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/ >> >
