[15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope

Roman Kennke rkennke at redhat.com
Wed May 27 11:18:52 UTC 2020


On Tue, 2020-05-26 at 13:57 -0400, Zhengyu Gu wrote:
> > Hm! I actually thought we optimized ShenandoahHeap::heap() enough
> > not to matter [1]. Reverting
> > heap() cache would seem to ditch some of these overloads:
> > 
> >   131   inline ShenandoahEvacOOMScope();
> >   132   inline ShenandoahEvacOOMScope(Thread* t);
> >   133   inline ShenandoahEvacOOMScope(ShenandoahHeap* heap);
> >   134   inline ShenandoahEvacOOMScope(ShenandoahHeap* heap, Thread*
> > t);
> >   135   inline ~ShenandoahEvacOOMScope();
> > 
> > Thread:current() seems fine to pass, where available, and store
> > locally.
> 
> Okay, updated: 
> http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.01/index.html
> 
> -Zhengyu

Looks good in general.

+  void register_thread_to_protocol(Thread* t);
+  void unregister_thread_to_protocol(Thread* t);

It would have to be 'unregister_thread_from_protocol' but then I think
we can just do 'register_thread' and 'unregister_thread' instead?

Also, why not inline register_thread() and unregister_thread() too?
Those appear to be the common paths in mutator-LRB, and should only
account for a few instructions?

It may be worth passing thread from compiled-code into mutator-LRB, we
already keep it permanently in a register, and it may be relevant for
tiny-object-evacs. But that would be a future change.

Roman




More information about the hotspot-gc-dev mailing list