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