RFR: 8376106: TestObjectDescription.java intermittent fails Unable to replace class name
This change prevents the counter from overflowing. ### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration. The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990). ### Solution Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples. Testing: - Re-running the test 60 times never results in overflow. ------------- Commit messages: - spelling - improve test reliability Changes: https://git.openjdk.org/jdk/pull/29945/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376106 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29945/head:pull/29945 PR: https://git.openjdk.org/jdk/pull/29945
On Thu, 26 Feb 2026 21:57:13 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
test/jdk/jdk/jfr/event/oldobject/TestClassLoader.java line 42:
40: 41: static byte[] classByteCode = readTestClassBytes(); 42: private int classIdCounter;
Seems an extra whitespace ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29945#discussion_r2862115146
On Thu, 26 Feb 2026 21:57:13 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Hi @roberttoyonaga After apply the proposed patch, test run timed out. [TestObjectDescription.jtr.log](https://github.com/user-attachments/files/25591982/TestObjectDescription.jtr...) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-3970428095
On Fri, 27 Feb 2026 02:54:26 GMT, SendaoYan <syan@openjdk.org> wrote:
After apply the proposed patch, test run timed out.
Thanks for checking! It looks like `testThreadGroupName` timed out. Not related our changes to `testClassName`. The problem is that all the tests in this class, `TestObjectDescription`, rely on probabilistic sampling. So they are flakey. There's a chance that the desired objects never gets sampled. I've pushed another commit disabling TLABs `-XX:-UseTLAB`. This should force each allocation to get sampled. I also reduced the number of allocations per iteration (since sampling is now guaranteed). The only way we can time-out now is if undesired allocations push all the desired allocations out of the leak profiler queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-3973821215
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: Add -XX:-UseTLAB to make sampling more reliable. Whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29945/files - new: https://git.openjdk.org/jdk/pull/29945/files/ec0ec648..66977dc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=00-01 Stats: 14 lines in 2 files changed: 1 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29945/head:pull/29945 PR: https://git.openjdk.org/jdk/pull/29945
On Fri, 27 Feb 2026 16:27:40 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
Add -XX:-UseTLAB to make sampling more reliable. Whitespace.
After apply the new proposed patch, this test run all passed with 1k times. Should we update the copyright year for touched files. ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/29945#pullrequestreview-3869963458 PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-3976172462
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: update copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29945/files - new: https://git.openjdk.org/jdk/pull/29945/files/66977dc1..c972bae5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29945/head:pull/29945 PR: https://git.openjdk.org/jdk/pull/29945
On Mon, 2 Mar 2026 14:08:24 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
update copyright headers
I'm worried that -XX:-UseTLAB will use a code path that is never executed in any real setup. The purpose of the test is not to ensure sampling, but to check the object description. Still, if we have flakiness, it might be better to fix it in a more general way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-3993207211
On Tue, 3 Mar 2026 19:57:32 GMT, Erik Gahlin <egahlin@openjdk.org> wrote:
I'm worried that -XX:-UseTLAB will use a code path that is never executed in any real setup. The purpose of the test is not to ensure sampling, but to check the object description.
If the goal is to test the object description and not the sampling, then why does the path taken to sample matter? Reducing the tlab size rather than disabling tlabs entirely could help, but it still wouldn't guarantee sampling. Are there any other ways? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-3993399189
On Tue, 3 Mar 2026 20:36:58 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
If the goal is to test the object description and not the sampling, then why does the path taken to sample matter?
We don’t use -XX:-UseTLAB in any other OldObjectSample test, so it’s not hard to see that this test could cause false positives in the future. Why doesn’t this test work like the others? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-3997650812
On Mon, 2 Mar 2026 14:08:24 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
update copyright headers
Okay, I've reverted the `-XX:-UseTLAB` change, but kept the change that prevents overrunning the `classIdCounter`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-3999948910
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision: - whitespace - Revert "Add -XX:-UseTLAB to make sampling more reliable. Whitespace." This reverts commit 66977dc19565b4b860fb7e56d4ede7b255f94a77. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29945/files - new: https://git.openjdk.org/jdk/pull/29945/files/c972bae5..0ba7c4d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=02-03 Stats: 13 lines in 1 file changed: 1 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29945/head:pull/29945 PR: https://git.openjdk.org/jdk/pull/29945
On Wed, 4 Mar 2026 20:06:17 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
- whitespace - Revert "Add -XX:-UseTLAB to make sampling more reliable. Whitespace."
This reverts commit 66977dc19565b4b860fb7e56d4ede7b255f94a77.
Looks good, but I don’t think fixing typos in a file not belonging to the fix is confusing. TestClassLoader is used by many tests, and if this fix gets backported, it’s more likely to apply cleanly if we only address the underlying issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4005072308
On Thu, 5 Mar 2026 13:30:04 GMT, Erik Gahlin <egahlin@openjdk.org> wrote:
fixing typos in a file not belonging to the fix is confusing
Yes, I agree. I've reverted the typo correction. The typos originally were in the same file as the `-XX:-UseTLAB` change, but that's since been removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4005222155
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: Revert "spelling" This reverts commit ec0ec64821c95412be6b2deb6a85bd2fae1cf4bf. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29945/files - new: https://git.openjdk.org/jdk/pull/29945/files/0ba7c4d6..5fda529e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29945/head:pull/29945 PR: https://git.openjdk.org/jdk/pull/29945
On Thu, 5 Mar 2026 13:54:46 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
Revert "spelling"
This reverts commit ec0ec64821c95412be6b2deb6a85bd2fae1cf4bf.
The newest proposed patch seems identical to the first one? The newest proposed patch make test always timed out. test/jdk/jdk/jfr/event/oldobject/TestObjectDescription.java line 2:
1: /* 2: * Copyright (c) 2018, 2026, Oracle and/or its affiliates. All rights reserved.
This copyright change do not needed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4005436555 PR Review Comment: https://git.openjdk.org/jdk/pull/29945#discussion_r2890298456
On Thu, 5 Mar 2026 14:24:29 GMT, SendaoYan <syan@openjdk.org> wrote:
The newest proposed patch seems identical to the first one? The newest proposed patch make test always timed out.
This is indeed actually the same as the first. We decided earlier above that `-XX:-UseTLAB ` was not the right approach. The goal of this PR has been scoped down to only preventing the original problem of overrunning the counter, not reducing the flaky-ness of the leak sampling. We need to figure out a different approach to improving leak sampling reliability (across all the oldobject tests), which can probably be done in a separate fix. Are you seeing the test time out for every single run, or is it just still being flakey? I'm running it repeatedly on amd64 linux and haven't seen it time out yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4006381410
On Thu, 5 Mar 2026 16:48:50 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
The newest proposed patch seems identical to the first one? The newest proposed patch make test always timed out.
This is indeed actually the same as the first. We decided earlier above that `-XX:-UseTLAB ` was not the right approach. The goal of this PR has been scoped down to only preventing the original problem of overrunning the counter, not reducing the flaky-ness of the leak sampling. We need to figure out a different approach to improving leak sampling reliability (across all the oldobject tests), which can probably be done in a separate fix.
Are you seeing the test time out for every single run, or is it just still being flakey? I'm running it repeatedly on amd64 linux and haven't seen it time out yet.
One reason for the timeout could be that the test consists of several tests that are repeated. Most other tests only have a single repeat loop. Anyway, I think this is better fixed separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4016885602
On Sat, 7 Mar 2026 16:43:10 GMT, Erik Gahlin <egahlin@openjdk.org> wrote:
Are you seeing the test time out for every single run, or is it just still being flakey? I'm running it repeatedly on amd64 linux and haven't seen it time out yet.
The timed out fails always reproducable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4023642313
On Mon, 9 Mar 2026 13:07:09 GMT, SendaoYan <syan@openjdk.org> wrote:
I runed the test 5 times, 4 times passed, the rest one timed out.
[run-3.log](https://github.com/user-attachments/files/25843794/run-3.log)
@sendaoYan, Looks like it timed out on iteration 2003, this is the same as we were originally seeing. Are you certain this is on the latest commit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4024103978
On Mon, 9 Mar 2026 14:15:49 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
I runed the test 5 times, 4 times passed, the rest one timed out. [run-3.log](https://github.com/user-attachments/files/25843794/run-3.log)
@sendaoYan, Looks like it timed out on iteration 2003, this is the same as we were originally seeing. Are you certain this is on the latest commit?
Sorry, I forgot to apply the patch. I will try tormorrow ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4024581472
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision: copyright TestObjectDescription ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29945/files - new: https://git.openjdk.org/jdk/pull/29945/files/5fda529e..86603c40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29945/head:pull/29945 PR: https://git.openjdk.org/jdk/pull/29945
On Thu, 5 Mar 2026 15:08:46 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
copyright TestObjectDescription
Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29945#pullrequestreview-3909113506
On Thu, 5 Mar 2026 15:08:46 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
copyright TestObjectDescription
Thank you for the reviews!
Anyway, I think this is better fixed separately.
I created an issue here to track fixing the test sampling unpredictability https://bugs.openjdk.org/browse/JDK-8379519 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4023879409
On Thu, 5 Mar 2026 15:08:46 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
copyright TestObjectDescription
@roberttoyonaga Your change (at version 86603c4094d8dd1b07cfb1f21a8055b87ea75702) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4023900679
On Thu, 5 Mar 2026 15:08:46 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
This change prevents the counter from overflowing.
### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration.
The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990).
### Solution
Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples.
Testing: - Re-running the test 60 times never results in overflow.
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
copyright TestObjectDescription
I run the test 5 times, and all the test timed out. [run-5.log](https://github.com/user-attachments/files/25857476/run-5.log) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4028107443
On Tue, 10 Mar 2026 02:08:58 GMT, SendaoYan <syan@openjdk.org> wrote:
I run the test 5 times, and all the tests timed out. [run-5.log](https://github.com/user-attachments/files/25857476/run-5.log)
Looks like the time out is in `testThreadGroupName` again, not related to the counter overflow in `testClassName`. We can try to resolve this in https://bugs.openjdk.org/browse/JDK-8379519 Can you please sponsor this integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4031252925
On Tue, 10 Mar 2026 13:06:13 GMT, Robert Toyonaga <duke@openjdk.org> wrote:
I run the test 5 times, and all the tests timed out. [run-5.log](https://github.com/user-attachments/files/25857476/run-5.log)
Looks like the time out is in `testThreadGroupName` again, not related to the counter overflow in `testClassName`. We can try to resolve this in https://bugs.openjdk.org/browse/JDK-8379519
Can you please sponsor this integration?
Before this PR, this test fail intermittent; After this PR, this PR fails always on ours test machines. @egahlin Can you check the oracle's CI results after this apply this proposed patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29945#issuecomment-4031598359
participants (4)
-
duke
-
Erik Gahlin
-
Robert Toyonaga
-
SendaoYan