Migrate off Unsafe

[koundinyarvs]

The following classes are using sun.misc.Unsafe

com.google.common.cache.Striped64
com.google.common.hash.LittleEndianByteArray
com.google.common.primitives.UnsignedBytes
com.google.common.util.concurrent.AbstractFuture

class sun.misc.Unsafe is a jdk internal class. package sun.misc is jdk internal after jdk 8. In jdk16, --illegal-access=deny was default. This option is ignored in jdk 17. usage context: run method declaration (return type) 

Refer http://openjdk.java.net/jeps/260

[cpovirk]

Can you provide some information about what problem you're seeing? We have included fallback implementations for cases in which Unsafe is not available—except, it appears, perhaps not for Striped64. I would expect for those normally to automatically kick in. Are you using some kind of static analyzer that flags the Unsafe usages?

[koundinyarvs]

Hi @cpovirk

Yes we are using a static analyzer to see what are the packages that java 17 doesn't like to expose usage of CLASS sun.misc.Unsafe and it is identifying
Striped64
LittleEndianByteArray
UnsignedBytes
AbstractFuture
As some classes in guava which are using sun.misc.Unsafe and this needs to be avoided
The analyzer is complaining that

class sun.misc.Unsafe is a jdk internal class. package sun.misc is jdk internal after jdk 8. In jdk16, --illegal-access=deny was default. This option is ignored in jdk 17. usage context: sun.misc.Unsafe.getUnsafe call

[cpovirk]

Is there something that we can put on our code to suppress the static analyzer for the classes that have a fallback implementation? If we can do that without adding any dependencies, then we'd probably do it.

We probably should look at Striped64. (Note that it's part of common.cache, and as always, we encourage people to use Caffeine for caching nowadays.)

[cpovirk]

On the Striped64 front:

The ViewCVS frontend for the jsr166 repo has been offline for a while now, I believe. But the command-line instructions still work. The repo includes a copy of Striped64 that uses MethodHandle+VarHandle, so we could use that if we don't want to figure things out ourselves.

Or perhaps we just want to use LongAdder? As noted, that might cause trouble for GWT/J2CL, but we could use supersource. As also hinted there, it would cause trouble for Android, too, if it were the only approach (since the class isn't available there until API Level 24). But it would be fine with a fallback to Unsafe.

[marcphilipp]

JDK 24-ea+26 or later now issues this warning by default (see MNG-8399 for all of them):

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper (file:/home/marc/.asdf/installs/maven/3.9.9/lib/guava-33.2.1-jre.jar)
WARNING: Please consider reporting this to the maintainers of class com.google.common.util.concurrent.AbstractFuture$UnsafeAtomicHelper
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release 

For now, it can be suppressed using --sun-misc-unsafe-memory-access=allow but according to JEP 498 that's going to change in "JDK 26 or later".

[cpovirk]

Thanks. Our current JDK@head project is SecurityManager, which you've probably seen produce similar warnings :) I imagine that this one will be in our sights soon. We'll compare performance of the various AtomicHelper implementations under various JDKs and then see if we should reorder them, introduce a new one (VarHandle-based?), or what.

[cpovirk]

We have an existing benchmark (in Caliper, sadly, rather than JMH) for single-threaded use of AbstractFuture. The difference between the existing Unsafe implementation and the existing AtomicReferenceFieldUpdater version is mostly hard to detect in the noise, but Unsafe has a noticeable advantage for a benchmark that merely repeatedly creates, sets, and gets. (Both implementations are at least clearly better than the fallback synchronized-based implementation.)

The only immediate takeaway from that is that we can't just flip our default to the AtomicReferenceFieldUpdater implementation today. But we can still eventually see about using VarHandle, and we can see about making our AtomicReferenceFieldUpdater-typed fields static, which I believe should allow for better optimization.

[cpovirk]

static does appear to eliminate the performance difference in the simple test. Further benchmarking is of course needed. [edit: I wonder if I messed this up? Comments in the source suggest that I should have seen access problems that forced fallback to the synchronized implementation, but then I didn't see results that slow....]

Another thing for us to remember is that the way we try to initialize the various helers with try-catch is probably wrong. I would hope that defaulting to our AtomicReferenceFieldUpdater implementation would actually be the safest move there, since that implementation should never fail to load (aside from the old Samsung bug—though perhaps it could make things worse there?).

[cpovirk]

Initial benchmarks for VarHandle also look promising. However, they do make me worry more about the try-catch approach, since an attempt to use VarHandle under Java 8 would fail. We could probably still do it if we guard it with reflection to look at whether VarHandle exists.

[ben-manes]

AtomicReferenceFieldUpdater became much faster in OpenJDK's lead up to VarHandles, whereas in Java 5 it was slow due to reflection and allocations at every invocation, iirc. If that helps here is Shiplev's discussion on it using JHM:
Faster Atomic*FieldUpdaters for Everyone