Tom was looking into a bug with his bimorphic inlining patch and said something
about massive inlining with RtalkTest so I thought I also give it a shot.
One thing I can say for sure: massive inlining and huge methods!
We get a lot like:
@ 115 java.lang.invoke.MethodHandle::asSpreader (13 bytes)
NodeCountInliningCutoff
@ 60 ri.core.rtalk.RtFixedObjects::getNil (5 bytes) size >
DesiredMethodLimit
I think the thing Tom as was a method like e.g.:
79216 390 rtPbc.r184::block$1 (49 bytes)
It seems it does recursive inlining of this pattern:
@ 3
java.lang.invoke.MethodHandle::invokeExact (7 bytes) inline (hot)
@ 3 ri.core.rtalk.RtCallSite::test (16
bytes) inline (hot)
@ 1 ri.core.rtalk.RtObject::classField (5
bytes) inline (hot)
@ 10
java.lang.invoke.MethodHandle::invokeExact (12 bytes) inline (hot)
@ 5
java.lang.invoke.MethodHandleImpl::selectAlternative (10 bytes) inline (hot)
@ 23
java.lang.invoke.MethodHandle::invokeExact (30 bytes) inline (hot)
@ 23
java.lang.invoke.MethodHandle::invokeExact (8 bytes) inline (hot)
@ 1 rtPbc.r192::invoke (10 bytes) inline
(hot)
@ 4 ri.core.rtalk.RtFixedObjects::getTrue
(5 bytes) inline (hot)
@ 1
ri.core.rtalk.RtFixedObjects::getFixedAsRtObject (8 bytes) inline (hot)
@ 1
ri.core.rtalk.RtFixedObjects::getFixedObject (8 bytes) inline (hot)
@ 4
ri.core.container.OrderedMap::getValueAt (9 bytes) inline (hot)
@ 5 java.util.ArrayList::get (11
bytes) inline (hot)
@ 2
java.util.ArrayList::rangeCheck (22 bytes) inline (hot)
@ 7
java.util.ArrayList::elementData (7 bytes) inline (hot)
Is that your GWT chains? If so, these are either a little too long or we have
a bug somewhere.
-- Christian
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
