RFR: 8241605: Shenandoah: More aggressive reference discovery
Roman Kennke
rkennke at redhat.com
Wed Mar 25 19:34:10 UTC 2020
Hi Aleksey,
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8241605/webrev.00/
>
> *) Feels like this cast:
>
> 1578 if (((ShenandoahEnqueueBarrierNode*)barrier)->can_eliminate(phase)) {
>
> ...should be done when we poll the node a few lines above?
> 1573 Node* barrier = state->enqueue_barrier(i);
Indeed. And it doesn't require a cast there! :-)
> *) "test_heap_stable" is misleading name now. "test_heap_state"? You already "assert
> is_heap_state_test".
Right. Changed that.
> *) I actually wonder if checking for TRAVERSAL|MARKING should be done as another generic
> optimization? It seems good by itself to test for this instead of falling through for
> evac/update-refs? (Actually, what checks for *that* in the old code?)
I believe you're confusing the enqueue-barrier with the LRB here.
EQ-barriers are only relevant during marking (and traversal).
> It is good for sh/jdk sandbox. Please make sure you don't use bug ID when pushing there, so that
> history would separate this prototype and the actual upstream change?
Yes, will do.
Thanks,
Roman
More information about the hotspot-gc-dev
mailing list