-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
8311639: Replace currentTimeMillis() with nanoTime() in jtreg/gc #15331
Conversation
👋 Welcome back lkorinth! A progress list of the required criteria for merging this PR into |
Webrevs
|
@@ -77,7 +77,7 @@ class LongLivedAllocationTask extends Exitable implements Runnable { | |||
@Override | |||
public void run() { | |||
while (!shouldExit()) { | |||
String prefix = "long" + System.currentTimeMillis(); | |||
String prefix = "long" + (System.nanoTime() % 10000); // limit to 4 digits after changing from milliseconds to nanoseconds, else the key will use more memory |
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.
Is this used to calculate elapsed time? If not, I think using currentTimeMillis
is fine.
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.
It is not to calculate elapsed time. It is to create a unique(ish) key for a hash table. The new code does not guarantee a unique value, but then neither did the old.
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.
I could possibly add some characters to the key if that is what bothers you. I could of course also use currentTimeMillis
as it is nothing wrong with it. But I would prefer removing currentTimeMillis
in all gc testing.
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.
I will try to see if I can do it without using time at all.
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.
Not using time is probably the best. Not obvious if #digits here is critical. Maybe this is useful -- e.g. to generate fixed 6-digit int:
Random rnd = new Random();
int n = 100_000 + rnd.nextInt(900_000);
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.
I reverted to the original implementation as I did not understand the idea behind it.
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.
Looks good. I'd also go with Albert's suggestion and keep timeout logging in TestSystemGC.
System.out.println("Running with timeout of " + timeout + "ms"); | ||
endTime = System.currentTimeMillis() + timeout; | ||
long timeoutNanos = Integer.parseInt(args[0]) * 1_000_000_000L; | ||
System.out.println("Running with timeout of " + timeoutNanos + "ns"); |
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.
The precision here is in seconds. Maybe just leave this print out to be in ms?
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.
Okay.
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.
I will change it to seconds.
@lkorinth 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 34 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 |
I will refactor a bit more... |
Thanks Albert and StefanK, I will integrate next week. |
/integrate |
Going to push as commit 17a19dc.
Your commit was automatically rebased without conflicts. |
I have removed usage of
currentTimeMillis()
in jtreg/gc ascurrentTimeMillis()
is not monotonic. It is mostly changing from milliseconds to nanoseconds. In certain places, I have changed the code from something like(instant1 < instant2)
to(instant1 - instant2 < 0)
It might look like I am removing instant2 from both sides of the inequality and the result ought to be the same, but due to overflow arithmetic, the change should be better if nanoseconds where to overflow. I have also removed some loops where the loop is doing nothing except sleeping. I somewhat shortened the string in the key of a hash map because the nanosecond value made the string too long for the heap size.All tests within jtreg/gc passes.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15331/head:pull/15331
$ git checkout pull/15331
Update a local copy of the PR:
$ git checkout pull/15331
$ git pull https://git.openjdk.org/jdk.git pull/15331/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 15331
View PR using the GUI difftool:
$ git pr show -t 15331
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15331.diff
Webrev
Link to Webrev Comment