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