-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8298783: java/lang/ref/FinalizerHistogramTest.java failed with "RuntimeException: MyObject is not found in test output" #24143
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
Conversation
👋 Welcome back bchristi! A progress list of the required criteria for merging this PR into |
@bchristi-git This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 62 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
@bchristi-git The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
The The test then prints out the contents of this internal queue and expects that there be at least one more In the cases where this intermittently fails, what seems to be happening is that, out of the numerous As noted, this is a test bug because in its current form, there's no guarantee that the internal The proposed change here updates the test in such a way that we wait for at least 2 instances of I think the overall idea/change to this test looks good to me. I do have a comment about the implementation detail of this change which I've added inline. |
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.
Thank you Brent for the updates. Good catch on the PhantomReference
usage in the test. The latest changes look good to me.
lock.lock(); | ||
} | ||
} | ||
|
||
public static void main(String[] argvs) { | ||
try { | ||
lock.lock(); | ||
for(int i = 0; i < objectsCount; ++i) { | ||
refQForTwo = new RefQForTwo(new MyObject(), new MyObject()); | ||
for(int i = 2; i < OBJECTS_COUNT; ++i) { |
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.
for(int i = 2; i < OBJECTS_COUNT; ++i) { | |
for (int i = 2; i < OBJECTS_COUNT; ++i) { |
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.
Still looks good to me.
} | ||
System.out.println("ref1Cleared: " + refQForTwo.ref1Cleared); | ||
System.out.println("ref2Cleared: " + refQForTwo.ref2Cleared); | ||
System.out.println("trappedCount.intValue(): " + trappedCount.intValue()); |
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.
This could be made completely reliable, and much simpler, by using WhiteBox.
Don't introduce RefQForTwo. (It doesn't provide reliable information.)
Use WhiteBox::fullGC() to trigger finalization, instead of ForceGC.
Use (new) WhiteBox::waitForReferenceProcessing() to wait until the
FinalReferences have been enqueued (and mostly trapped in the queue).
do { | ||
refProResult = wb.waitForReferenceProcessing(); | ||
System.out.println("waitForReferenceProcessing returned: " + refProResult); | ||
} while (refProResult); |
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 spammy output? Why not just
while (wb.waitForReferenceProcessing()) {}
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.
Right now, the test just it prints a single line:
waitForReferenceProcessing returned: false
and I expect this to continue to be true.
For intermittently failing tests, I'm inclined to add a little extra output as long as I'm fiddling with it anyway. That way, if the test ever starts failing again, we have some (hopefully useful) clues about what happened.
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.
Right now, the test just it prints a single line:
waitForReferenceProcessing returned: false
and I expect this to continue to be true.
If reference processing is being slow because of load, that will be different.
For intermittently failing tests, I'm inclined to add a little extra output as long as I'm fiddling with it anyway. That way, if the test ever starts failing again, we have some (hopefully useful) clues about what happened.
OK.
/integrate |
Going to push as commit fe29cad.
Your commit was automatically rebased without conflicts. |
@bchristi-git Pushed as commit fe29cad. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
I propose some cleanups to
FinalizerHistogramTest.java
to hopefully clear up the intermittent failures:othervm
: this test blocks the (global) finalizer thread, and also requires the (global) finalizer thread to enter the test'sfinalize()
methodvolatile
ints, but sets them based on their current value, which is not reliable; convert toAtomicInteger
PhantomReference
s to ensure that at least twoMyObject
s have become unreachable. If one is stuck infinalize()
, at least one is still waiting to be finalized and should show up in the histogram.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24143/head:pull/24143
$ git checkout pull/24143
Update a local copy of the PR:
$ git checkout pull/24143
$ git pull https://git.openjdk.org/jdk.git pull/24143/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 24143
View PR using the GUI difftool:
$ git pr show -t 24143
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24143.diff
Using Webrev
Link to Webrev Comment