Oh, by the way - we never seem to get any free cycles for this, but in the Java 9 timeframe I hope (forward looking statement - so it can be a complete lie - disclaimer), that we will also have some basic JFR events in Nashorn itself, which will provide JavaScript specific data, such as “this callsite is megamorphic” and similar things.
/M > On 04 May 2015, at 11:31, Marcus Lagergren <[email protected]> > wrote: > > Personally, I use Java Mission control to record and analyze the heap > operating set. This is free for non production use. Mission control also > gives you source lines in your original JavaScript program for views. > > Attila and I have previously also used the http://eclipse.org/mat/ > <http://eclipse.org/mat/> Eclipse plugin. > > Regards > Marcus > >> On 30 Apr 2015, at 15:32, Josh Fleming <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi folks, >> >> What's the best way to do heap profiling of JavaScript code in Nashorn? >> We're running a large JavaScript framework on Nashorn, and recently I had to >> track down a couple memory leaks. This turned out to be a painful process. >> When using a heap profiler like YourKit, it's very tedious to find the >> correspondence between what you see in a JVM retention path and the exact >> JavaScript code it originates from: there are multiple layers of JVM >> representation, and the naming is a bit cryptic. >> >> Eventually I fell back on a manual process of drilling down to the "JO* -> >> map -> properties -> list" linked list to find a unique property name within >> each JavaScript object, and used what I found there to grep the JavaScript >> code. The situation is better if you happen to come upon a closure, because >> the "data -> functionName" property in ScriptFunctionImpl includes a line >> number. But it seems like there must be a better way. >> >> Any guidance would be much appreciated. >> >> >> Thanks, >> >> jf >> >
