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