[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