Ping: RFR: JDK-8205523: Explicit barriers for interpreter

[Roman Kennke]

>> I am a fan of profile guided optimization. I would definitely not mind 
>> introducing these concepts in the compilers where they are with no doubt 
>> necessary (and we also have the right tools for dealing with this 
>> better). In fact, they already have read/write decorators that could be 
>> used for resolve barriers in our compilers, and can use algorithms to 
>> safely elide barriers where provably correct, so it makes perfect sense 
>> for me to use such concepts there.
>> I'm just not sure that the interpreter needs to be polluted with this 
>> conceptual overhead, unless there is at least one benchmark that can 
>> show that we are solving an actual problem with this. Remember, 
>> premature optimizations are the root of all evil.
> 
> but efficient systems are made from thousands of tiny optimizations, each
> one too small to be measured above the noise on its own.
> 

After some offline discussion with Erik, I want to propose a solution
that 1. keeps the API simple to use, even if not sure if it's a read- or
write-access (defaulting to stronger write, 2. remains flexible enough
to optimize for read-only acces.

This changeset introduces an API BarrierSetAssembler::resolve() which
takes the 'hint' about read- vs write-access via a Decorator ACCESS_READ
and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets
ACCESS_WRITE if ACCESS_READ is not explicitely set.

Incremental webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/
Full webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/

If this proposal gets accepted, I'd take this further (in separate RFEs):
1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS
and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they
are currently passed into Access API that 'knows' what it is, e.g.
store_at/load_at, etc).
2. introduce same pattern for resolve() in runtime (and later, c1 and c2).

What do you think?

Roman