5 ms·

> This guide is mainly intended for expert programmers familiar with Java concurrency, but unfamiliar with the memory order modes available in JDK 9 provided by

> This guide is mainly intended for expert programmers familiar with Java concurrency, but unfamiliar with the memory order modes available in JDK 9 provided by VarHandles. I think it's important to emphasise this. You should think extremely carefully before reaching for features like these and should have a very good reason for not using the existing concurrency tools and data structures. That said, if you do need to build your own concurrent data structures then these do provide excellent primitives with which to do it.

derefr 10y ago
Right; the proper consumer of material like this (for anything other than intellectual-curiosity purposes) isn't your regular line-of-business developer; it's more the the developers of the concurrency libraries such developers consume, e.g. actor frameworks like Akka or Vert.x.
- aardvark179 10y ago
  I was going to say it was even more limited than that, but vert.x does seem to have quite a few uses of AtomicLong, Integer, and Boolean which could be replaced by primitive fields and VarHandles. Whether it's worth it depends on how many of them are actually used at run time and whether removing the extra indirection and footprint is important. It also makes heavy use of the JDK's concurrent maps, latches, and other structures which it would probably be unwise to try and re-implement.
  - axiak 10y ago
    Those uses of AtomicFoo classes could probably be updated to use AtomicFooUpdater fields (e.g. AtomicIntegerFieldUpdater). VarHandle is like AtomicFieldUpdater but with all of the concurrency semantics that were accessible only via Unsafe access.
    - _old_dude_ 10y ago
      In Java 9, all updaters have been rewritten in term of VarHandle. All reference updaters are less efficient that their VarHandle counterparts because they rely on generics. In Java generics are erased at runtime, so the reference updater code has some supplementary runtime checks.
      - sreque 10y ago
        This isn't correct. The atomic updater classes don't rely on generics to do anything. What they do is perform safety checks on every access to ensure you don't segfault your JVM, resulting in heavy performance losses compared to sun.misc.Unsafe.
        xxs 10y ago
        Actually it is true (about generics and erasure) when it comes to AtomicReferenceFieldUpdater. The check is likely to be around 1 cpu cycle since the branch is virtually always predicted.
        _old_dude_ 10y ago
        It can be one mov + cmp + je in assembly, but it's not always the case. It's an instanceof check, if the class of the field is final (or can be proven to be effectively final by CHA) then it's a null check follow by a pointer check. Theoretically, the null check can proved to be unnecessary, be fused with another or be transformed to an implicitly nullcheck but in specific the case of an AtomicReferenceFieldUpdater, null is usually a valid value (by example, null is used as tombstone in many concurrent data structure implementations) so it's usually more than just a getClass() and a pointer check.
        sreque 10y ago
        From what I've read, until recently this wasn't actually the case for the field updater classes. Instead, Java does things like not trusting your fields' finality and not treating anything as constant. Let me see if I can find the blog post. Here we go: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=atomic+field+updater+optimizations+java+8&* https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...

derefr 10y ago

Right; the proper consumer of material like this (for anything other than intellectual-curiosity purposes) isn't your regular line-of-business developer; it's more the the developers of the concurrency libraries such developers consume, e.g. actor frameworks like Akka or Vert.x.

aardvark179 10y ago
I was going to say it was even more limited than that, but vert.x does seem to have quite a few uses of AtomicLong, Integer, and Boolean which could be replaced by primitive fields and VarHandles. Whether it's worth it depends on how many of them are actually used at run time and whether removing the extra indirection and footprint is important. It also makes heavy use of the JDK's concurrent maps, latches, and other structures which it would probably be unwise to try and re-implement.
- axiak 10y ago
  Those uses of AtomicFoo classes could probably be updated to use AtomicFooUpdater fields (e.g. AtomicIntegerFieldUpdater). VarHandle is like AtomicFieldUpdater but with all of the concurrency semantics that were accessible only via Unsafe access.
  - _old_dude_ 10y ago
    In Java 9, all updaters have been rewritten in term of VarHandle. All reference updaters are less efficient that their VarHandle counterparts because they rely on generics. In Java generics are erased at runtime, so the reference updater code has some supplementary runtime checks.
    - sreque 10y ago
      This isn't correct. The atomic updater classes don't rely on generics to do anything. What they do is perform safety checks on every access to ensure you don't segfault your JVM, resulting in heavy performance losses compared to sun.misc.Unsafe.
      - xxs 10y ago
        Actually it is true (about generics and erasure) when it comes to AtomicReferenceFieldUpdater. The check is likely to be around 1 cpu cycle since the branch is virtually always predicted.
        _old_dude_ 10y ago
        It can be one mov + cmp + je in assembly, but it's not always the case. It's an instanceof check, if the class of the field is final (or can be proven to be effectively final by CHA) then it's a null check follow by a pointer check. Theoretically, the null check can proved to be unnecessary, be fused with another or be transformed to an implicitly nullcheck but in specific the case of an AtomicReferenceFieldUpdater, null is usually a valid value (by example, null is used as tombstone in many concurrent data structure implementations) so it's usually more than just a getClass() and a pointer check.
        sreque 10y ago
        From what I've read, until recently this wasn't actually the case for the field updater classes. Instead, Java does things like not trusting your fields' finality and not treating anything as constant. Let me see if I can find the blog post. Here we go: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=atomic+field+updater+optimizations+java+8&* https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e...