Nashorn and JVMTI

[David P. Caldwell]

Bernd,

Thanks for your advice on this.

I do not enjoy benchmarking; I enjoy simplicity, and a customer with a
Java-based stack, lots of JavaScript programmers working on the
client, and a desire to migrate toward scripting languages should use
Nashorn, because it's by far the simplest path forward.

But the objection I got was "there are performance concerns," with no
evidence presented. So I'd want to (a) create a minimal amount of
evidence, (b) use profiling exactly like you're suggesting to do a bit
of bottleneck elimination of proof-of-concept code before presenting
it. Because the first evaluation customer would do would be to load
test it, and I'd want to be prepared.

I anticipate bottlenecks would have nothing to do with Nashorn (there
are no DBAs, so the database is not exactly optimized), but I'd like
to have some metrics to demonstrate that.

I agree that I would not use the profiler to do performance
benchmarking, given that the profiler adds overhead in the first
place. :)

-- David.

On Thu, Oct 2, 2014 at 2:21 PM, Bernd <ecki at zusammenkunft.net> wrote:
> Hello David,
>
> Do you want to optimize the JVM settings before challenging V8 or do you
> hope to get absolute measurements with the profiler to show off?
>
> Because I would advice against using profilers for anything besides
> optimizations, finding hotspots and doing before/after comparision or
> trends.
>
> For the shootout an externally driven metric (req/s, 99%th service times)
> is a guess better. And particular on bigger machines (which I would expect
> to be the NodeJS bottleneck - not sure if Avatar.JS does this better).
>
> Gruss
> Bernd
> Am 25.09.2014 23:24 schrieb "David P. Caldwell" <
> david at code.davidpcaldwell.com>:
>
>> 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/
>>