Skip to content

Conversation

@rm-gh-8
Copy link
Contributor

@rm-gh-8 rm-gh-8 commented Jan 8, 2026

Backporting JDK-8369611: Remove safepoint synchronization from ParallelScavengeHeap and SerialHeap

This PR removes unnecessary conditional STS (Safepoint Thread Synchronization) code from ParallelScavengeHeap and SerialHeap. The cleanup is possible because StringDedup threads are now derived from JavaThread (changed in JDK-8369392), eliminating the need for special conditional synchronization logic that was previously required when StringDedup threads had different threading characteristics.

This backport has internal demand.

Ran related tests on linux-x64, linux-aarch64, macos-aarch64 and windows-x64:

make test TEST=test/hotspot/jtreg/vmTestbase/gc

Results attached:

windows-x64-specific-test.log
macos-aarch64-specific-test.log
linux-x64-specific-test.log
linux-aarch64-specific-test.log


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • JDK-8369611 needs maintainer approval

Issue

  • JDK-8369611: Remove safepoint synchronization from ParallelScavengeHeap and SerialHeap (Enhancement - P4 - Requested)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk25u-dev.git pull/136/head:pull/136
$ git checkout pull/136

Update a local copy of the PR:
$ git checkout pull/136
$ git pull https://git.openjdk.org/jdk25u-dev.git pull/136/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 136

View PR using the GUI difftool:
$ git pr show -t 136

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk25u-dev/pull/136.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 8, 2026

👋 Welcome back rm-gh-8! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Jan 8, 2026

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk bot changed the title Backport 551cd03b99feb34d98703b7d04571f92f83f2471 8369611: Remove safepoint synchronization from ParallelScavengeHeap and SerialHeap Jan 8, 2026
@openjdk
Copy link

openjdk bot commented Jan 8, 2026

This backport pull request has now been updated with issue from the original commit.

@openjdk openjdk bot added backport Port of a pull request already in a different code base clean Identical backport; no merge resolution required labels Jan 8, 2026
@rm-gh-8 rm-gh-8 marked this pull request as ready for review January 8, 2026 17:04
@openjdk
Copy link

openjdk bot commented Jan 8, 2026

⚠️ @rm-gh-8 This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

@openjdk openjdk bot added the rfr Pull request is ready for review label Jan 8, 2026
@mlbridge
Copy link

mlbridge bot commented Jan 8, 2026

Webrevs

@rm-gh-8
Copy link
Contributor Author

rm-gh-8 commented Jan 8, 2026

/approval request for backport of JDK-8369611: Remove safepoint synchronization from ParallelScavengeHeap and SerialHeap

This PR removes unnecessary conditional STS (Safepoint Thread Synchronization) code from ParallelScavengeHeap and SerialHeap.

This backport has internal demand.

Low risk - Fix is based on previous architectural change (JDK-8369392) with known implications, though any change to safepoint synchronization could affect GC pause times or thread coordination.

@openjdk
Copy link

openjdk bot commented Jan 8, 2026

@rm-gh-8
8369611: The approval request has been created successfully.

@openjdk openjdk bot added the approval Requires approval; will be removed when approval is received label Jan 8, 2026
@GoeLin
Copy link
Member

GoeLin commented Jan 14, 2026

Hi Roland,
you are backporting enhancements and similar. As they are in GC, very central, I would prefer that these rather go to April or July updates, so that they are tested in 26 for some time.

@rm-gh-8
Copy link
Contributor Author

rm-gh-8 commented Jan 14, 2026

Hi Goetz,

The earliest opportunity that meets the maintainers (and product) quality gates would be preferable.

@shipilev
Copy link
Member

This one is one the simpler side, so we can have it in April release, I think? More complicated ones can indeed go into July release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approval Requires approval; will be removed when approval is received backport Port of a pull request already in a different code base clean Identical backport; no merge resolution required rfr Pull request is ready for review

Development

Successfully merging this pull request may close these issues.

3 participants