Migrate off Unsafe (guava-jre)

[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.... edit edit: Ah, I'll bet that I saw the problems only under external CI, since we still use -source 8 -target 8 there. Compare this comment.]

Another thing for us to remember is that the way we try to initialize the various helpers 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

[cpovirk]

I'll need to publish a release with the recent changes here, but with that release, I'll consider this to be fixed: When running under Java 9+, guava-jre will no longer use Unsafe. The Unsafe code paths are still there to support Java 8 users, and it's possible that some tools will detect them, but I don't expect any more runtime warnings once users upgrade to the new version.

I assume that someday we'll have to make further changes, perhaps to remove Unsafe code paths entirely or to make similar changes in the Android flavor. But if anyone sees trouble with the new version in practice, let us know.

[cpovirk]

It's possible that we'll want to do something in the Android flavor for users who use it under newer JVMs: Currently, the code would still try to use Unsafe there, and I don't think it would successfully fall back when Unsafe starts throwing exceptions. (And even when Unsafe "only" logs warnings, that's annoying, too.)

We of course recommend using the JRE flavor when running under a JVM. But it can be easy for the Android flavor to sneak in through cross-platform libraries that use it as a dependency. I don't expect it to be especially common, but it will come up.

This might actually be a case for a multi-release jar. But we'd want to see how that would affect Android users. (And I would expect to still find the occasional tool that doesn't understand multi-release jars, perhaps especially in the Android ecosystem, where they are presumably less used.) It's possible that the simpler course of action would be to perform a runtime version check. (We could also catch the exception that Unsafe will throw, but that wouldn't deal with the logging issue.)

[cpovirk]

Currently, the code would still try to use Unsafe there, and I don't think it would successfully fall back when Unsafe starts throwing exceptions.

My mistake: It does fall back successfully. I had been confused with a separate problem, in which an internal utility was trying to preinitialize essentially all the classes in Guava, including UnsafeAtomicHelper, even in environments in which it won't work. We might still change Guava to accommodate that, or we may change the utility.

[cpovirk]

Well... :)

OK, it's still worth noting that, if you use guava-android on a JRE (even after the upcoming release to avoid using Unsafe in guava-jre), recent JVMs would still show you warnings about using Unsafe, as already noted above. So maybe we'll want to do something more for guava-android, whether it involves multi-release jars or a runtime version check.

[cpovirk]

...or maybe including the VarHandle version in guava-android, too, while making sure not to use it from Android. (As I understand things, we'd want to avoid using it even if VarHandle is present: I don't think that VarHandle is actually usable unless the minimum(?) SDK set at build time is high enough to support it—or something like that. And (because of precisely this problem :)) we also haven't evaluated the performance of VarHandle under Android. So if we were to include the VarHandle code in guava-android, it would be (for now) purely for the benefit of JVM users.)

[cpovirk]

(This is still solved for guava-jre as of the forthcoming Guava 33.4.5. The following is only about guava-android.)

Actually, I've been focused mostly on AbstractFuture. Our other Unsafe-using classes don't necessarily have fallbacks (Striped64?), or, if they do, those fallbacks might not trigger properly (LittleEndianByteArray)? UnsignedBytes, like AbstractFuture, is probably fine. But that would be good to verify.

Hmm, I'd run some kind of test of what happens when fallback is off, but maybe I'd ignored the failures in the backport? Or, more likely, they got lost among some other failures from other tools that we use. I do see at least one failure related to Striped64 now, along with what appears to be the expected successful fallback in UnsignedBytes (but our tests don't expect fallback at all at the moment). I'm not sure what's up with LittleEndianByteArray, for which I'd expect to see a failure but seemingly don't.

Anyway, I will still come back to the guava-android question.

[TWiStErRob]

Is there a way to track -android Unsafe usage migration? (Considering this issue is in closed state.)

[cpovirk]

Thanks, I should really have filed a new issue. I've now done that: #7742