VisualVM hangs

[cowwoc]

Version 1.4.1

This might be related to #64

Sometimes I find VisualVM using 100% of 1 CPU core, stuck in an endless loop. The GUI is non-responsive and must be killed. I don't have repro steps but I am attaching a thread dump and the contents of messages.log for your review.
messages.log
thread-dump.txt

[jisedlac]

Based on both the thread dump and logfile, the Marlin rendering engine (https://github.com/bourgesl/marlin-renderer) is busy rendering the VisualVM charts:

java.lang.Thread.State: RUNNABLE
at sun.java2d.marlin.DDasher.lineTo(java.desktop@10.0.2/DDasher.java:372)

org.netbeans.core.CLIOptions2$EQStuck: GUI is not responsive
at java.desktop@10.0.2/sun.java2d.marlin.DRenderer.lineTo(DRenderer.java:683)

It seems to be bug in Marlin, the problem doesn't happen with Oracle JDK / OpenJDK. You should file a bug for Marlin and don't use it with VisualVM until fixed.

[cowwoc]

@jisedlac

It seems to be bug in Marlin, the problem doesn't happen with Oracle JDK / OpenJDK. You should file a bug for Marlin and don't use it with VisualVM until fixed.

What do you mean? I am running Oracle JDK 10.0.2 under Windows 10. I never installed Marlin. If this is a bug with Marlin version that is packed with the JDK, isn't Oracle responsible for chasing this down?

PS: I have never seen this bug outside of using VisualVM.

[cowwoc]

PS2: How do we know that VisualVM isn't at fault? Meaning, maybe VisualVM has sent an extremely heavy workload to Marin? (like rendering a billion lines)

[bourgesl]

Hi,
Stack traces indicates that jvisualvm chart overlay is causing a huge work to draw a dashed line:
at java.desktop@10.0.2/sun.java2d.SunGraphics2D.drawLine(SunGraphics2D.java:2235)
at com.sun.tools.visualvm.charts.xy.XYSelectionOverlay.paint(XYSelectionOverlay.java:137)
at java.desktop@10.0.2/javax.swing.JComponent.paintChildren(JComponent.java:907)

Any idea what is causing this situation: a very (too) long line, maybe wrong viewport size ?

In jdk10, Marlin 0.8.2 clipping does not clip dashed lines.
I implemented efficient dash clipping in Marlin 0.9.2 coming in jdk11 or as a jdk10 patch:
https://github.com/bourgesl/marlin-renderer/releases/tag/v0_9_2_jdk9

Could you give a try ? And explain me when the problem happens ?

[cowwoc]

@bourgesl

I implemented efficient dash clipping in Marlin 0.9.2 coming in jdk11 or as a jdk10 patch:
https://github.com/bourgesl/marlin-renderer/releases/tag/v0_9_2_jdk9 ... Could you give a try ?

I don't mind trying but you're going to have to provide me with a pre-compiled version to use under Windows 64-bit. Also, I think it might be unproductive to do so until we narrow down the repro steps. Which leads me to:

And explain me when the problem happens ?

I don't have concrete repro steps. All I know is that a couple times per day, I switch from VisualVM to my IDE and a few minutes later I notice that CPU usage is high. I track it down to VisualVM. When I try to switch focus back to it, the app is non-responsive and has to be killed.

[bourgesl]

As Marlin renderer is pure java code, you just need to patch jvisualvm or jdk10 with the marlin patch jar file given on the github release.
It will confirm or not if your problem is fixed and will be fixed by coming jdk11 in september.
Anyway jdk10 is soon EOL, so no bug can be fixed anymore.

I agree it is important to determine reproducer steps... what plots do you have on screen (large dataset or zoom window) ?

[bourgesl]

Maybe you are affected by this bug in jdk10:
https://bugs.openjdk.java.net/browse/JDK-8202580

[jisedlac]

OK, I wasn't aware that Marlin is now the default JDK renderer. Is there any way to disable it and run VisualVM with the original renderer on Java 9/10 as a workaround?

[jisedlac]

I've reviewed the VisualVM graphs code and there's nothing suspicious - the dashed line is exactly as long as the component size - being painted from 0 to getHeight(). I don't see any "heavy workloads" coming from VisualVM.

I've tried to reproduce the problem on my side - Windows 10, JDK 10.0.2, VisualVM 1.4.1 - with no success, works just fine. It looks like there's some corner case where the Marlin algorithm fails, maybe related to losing/gaining focus and/or visibility, guessing from the description from @cowwoc.

A screenshot of the VisualVM GUI at the point it gets frozen might help to identify the failure conditions.

Please let me know if there's anything we could do on VisualVM side to help to resolve the problem.

[bourgesl]

In jdk10, other antialiasing renderers were removed.
I suspect the getHeight() method returning an invalid size (Integer.MAX_VALUE) in some cases (invisible or disabled window...), any clue ?
Where is the source code of this method ?

[jisedlac]

https://github.com/oracle/visualvm/blob/master/visualvm/charts/src/org/graalvm/visualvm/charts/xy/XYSelectionOverlay.java#L137

[jisedlac]

Component.getHeight() seems to work fine - I've just tried all possible window states. IMO there would be many other issues including OOME from offscreen buffers if getHeight() returned Integer.MAX_VALUE.

[bourgesl]

Maybe unrelated but josm had issues with that change:
https://bugs.openjdk.java.net/browse/JDK-8072682
Concerning marlin bug in jdk10, it can be avoided if the dash phase is 0. In your case the even stroke.