Nashorn and JVMTI

[Attila Szegedi]

Thanks for the quick answer, folks. I have answered on nashorn-dev appropriately (suggested they try 8u40 EA as the fix should be in there too).

On Oct 2, 2014, at 6:51 PM, Michel Trudeau <michel.trudeau at oracle.com> wrote:

> Right.   It's fixed in many releases.
> 
> https://bugs.openjdk.java.net/browse/JDK-8050485
> 
> 8u25, which ships on October 14, will have this fixed.
> 
> Thanks,
> Michel	
> 
> 
> 
> 
> Tomas Hurka wrote:
>> 
>> 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/
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20141002/f4488f6a/attachment-0001.html>