Unsafe.getObject() doesn't get loop hoisted in C2

Christian Thalinger christian.thalinger at oracle.com
Mon Jan 28 18:19:10 PST 2013


On Jan 1, 2013, at 3:57 AM, Aaron Grunthal <aaron.grunthal at infinite-source.de> wrote:

> While trying to optimize the JRuby runtime I've run into a field that's declared volatile but would benefit from non-volatile accesses for some important read operations.
> 
> I've tried to use Unsafe.getObject to achieve identical semantics to a non-volatile field access, but it seems like hotspot C2 cannot perform loop invariant code motion on getObject. I.e. it's losing one of the major performance benefits of non-volatile accesses since the volatile read itself is not that expensive, at least on x86.
> 
> My alternative is to declare the field as non-volatile and use Unsafe for volatile/atomic access in all other places, but this is something I would like to avoid as it seems more brittle than using getObject only in a few places (like CHM does for example).
> 
> The question is whether this is intentional or something that should be fixed?

My guess is that C2 emits a memory barrier.  I suggest to read LibraryCallKit::inline_unsafe_access.

-- Chris

> 
> - Aaron
> 
> test + disassembly : https://gist.github.com/4420897#file-test-java
> compilable test: https://gist.github.com/4426366
> Originally reported in concurrency-interest:
> http://cs.oswego.edu/pipermail/concurrency-interest/2013-January/010520.html



More information about the hotspot-dev mailing list