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

[Erik Österlund]

Hi Andrew and Roman,

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. In you experience, 
have you ever observed a difference in any application or benchmark, due 
to the less than handful paths in the interpreter having a slightly 
suboptimal barrier being used? If so, I could change my mind.

Thanks,
/Erik

On 2018-06-27 12:44, Andrew Haley wrote:
> On 06/27/2018 11:42 AM, Roman Kennke wrote:
>
>> It should be noted that normal loads and stores are already covered
>> by the Access API, and we emit the correct read- and write
>> barriers. This is about a few places that don't easily fit that
>> model and still require barriers. That is monitor enter/exit (need
>> WBs anyway) and a few intrinsics, in the interpreter only
>> CRC32. This requires an RB on the buffer array. Yeah, it's probably
>> OK to emit WB there too. If it's really hot, it'd be compiled by C1
>> or C2.
> Right, but as you correctly note we'll have exactly the same
> discussion about C1, with the same points made.
>