Nashorn and JVMTI

[Attila Szegedi]

David,

I was told this is a bug in the JDK that has since been fixed and will be released with 8u25 on October 14. Relevant issue descriptions are at <https://netbeans.org/bugzilla/show_bug.cgi?id=245522> and <https://bugs.openjdk.java.net/browse/JDK-8050485>. The discussion at the first link seems to have also mentioned -Xverify:none as a temporary workaround. I have reviewed these and there's no talk about this fix being relevant to the visibility into Nashorn classes too. To determine that, you can download Java 8u40 Early Access release from <https://jdk8.java.net/download.html> and see if it fixes the entirety of your issue – the current 8u40 EA build is 07, and I can see that the fix for this issue has made it already into build 03.

Hope that helps,
  Attila.

On Sep 25, 2014, at 11:13 PM, David P. Caldwell <david at code.davidpcaldwell.com> wrote:

> Team,
> 
> When I attempt to connect the NetBeans profiler (which I understand to
> be essentially the same as jvisualvm) to a Nashorn embedding, I get an
> error (JVMTI error 62) for essentially every class that relates to
> scripting, including the dynalink stuff and Nashorn itself, as well as
> generated classes named NashornJavaAdapter.
> 
> If I persist through all of this (or filter them out of being
> profiled, or turn on -Xverify:none), I end up with profiling data that
> doesn't involve the JavaScript code at all; it basically treats the
> call to eval() as atomic.
> 
> Do you guys do this stuff? My customers are constantly objecting to
> the "fact" that running Java on the JVM is going to be a terrible
> idea, performance-wise -- especially compared to Node, which they
> believe is lightning fast -- and I am having difficulty generating
> data on this point.
> 
> More generally, of course, profiling is a normal and necessary
> development activity. I wrote a Java agent for Rhino that mangled the
> classes using Javassist to wrap all JavaScript function invocations in
> instrumented methods, but I'm not clear on (a) whether that's
> necessary, or (b) how it would work given the Nashorn implementation
> is probably using constructs I don't yet understand. But if that's the
> route, let me know and give me a pointer or two and I'll be on my way.
> 
> -- David P. Caldwell
> http://www.davidpcaldwell.com/