Re: Nashorn and JVMTI

[Michel Trudeau]

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/