RFR: 8201543: Modularize C1 GC barriers

[Roman Kennke]

Hi Erik,

>> - At the same time, do you think the resolve_address() provides a place
>> for GC like Shenandoah that needs to resolve the base object and insert
>> a read/write-barrier and *then* resolve the barrier(base)+offset? If
>> this is the intention, may I request to somehow carry over the
>> information whether or not the address is intended for read or write?
>> Because we need insert different barriers on reads vs writes. Maybe this
>> can be added in the decorators?
> 
> Yes that was my intention indeed. I added in a C1_WRITE_ACCESS and
> C1_READ_ACCESS decorator for your convenience. Loads have
> C1_READ_ACCESS, stores have C1_WRITE_ACCESS, and atomics have both.

Perfect! I think that is good enough for my purposes.

> Full webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.02/
> 
> Incremental webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01_02/
> 
> It's a good place for ModRef to check whether resolving to a register is
> needed or not too (only required for accesses with write barriers).

Ok, seems fine to me.

>> - Or is the intention to resolve the base object on the actual
>> load_at_resolved() etc entry points? As far as I can tell this would be
>> difficult because we don't get to see the base object anymore?
> 
> I think it's best done in resolve. But note that you get the access
> wrapper in the resolved paths, and it retains the base pointer if you
> need it.
> 
>> - Thinking forward a little bit... Shenandoah is going to need some
>> resolve-hooks in a couple of places that are not practical to handle via
>> load/store style access calls. For example in monitorenter/exit code we
>> need to insert a write-barrier on the object to be synchronized on. Will
>> this be possible/practical to do via resolve_address()?
> 
> I think we should probably add a public resolve barrier for that purpose.

Ok. I will take care of it as soon as this change is pushed.


>> - Does it already handle primitive accesses? From the looks of it, I'd
>> say yes. That'd be nice.
> 
> The backends should be ready for it. But I think I will leave the
> exercise of finding the callsites to you, as you have spent more time
> finding where they are needed.

Yup, absolutely.

Thanks again for doing this!
Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180424/c98264e1/signature.asc>