Skip to content
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

8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java fails intermittently on Windows #10822

Closed
wants to merge 6 commits into from

Conversation

coleenp
Copy link
Contributor

@coleenp coleenp commented Oct 21, 2022

I added another semaphore so the test will run in the order I want it to. Alternate suggestions or corrections welcome.
Running with GHA, and our tier1 in progress.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java fails intermittently on Windows

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10822/head:pull/10822
$ git checkout pull/10822

Update a local copy of the PR:
$ git checkout pull/10822
$ git pull https://git.openjdk.org/jdk pull/10822/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10822

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10822.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Oct 21, 2022

👋 Welcome back coleenp! 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 openjdk bot added the rfr Pull request is ready for review label Oct 21, 2022
@openjdk
Copy link

openjdk bot commented Oct 21, 2022

@coleenp The following label will be automatically applied to this pull request:

  • hotspot-runtime

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.

@openjdk openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label Oct 21, 2022
@mlbridge
Copy link

mlbridge bot commented Oct 21, 2022

Webrevs

Copy link
Contributor

@pchilano pchilano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. But I think mainSync is not needed now. Thread 1 will always get to wait() before Thread 2 reaches the notify() call while loading D, so that should be enough to avoid the lost notification issue.

@openjdk
Copy link

openjdk bot commented Oct 21, 2022

@coleenp 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:

8295713: runtime/ParallelLoad/SuperWait/SuperWaitTest.java fails intermittently on Windows

Reviewed-by: pchilanomate, dholmes

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 59 new commits pushed to the master branch:

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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Oct 21, 2022
@coleenp
Copy link
Contributor Author

coleenp commented Oct 21, 2022

Thanks Patricio, I don't need mainSync anymore because the first thread will wait.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your are doing an unconditional wait() which in theory could be affected by a spurious wakeup. If you actually do:

while (!DisLoading) {
  wait();
}

with a corresponding

DisLoading = true;
notify();

then I think you could dispense with the semaphore altogether.

…loader locked region, and guard against spuriouss wakeups.
@coleenp
Copy link
Contributor Author

coleenp commented Oct 24, 2022

I need to both handle 1. the spurious wakeup from wait(), and 2. the case where the second thread loads everything, and then the first thread then waits, after D's notification - the missed notification.

@dholmes-ora
Copy link
Member

I need to both handle 1. the spurious wakeup from wait(), and 2. the case where the second thread loads everything, and then the first thread then waits, after D's notification - the missed notification.

That is what DIsLoaded indicates. There's no missed notification because you won't wait if D is already loaded.

@coleenp
Copy link
Contributor Author

coleenp commented Oct 25, 2022

It won't test what I'm trying to test though, but maybe it's ok. I added the test for illustrative purposes.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry Coleen some of the intermediate changes here confused me. The original use of mainSync is slowing down thread1 (loading A) so that it can't proceed until thread 2 starts to load C and has the lock of L2 (which sets up the potential deadlock scenario). That could be added back in conjunction with the dIsLoaded usage. In both cases thread 2 could always get to go first and load C and D before thread 1 has a chance to do anything.

@@ -36,19 +36,17 @@

public class SuperWaitTest {

private static Semaphore mainSync = null;
private static volatile boolean dIsLoading = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't need to be volatile as it is only accessed under the classloader lock.

@coleenp
Copy link
Contributor Author

coleenp commented Oct 25, 2022

My n-1 change makes thread 2 wait for loading C and D until thread1 is in the locked region for loading A (which was the deadlock scenario before the wait() is introduced). It doesn't really matter if thread 2 goes first with the dIsLoading change. Either way, the test will complete and not miss a notify.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay this seems fine from a logic perspective. There's one nit below that I missed before but up to you whether to change it.
Thanks.

@@ -36,19 +36,17 @@

public class SuperWaitTest {

private static Semaphore mainSync = null;
private static boolean dIsLoading = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: sorry just noticed the placement here. This is really an instance field of MyLoaderOne.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed it.

@coleenp
Copy link
Contributor Author

coleenp commented Oct 26, 2022

Thanks for the reviews Patricio and David.
/integrate

@openjdk
Copy link

openjdk bot commented Oct 26, 2022

Going to push as commit a8450b3.
Since your change was applied there have been 59 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Oct 26, 2022
@openjdk openjdk bot closed this Oct 26, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Oct 26, 2022
@openjdk
Copy link

openjdk bot commented Oct 26, 2022

@coleenp Pushed as commit a8450b3.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@coleenp coleenp deleted the loading-tests branch October 26, 2022 18:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime hotspot-runtime-dev@openjdk.org integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

3 participants