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.trud...@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.hu...@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.szeg...@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.szeg...@oracle.com> >>>> Subject: Re: Nashorn and JVMTI >>>> Date: October 2, 2014 at 4:39:07 PM GMT+2 >>>> To: "David P. Caldwell" <da...@code.davidpcaldwell.com> >>>> Cc: nashorn-dev <nashorn-...@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 >>>> <da...@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/ >> >>
