I'm trying to profile a junit test - all I care about is hot spots and call tree - I want to see where the test is taking time. I'm running the test by right clicking in intellij idea and saying "profile ..." The test runs in less than a second, and then finishes - even if I can get there quick enough to click call tree and click start recording (haven't found any way of getting it recording immediately) - anything I haven't managed to open by the time it finishes is not available, saying things along the lines of "no data was received because the profiled JVM has terminated.
How do I right click and run a test, have it capture all call history and timings in such a way that I can browse it all once the test has completed? (or is there an alternative/better way of doing this?)
In the profiling settings, on the "Miscellaneous" tab, there is a setting called "Keep VM alive". If you select that check box, the VM will not terminate as long as the JProfiler GUI is connected to it.
Update 2017-11-28
Since JProfiler 10, this setting is no longer in the profiling settings, but in the startup dialog. Also, there is now an option to automatically save a snapshot when the JVM exits. This has the advantage of not blocking the test runner in the IDE.
Related
I have a frustrating issue where Eclipse (aka Spring Tool Suite flavor) falls into a strange build state that it can never complete or resolve. When the problem occurs, a cyclic state between multiple processes ensues. A common case is when the "Download Sources and JavaDocs" process runs every few seconds, dropping briefly into a "Sleeping" state to allow other processes to run, and then times out and restarts the process. This continues to repeat indefinitely. The switching from build to sleep modes perpetually occurs. These fighting processes will continue in this way for hours, if I let Eclipse continue, which also utilizes the CPU heavily throughout.
This unsettled state is often initiated when I perform a full clean and/or build of my project(s), whereas other times it happens when I include new Java Classes as required dependencies. Sometimes it gets going all on its own. Either way, Eclipse will vainly attempt to build the project(s) resources, and the project itself, and it will do so indefinitely without ever achieving a resolved state.
While there are a variety of combinations of these fighting / conflicting / deadlocked processes, I have noticed that it is often a "Building Workspace" process that frequently has issues. The build runs to around 85%, then suddenly sleeps while a "Download Sources" process appears and runs, after which the "Building Workspace" resumes once again... always starting over, and never quite building to completion. Always dropping into a sleep state when "Download Sources" runs.
When I grow weary of it, and wish to end it, I must either exit my IDE completely and restart, or I have to rapidly click the STOP button of the oscillating processes that that flash and disappear inconsistently in the progress view. It feels rather like playing a Whac-A-Mole carnival game of sorts, until I have successfully clicked them all. At that point, the processes cease to appear, and things run smoothly again for a time. This is NOT something that happens every time, but often enough to be a nuisance, and it interrupts productivity as it slows or blocks other processes, such as starting my project.
With previous builds of Eclipse on other machines, I never recall having this issue... at least not so persistently. And yet I have read similar issues in various forums (including Stack Overflow) going back for years.
Eclipse / Spring Tool Suite Version info
STS Version: 3.9.4.RELEASE
STS Build Id: 201804120921
Platform: Eclipse Oxygen.3a (4.7.3a)
HOST O.S.: Windows 10 - 64-bit edition
Here is what I have tried so far:
I unchecked the "Refresh using native hooks or polling" and my problem has continued to occur for the past few months.
I haven't moving the metadata folder out (article here) because I'm worried about wasting more time recovering if it goes wrong.
Disabled certain Maven plugins and closed projects. It does seem to happen less frequently when I have only a single project open. However, in the world of cooperating services, it is often necessary to keep multiple projects open.
Perhaps this is related more to the customized STS tooling (Spring Tool Suite) that has been applied over Eclipse, but because I'm not sure, I didn't Tag STS.
This issue is very intermittent, but once it starts happening, I can't get around it.
I have passed the "agentlib" flag. Do I also need to set trigger to get the snapshots? I actually wanted to profile the entire run (including heap/gc dumps, CPU profiling of methods etc) from start to stop of the application. Can someone let us know how we can do this for ENTIRE application run? The help is not very clear on this.
This is called "offline profiling" in JProfiler and requires you to set up triggers.
You define a trigger for "JVM startup" where you start the recordings that you are interested in and a "JVM exit" trigger where you save a snapshot.
For more information, see
http://resources.ej-technologies.com/jprofiler/help/doc/helptopics/config/triggers.html
I have a problem while debugging in IntelliJ IDEA, it hangs in debug mode on break point in listeners in javafx application. I tried to increase heap space, but it's not help. Maybe someone had such problem too, please, suggest me what to do.
Set this as a VM parameter:
-Dsun.awt.disablegrab=true
It will mess up drag-and-drop, and leave an artifact on your screen while the debugger is paused - but it will let you debug. It happens whenever you block the JavaFX thread.
This can happen for a simple reason: The application has a lock on the desktop, for example a modal dialog or a popup or an open menu. Then it stops in a breakpoint. This notifies the IDE. Now the IDE tries to do something on your desktop but can't since the application still has a lock on the whole desktop -> deadlock.
You can use a tool like Chronon which records the whole program and lets you move back and forth on the timeline.
The last option is logging or poor man's debugger (System.out) instead.
[EDIT]
it's hard to check with System.out which of 20 parameters not equal.
It's actually pretty easy:
System.out.println("check");
if(!a1.equals(b2)) System.out.println(a1+"!="+b1);
Then duplicate the last line. That way, you will only get output when something is actually interesting (and not for the 19 equal parameters). Add some patterns to the output if you can't distinguish aX from aY (i.e. both are true):
if(!a1.equals(b2)) System.out.println("a1:"+a1+"!="+b1);
I am trying to profile functions in my java application using VisualVM (eclipse plug-in). Right now when I run an application, eclipse opens VisualVM and takes me to the profilers tab where I can start profiling by pressing the CPU or Memory buttons. Unfortunately, in the time that I take to manually do this, I lose significant number to iterations in my application to get a precise result.
I know I can set the default profiler setting for an application under Tools->Options->Profiling. But is there an option in VisualVM where it can automatically fire the profiler on seeing a particular main function/application being launched.
VisualVM is practically the standalone Netbeans Profiler (which is a great tool, by the way).
But what I am missing, is the ability to initialize monitoring settings for a process before it starts.
Usually, in VistualVM, one can open a process and start changing settings only when the process is already running. This is a problem when one should want to profile a shorter-term process.
Sadly, this solution doesn't work: A Java program doesn't starts "fast enough", and gets suspended before it would be recognized by VisualVM as such.
Is it possible to do somehow?
NOTE 1: My current workaround: I added a cmd-line switch to my project: "-W" to wait for an [enter] key press.
NOTE 2: Strange, the Netbeans Profiler still gives much more realistic profiling results. But it has a bug currently, which forces me to recompile the main project the amount of times of linked projects ;) That'll be 12... And I failed to reproduce the bug.