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

Merged
merged 1 commit into from
Jan 3, 2025

Conversation

copybara-service[bot]
Copy link
Contributor

@copybara-service copybara-service bot commented Dec 17, 2024

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.)
  • We already started requiring newer versions of Java to build our GWT module in cl/711487270.
  • 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 (aside from GWT users), 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.)
- We already started requiring newer versions of Java to build our _GWT_ module in cl/711487270.
- 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 (aside from GWT users), since our build automatically downloads a new JDK to use for javac since cl/655647768.
RELNOTES=n/a
PiperOrigin-RevId: 711733182
@copybara-service copybara-service bot merged commit 1a300f6 into master Jan 3, 2025
1 check passed
@copybara-service copybara-service bot deleted the test_702770479 branch January 3, 2025 14:28
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