Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make AbstractFuture use VarHandle when available. #7555

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

copybara-service[bot]
Copy link
Contributor

Make AbstractFuture use VarHandle when available.

For now, this is only for the JRE flavor, not for Android.

Our not entirely great benchmarks suggest that this may actually improve performance slightly over the current Unsafe-based implementation. This matches my sense that alternatives to Unsafe have gotten faster.

There are plenty of other places in Guava that we use Unsafe, but this is a start.

Also: I'm going to consider this CL to "fix" #6549, even though:

  • We already started requiring newer versions of Java to build our tests in cl/705512728. (This CL is the first to require a newer JDK to build prod code, again only to build it, not to run it.)
  • This CL requires only Java 9, not Java 11.
  • None of the changes so far should require people who build our Maven project to do anything, since our build automatically downloads a new JDK to use for javac since cl/655647768.
    RELNOTES=n/a

For now, this is only for the JRE flavor, not for Android.

Our not entirely great benchmarks suggest that this may actually improve performance slightly over the current `Unsafe`-based implementation. This matches my sense that [alternatives to `Unsafe` have gotten faster](#6806 (comment)).

There are plenty of other [places in Guava that we use `Unsafe`](#6806), but this is a start.

Also: I'm going to consider this CL to "fix" #6549, even though:
- We already started requiring newer versions of Java to build our _tests_ in cl/705512728. (This CL is the first to require a newer JDK to build _prod_ code, again only to _build_ it, not to _run_ it.)
- This CL requires only Java 9, not Java 11.
- None of the changes so far should require people who _build our Maven project_ to do anything, since our build automatically downloads a new JDK to use for javac since cl/655647768.
RELNOTES=n/a
PiperOrigin-RevId: 702770479
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant