Ping: RFR: JDK-8205523: Explicit barriers for interpreter
rkennke at redhat.com
Mon Jul 2 11:56:37 UTC 2018
>> 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.
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.
2. introduce same pattern for resolve() in runtime (and later, c1 and c2).
What do you think?
More information about the hotspot-dev