Nashorn and JVMTI

[Tomas Hurka]

Hi Attila,
JVMTI error 62 is caused by bug in JDK. See <https://netbeans.org/bugzilla/show_bug.cgi?id=245522>

--
Tomas Hurka   <mailto:tomas.hurka at oracle.com>
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.java.net
Software Developer
Oracle, Praha Czech Republic


On 2 Oct 2014, at 16:47, Attila Szegedi <attila.szegedi at oracle.com> wrote:

> Folks,
> 
> I'm forwarding a message from nashorn-dev (as well as my initial reply); there seems to be an issue with trying to profile Nashorn using JVMTI through NetBeans profiler. If anyone has any insight into this, it'd be appreciated.
> 
> Thanks,
>   Attila.
> 
> 
> Begin forwarded message:
> 
>> From: Attila Szegedi <attila.szegedi at oracle.com>
>> Subject: Re: Nashorn and JVMTI
>> Date: October 2, 2014 at 4:39:07 PM GMT+2
>> To: "David P. Caldwell" <david at code.davidpcaldwell.com>
>> Cc: nashorn-dev <nashorn-dev at openjdk.java.net>
>> 
>> 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/
>> 
>