-
Notifications
You must be signed in to change notification settings - Fork 253
8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" #3074
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
Open
sendaoYan
wants to merge
10
commits into
openjdk:master
Choose a base branch
from
openjdk-bots:backport-sendaoYan-fe29cad5-master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
1126ef5
Backport fe29cad5e0b10cd088fc39967599f5a8dcaa445c
254938b
Merge branch 'openjdk:master' into backport-sendaoYan-fe29cad5-master
sendaoYan 6c1eca2
Adopt to jdk11u-dev
sendaoYan a301705
Merge branch 'openjdk:master' into backport-sendaoYan-fe29cad5-master
sendaoYan 40a5efc
Merge branch 'openjdk:master' into backport-sendaoYan-fe29cad5-master
sendaoYan f0ec724
Merge branch 'openjdk:master' into backport-sendaoYan-fe29cad5-master
sendaoYan b90ecf9
Merge branch 'openjdk:master' into backport-sendaoYan-fe29cad5-master
sendaoYan 7a9d65c
Merge branch 'openjdk:master' into backport-sendaoYan-fe29cad5-master
sendaoYan 2bf03c5
Merge branch 'openjdk:master' into backport-sendaoYan-fe29cad5-master
sendaoYan 5b15c3c
Merge branch 'openjdk:master' into backport-sendaoYan-fe29cad5-master
sendaoYan File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the change from System.gc to WB.fullGC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use WB.fullGC instead of System.gc is a good practice sometimes, this will make test more robustness and stable, such as openjdk/jdk#29729.
System.gc() is only a hint to the JVM — it does not guarantee that a full collection runs, that all unreachable objects are collected, or that reference/finalizer processing has completed. In this test that was the root cause of the intermittent failure: after System.gc(), the old code spun on while (wasTrapped < 1), i.e. it proceeded as soon as the first MyObject.finalize() was entered. At that moment other MyObject instances might not yet have been discovered and enqueued for finalization, so FinalizerHistogram could legitimately show no MyObject entries.
WhiteBox.fullGC() (see WB_FullGC in whitebox.cpp) forces a full heap collection with GCCause::_wb_full_gc and clears soft references, so unreachable MyObject instances are actually collected. The follow-up loop on wb.waitForReferenceProcessing() (which delegates to Reference.waitForReferenceProcessing()) then waits until pending reference processing — including work handed off to the finalizer thread — has quiesced (false means no active/pending processing). Only after that do we read the histogram, which matches the test's intent: at least one object blocked in finalize(), with others still waiting in the finalizer queue.
So the change is not “use WhiteBox for fun”; it replaces a racy System.gc() + busy-wait with deterministic GC + reference-processing synchronization, which is the actual fix for JDK-8298783.