RFR: keep read barrier on final field access

Aleksey Shipilev shade at redhat.com
Tue Oct 24 11:48:56 UTC 2017


On 10/24/2017 10:43 AM, Roland Westrelin wrote:
> 
>> I wonder if that means we cannot figure out early in GraphKit if the field access would be "stable"
>> or not, for fields that are marked for trustness in ciField::trust_final_non_static_fields. I do
>> think we need to walk through all the different trustness levels, including @Stable, +TFNSF,
>> ciField:tfnsf, etc, and capture what they have in Shenandoah.
> 
> Do we have any evidence that classes for which
> ciField::trust_final_non_static_fields() returns true today would work
> ok with no read barriers on instance final fields?

It seems to me the same trouble appears with these stable/trusted fields too: evac the hosted
object, and thus miss the update. While I still believe that is within the spec, it might be too
surprising to many.

> What ciField::trust_final_non_static_fields() says AFAIU is that it's
> guaranteed the final field is not updated by reflection etc. outside the
> constructor and that's it.
> 
> Given how tricky it is to track down a missing read barrier, I think it
> would be safer to be conservative here.

Yes, I agree. Let's emit the read barriers for them today.

-Aleksey



More information about the shenandoah-dev mailing list