when I profiled one of our running JVMs, I found non profiled CPU classes count is growing constantly. Even though these non profiled CPU classes are not included in the filter settings, does increase in count alarm some kind of leak? We are using some third party libraries also in our application. Right now I see the classes count is increasing in this third party library. May be we are not handling code properly? I'm not sure. Can you someone please advise if this is some kind of leak? Attached classes screenshot and related information with the third party class.
Screen1
Screen2
You can use the "Class loaders" probe in the "JEE & Probes" section to see which classes are loaded and what triggers the loading of those classes. The "Events" tab of that probe will show you single class loading events with stack traces.
Related
Can you pls help us answering the below questions.
1) While tracing/profiling a JAVA based web application using jprofiler is there any way to find out if the calls are parallel or sequential ?
2) While running Jprofiler on JVM where Wily tracing tool is already there, the jprofiler is mostly detecting the the overhead due to Wily tool rather than the actual application. Is there any way we can enable the jpropfiler filter to ignore Wily probes (e.g. ignore anything that starts with com.wily.. Even after putting this filter in jprofiler exclude class filter, still jprofiler detects the Wily probes with com.wily.). Can you pls suggest how to fix this in exclude filter ?
Also, is there any known conflicts/issues of jprofiler with Wily tool ?
Thanks,
PR
is there any way to find out if the calls are parallel or sequential
No, the call tree cannot show this.
Even after putting this filter in jprofiler exclude class filter, still
jprofiler detects the Wily probes with com.wily.
That is because the calls from profiled classes are always shown and Wily instruments your code. You can configure a ignored method by right-clicking the Wily method in the call tree and choosing "Add filter from selection->Ignore method ...".
In general, I would not recommend to use multiple profilers or monitoring tools at the same time.
I am evaluating different multiprocessing libraries for a fault tolerant application. I basically need any process to be allowed to crash without stopping the whole application.
I can do it using the fork() system call. The limit here is that the process can be created on the same machine, only.
Can I do the same with MPI? If a process created with MPI crashes, can the parent process keep running and eventually create a new process?
Is there any alternative (possibly multiplatform and open source) library to get the same result?
As reported here, MPI 4.0 will have support for fault tolerance.
If you want collectives, you're going to have to wait for MPI-3.something (as High Performance Mark and Hristo Illev suggest)
If you can live with point-to-point, and you are a patient person willing to raise a bunch of bug reports against your MPI implementation, you can try the following:
disable the default MPI error handler
carefully check every single return code from your MPI programs
keep track in your application which ranks are up and which are down. Oh, and when they go down they can never get back. but you're unable to use collectives anyway (see my opening statement), so that's not a huge deal, right?
Here's an old paper (back when Bill still worked at Argonne. I think it's from 2003):
http://www.mcs.anl.gov/~lusk/papers/fault-tolerance.pdf . It lays out the kinds of fault tolerant things one can do in MPI. Perhaps such a "constrained MPI" might still work for your needs.
If you're willing to go for something research quality, there's two implementations of a potential fault tolerance chapter for a future version of MPI (MPI-4?). The proposal is called User Level Failure Mitigation. There's an experimental version in MPICH 3.2a2 and a branch of Open MPI that also provides the interfaces. Both are far from production quality, but you're welcome to try them out. Just know that since this isn't in the MPI Standard, the function prefixes are not MPI_*. For MPICH, they're MPIX_*, for the Open MPI branch, they're OMPI_* (though I believe they'll be changing theirs to be MPIX_* soon as well.
As Rob Latham mentioned, there will be lots of work you'll need to do within your app to handle failures, though you don't necessarily have to check all of your return codes. You can/should use MPI error handlers as a callback function to simplify things. There's information/examples in the spec available along with the Open MPI branch.
I'm still fighting with memory leak. Using improved MemoryDiagnosticsHelper, i added possibility to make datastamps to see immediate memory cunsumption.
Problem starts at full app: i have a pivot with 3 items, 2 of them containing list of 10-20 objects (with possibility to jump to item details). Memory diagnostic shows, that it consumes about 50Mb of memory. After jumping to detail page and returning to pivot, memory consumption easily grows to 70Mb.
At first, i moved list to separate app. Without style, it takes 15 Mbs. I didnt check yet, but i assume, 2 lists in pivot would take about 20Mbs, because dlls are already loaded.
So, i decided to go deeper into app loading stage.
At the InitializePhoneApplication(), it takes 7 Mb.
At the CompleteInitializePhoneApplication(), it takes 8.5 Mb with empty ViewModelLocator, or 10.5 Mb with all viewmodels. Quite large, but i have 30-40 dataservices and 40-50 viewmodels. So let it be, i'd feel myself pretty ok, if it would not grow anymore.
At the first page's OnNavigatedTo(), it takes almost the same, kinda 10.7 Mb with all VMs, that's ok.
???
No profit. Seriously, what happens next? I cant see, what exactly is going on next, but MemoryDiagnosticsHelper says, that memory consumption jumps to 30 Mbs. Why? All dlls and VMs are already loaded. I'm just loading a very empty page, totally white.
Profiler (running in release mode, of course), is also helpless. It just shows growth in memory consumption, but it happens in non-managed memory. It annoys alot, really.
Ok, lets make question more clean. What happens next, when app is initialized (passed initialization, and viewmodel loaded and attached, and page passed OnNavigatedTo())?
EDIT 1: in the night, i got and idea, that the only weak part in my app (at least, that master-detail pages) is MVVMLight's EventToCommand. Almost first article in google is http://atomaras.wordpress.com/2012/04/23/solving-mvvmlights-eventtocommand-memory-leak-wp7/ Anybody knows, if it is alreasy fixed? I checked MvvmLight's blog, and looking like Laurent is working on installer for now. That pushes me to idea, that this leak should be already solved, isnt it?
EDIT 2: i see 2 solutions for leaking problem: either to use fix from the link above, or call commands from the codebehind. Or use another MVVM lib.
References.
I expected them to be loaded smoothier, during first stages of app init. Also, now it is clear, why profiler said that there's not that much managed code in the memory.
Background:
We build a product which adds various features (transactions, shared memory based object persistence, indexing and queries, cluster based high availability and replication) to Java via annotations and a custom class loader. The bulk of the implementation for these features is in C++ libraries which are accessed via native calls inserted by our class loader. Our natives can be characterized as using CPU, blocking via mutex or condvar acquisition, blocking on network I/O, or some combination of all three. The native entry points themselves do not know whether or not they will block.
Question:
JProfiler reports time spent in our natives as CPU time, and shows any thread inside our natives as running. Is there someway to make JProfiler aware of the actual combination of running and blocking that occurs?
Add a method trigger for all native methods that should be excluded from the "Runnable" thread state. On the "Actions" step of the trigger configuration, add a "Override thread status for current method" trigger action. You can set the thread status to "Waiting", "Blocking" or "Net I/O".
Sometimes when looking at someone else's large Objective-C program, it is hard to know where to begin.
In such situations, I think it would be helpful to log every call to every non-Apple method.
Is there a way to do that? Basically, make one change in some central place, and log every method that is called. Preferably limited to non-Apple methods.
You can set the environment variable NSObjCMessageLoggingEnabled to YES. This will write a log of all message sends in the folder /tmp/msgSends-xxx.
You could add a symbolic breakpoint to objc_msgSend(), and have it log the second parameter without stopping.
How to do it for your own methods only though is a toucher task. Maybe if you could inspect the class name being called and do some magic to have a conditional breakpoint for only calls where the class' prefix matches your own?
I don't think logging every single call is practical enough to be useful, but here's a suggestion in that direction.
On a side note, if it's a large program, it better have some kind of documentation or an intro comment for people to get started with the code.
In any case, every Cocoa application has an applicationDidFinishLaunching... method. It's a good place to start from. Some apps also have their principal (or 'main window') class defined in the Info.plist file. Both these things might give you a hint as to what classes (specifically, view controllers) are the most prominent ones and what methods are likely to have long stack-traces while the program is running. Like a game-loop in a game engine, or some other frequently called method. By placing a breakpoint inside such a method and looking at the stack-trace in the debugger, you can get a general idea of what's going on.
If it's a UI-heavy app, looking at its NIB files and classes used in them may also help identify parts of app's functionality you might be looking for.
Another option is to fire up the Time Profiler instrument and check both Hide missing symbols and Hide system libraries checkboxes. This will give you not only a bird's eye view on the methods being called inside the program, but also will pin-point the most often called ones.
By interacting with your program with the Time Profiler recording on, you could also identify different parts of the program's functionality and correlate them with your actions pretty easily.
Instruments allows you to build your own "instruments", which are really just DTrace scripts in disguise. Use the menu option Instrument >> Build New Instrument and select options like which library you'd like to trace, what you'd like to record when you hit particular functions, etc. Go wild!
That's an interesting question. The answer would be more interesting if the solution supported multiple execution threads and there were some sort of call timeline that could report the activity over time (maybe especially with user events plotted in somehow).
I usually fire up the debugger, set a breakpoint at the main entry point (e.g. - applicationDidFinishLaunching:withOptions:) and walk it in the debugger.
On OSX, there are also some command-line tools (e.g. sample and heap) that can provide some insight.
It seems like some kind of integration with instruments could be really cool, but I am not aware of something that does exactly what you're wanting (and I want it now too after thinking about it).
If one were to log a thread number, and call address, and some frame details, it seems like the pieces would be there to plot the call timeline. The logic for figuring out the appropriate library (Apple-provided or third party) should exist in Apple's symbolicatecrash script.