Nashorn and JVMTI

[Attila Szegedi]

No, we don't do anything to conceal Nashorn's internals. Granted, most of it lives in jdk.internal and jdk.nashorn.internal that are designated as restricted packages, but that shouldn't stop a debugger from looking into them. We often use jvisualvm ourselves to investigate Nashorn performance.

I often tell people that one of the benefits of running anything (including JavaScript) on the JVM is monitoring and management, so I'd definitely be against obscured visibility into the runtime.

I'll try to make NetBeans and JVMTI people aware of this.

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/