netbeans
netbeans copied to clipboard
apache
NB 21 (and 20 too) focused profiler does not work with project source level > 11
Apache NetBeans version
Apache NetBeans 21
What happened
The focused (instrumented) profiler over selected classes & selected methods does not works with source level > 11 (tested with 17 & 21). No profiler data is collected, no threads are catched by profiler tool. General (sampled) profiler works fine.
Language / Project Type / NetBeans Component
Java (ant or maven tested) based application
How to reproduce
Create a sample application (eg: anagram game in NB Ant samples) with NB 21 (or 20) and installed JDK >= 17 (I've tested the problem with both 17 and 21).
Keep (in case of anagram game) source level to 8, run profiler in "methods" mode, go to "focused (instrumented) mode" and select "selected classes" or "selected methods" to profile. Profile (run) project. Invoke the profiled selected class or method: you can see collected data in profiler. The running thread is catched and profiled.
Switch source level to 11 and run the same steps with the profiler: all fine.
Finally, repeat the same steps with source level to 11 or 21: failed! No classes/methods will be profiled and profiler cannot find any thread in thread selection.
Some screenshots about settings:
Did this work correctly in an earlier version?
Apache NetBeans 16 or earlier
Operating System
FEDORA 39
JDK
OpenJDK 64-Bit Server VM (Red_Hat-17.0.9.0.9-4) (build 17.0.9+9, mixed mode, sharing)
Apache NetBeans packaging
Apache NetBeans binary zip
Anything else
Tested with vanilla NB 20 & 21: no customization & no external plugins. Tested with vanilla Fedora 39 builtin rpm java (17 & 21) packages too. Tested with external (Oracle, Adoptium) JDKs.
The problem seems related to the inability of profiler to catch the running thread (IMHO).
Are you willing to submit a pull request?
No
Hi all, FYI, verified: any source level > 11 causes the profiler not to function as expected. What could be the problem? Many thanks.
can confirm that bumping the source level above 11 will break the method profiler
@mbien check out #2949 One possibility might be to look at consuming the VisualVM code as a library? It's published to Maven - https://central.sonatype.com/artifact/org.graalvm.visualvm.modules/org-graalvm-visualvm-lib-profiler
@neilcsmith-net well, tbh I don't use the NB profiler at all personally - https://github.com/async-profiler/async-profiler took over all my profiling needs, it truly is an awesome tool and completely IDE independent.
Thats why I didn't plan to put time into this, I would have quickly checked if it is fixable thats all ;)
@mbien me neither most of the time. Having the profiler slowly decaying and no-one working on it is not a solution - either we need someone to work on it, we integrate with a third-party library, or we drop it and look at third-party tool integration instead?
@neilcsmith-net i mean async-profiler generates HTML flame graphs (e.g https://github.com/apache/netbeans/pull/4095) and directly connects via PID, so the integration would be a few buttons which map to CLI lines most likely.
no windows support though.
edit: but yes I agree that we should retire unmaintained functionality
I just stumbled upon this bug today with the same conditions: NB21, JDK21, sourcelevel21, Focused(instrumented) profiling. I use netbeans and all the build-in-tools like the profiler, git-support, maven ... a LOT the last 15 years in a offline environment without access to the internet, so i was very happy that netbeans comes "with batteries includes": Download, unzip and ready to rumble. It would be a shame for such a beautiful, solid IDE to starve slowly. So: please, please, fix this if you can :-) Thank you
@mbien check out #2949 One possibility might be to look at consuming the VisualVM code as a library? It's published to Maven - https://central.sonatype.com/artifact/org.graalvm.visualvm.modules/org-graalvm-visualvm-lib-profiler
This seems like the obvious choice as it pretty much IS the profiler included in Netbeans and supports Windows.
@thurka could you have a look at the NetBeans profiler? If I remember correctly, you were one of the authors. The class contents after compilation does not vary based on the class version (at least the javap output looks identical), so I suspect, the VM uses a different code path for execution, based on the class file version.
Maybe this plugin could be an option, when you are searching for an alternative: https://github.com/parttimenerd/intellij-profiler-plugin
