Charles, Thanks for your help and suggestions. I will try the printassembly. I how it works for x86_64 as that is my main interest. However, just the x86 will be useful.
On the well side of things - maybe I had too much reverb. I really like the sound of ambient reverb - but it is not to everyone's taste. Maybe next time I will turn it down a notch. As soon as I have some results from the assembler and other outputs - I will post them. The original posts I did (as you suggested I link them) are here: http://nerds-central.blogspot.com/2011/05/performing-dynamicinvoke-from-java-step.html and http://nerds-central.blogspot.com/2011/05/jvmjava-comparing-invokedynamic.html All the best - AJ On 28 May 2011 13:59, Charles Oliver Nutter <[email protected]> wrote: > On Sat, May 28, 2011 at 7:10 AM, Alex Turner > <[email protected]> wrote: > > All, > > > > Hi! This is my first post here. I am Alex Turner, currently technical > > team lead for the JVM compiler ground at Micro Focus. I have a great > > interest in invokedynamic and its performance. I created a performance > > test system using ASM 4.0 and Java. I am starting to get some figures > > (see my blog at nerds-central.blogspot.com for the source but I don't > > want to link spam you). > > Please link-spam! This group is all about sharing :) > > > The tests are run using the Sun/Oracle JVM on the 1.7-143 release on > > 64 bit Fedora 14. I would like to run the test (and more tests as I > > create them) using a range of different JVM flags to get some real > > numbers. I can then re-run these as new JVMs come out and try > > different platforms. > > > > If I was to pick 3 key flags to mess with, what would they be and what > > values should I give them > > Well had you asked a couple weeks back, I'd have recommended some > inlining flags like -XX:MaxInlineSize=#### and > -XX:InlineSmallCode=####. Those flags used to be useful for getting > invokedynamic/methodhandl logic to inline completely, but in recent > builds those don't make much of a difference (because the logic behind > the scenes now discounts invokedynamic/methodhandle logic for inlining > purposes). > > I have no suggestions at the moment for *tuning* invokedynamic. But I > will recommend my favorite flags for *monitoring* the JVM's > optimization of code: > > Required for many of these flags: -XX:+UnlockDiagnosticVMOptions > > -XX:+LogCompilation > > This will output a hotspot.log file containing a grotty XML-formatted > representation of what the Hotspot JIT compiler is doing with your > code. I would recommend not attempting to read this file yourself; > your eyes will almost certainly bleed. Instead, look for the > LogCompilation tool (logc) in OpenJDK sources under > hotspot/src/share/tools/LogCompilation and use the -i flag to print > out inlining information. Since inlining is the key to optimization, > this is your first angle of attack for investigating perf. You should > see invokedynamic calls inline like any other, along with any > MethodHandle intermediates you might be using to invoke code. > > -XX:+PrintAssembly > > This one requires the "hsdis" Hotspot disassembler plugin available > from the kenai.com project here: > http://kenai.com/projects/base-hsdis/downloads > > Obviously this will require a bit of knowledge of x86 assembly, but > x86 assembly isn't particularly difficult, is it? What you'll get from > this is the ultimate truth about how the JVM has chosen to optimize > your code. Ideally, you will see your method of interest with all > calls inlined; in other words, the top 20-30% of the resulting asm > will contain no CALL operations. CALL is the performance killer, not > just because it's relatively slower in itself, but because it > indicates lack of inlining. Lack of inlining means no optimization can > happen across that boundary. > > ...BTW... > > I could hear no traffic noise of any kind on your podcast. Near as I > could tell, you were podcasting from the bottom of a well or inside a > deep cave, rather than from a garden shed as you claimed. I hope you > have a heater or blanket, because it sounded very cold and lonely to > be talking about the JVM down there. > > - Charlie > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > -- Dr Alexander J Turner http://nerds-central.blogspot.com/2008/01/about-me.html -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
