review for 7071307: MethodHandle bimorphic inlining should consider the frequency

Christian Thalinger christian.thalinger at oracle.com
Wed Aug 24 06:12:55 PDT 2011


On Aug 24, 2011, at 1:44 AM, Tom Rodriguez wrote:

> This is a re-review since I added per method handle GWT profiling.
> 
> http://cr.openjdk.java.net/~never/7071307
> 312 lines changed: 270 ins; 15 del; 27 mod; 22101 unchg

src/share/vm/prims/methodHandleWalk.cpp:

MethodHandleCompiler::fetch_counts:

+   int count1 = -1, count2 = -1;
...
+   int total = count1 + count2;
+   if (count1 != -1 && count2 != -2 && total != 0) {

Why -2?

+   int          _taken_count;
+   int          _not_taken_count;

Does taken refer to target and not_taken to fallback in the GWT?

MethodHandleCompiler::make_invoke:

Can you use emit_bc instead of _bytecode.push where possible so we have at least a little sanity checking?

+     bool found_sel = false;

Can you rename that to maybe found_selectAlternative?


src/share/vm/ci/ciMethodHandle.cpp:

That print_chain is very helpful.  Thanks for that.


src/share/vm/classfile/javaClasses.cpp:

+ int java_lang_invoke_CountingMethodHandle::vmcount(oop mh) {
+   assert(is_instance(mh), "DMH only");
+   return mh->int_field(_vmcount_offset);
+ }
+ 
+ void java_lang_invoke_CountingMethodHandle::set_vmcount(oop mh, int count) {
+   assert(is_instance(mh), "DMH only");
+   mh->int_field_put(_vmcount_offset, count);
+ }

I think the assert message is a copy-paste bug.

Otherwise looks good.

> 
> 7071307: MethodHandle bimorphic inlining should consider the frequency
> Reviewed-by:
> 
> The fix for 7050554 added a bimorphic inline path but didn't take into
> account the frequency of the guarding test.  This ends up treating
> both sides of the if as equally frequent which can lead to over
> inlining and overflowing the method inlining limits.  The fix is to
> grab the frequency from the If and apply that to the branches.
> 
> Additionally I added support for per method handle profile collection
> since this was required to get good results for more complex programs.
> This requires the fix for 7082631 on the JDK side.
> http://cr.openjdk.java.net/~never/7082631

The JDK changes look good.

-- Christian

> 
> I also fixed a problem with the ideal graph printer where debug_orig
> printing would go into an infinite loop.
> 
> Tested with jruby and vm.mlvm tests.
> 



More information about the hotspot-compiler-dev mailing list