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
8273790: Potential cyclic dependencies between Gregorian and CalendarSystem #5683
Conversation
|
Webrevs
|
@@ -120,7 +120,17 @@ private static void initNames() { | |||
* @return the <code>Gregorian</code> instance | |||
*/ | |||
public static Gregorian getGregorianCalendar() { | |||
return GREGORIAN_INSTANCE; | |||
var gCal = GREGORIAN_INSTANCE; |
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.
Do we need the local variable gCal
?
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 was there to avoid additional volatile reads in that method. A performance optimization. However, with the change Roger suggested, this is no longer relevant.
* @run main/othervm CalendarSystemDeadLockTest | ||
* @run main/othervm CalendarSystemDeadLockTest | ||
* @run main/othervm CalendarSystemDeadLockTest | ||
* @run main/othervm CalendarSystemDeadLockTest |
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.
Just curious, before the fix, how many test instances caused the deadlock? I'd think these 5 runs are arbitrary numbers, Just wanted to have those 5 runs are appropriate.
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.
Hello @naotoj,
On my setup, without the fix, the test deadlocks almost always right on the first run. There have been cases where it did pass the first time, but running it a second time has always reproduced the failure. The 5 runs that I have in this test is indeed an arbitrary number. Given how quickly this test completes, I decided to use a slightly higher number of 5 instead of maybe 2 or 3. Do you think, we should change the run count to something else?
// add a couple of tasks which directly invoke sun.util.calendar.CalendarSystem#getGregorianCalendar() | ||
tasks.add(new GetGregorianCalTask(taskTriggerLatch)); | ||
tasks.add(new GetGregorianCalTask(taskTriggerLatch)); | ||
final ExecutorService executor = Executors.newFixedThreadPool(tasks.size()); |
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.
Asserting tasks.size() == numTasks
may help here.
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.
Yes, that makes sense. I've updated the test to add this check.
} | ||
} | ||
} | ||
} |
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.
Need a new line at the EOF.
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.
Done. I've updated this in the latest version of the PR.
As an alternative, can the Gregorian Instance be moved to a nested (static) class. |
Hello Roger,
I did indeed have that in mind when I started work on this. That was something Chris Hegarty had suggested and we have used in a different (but similar) issue a while back[1]. I was however unsure if that's a common enough technique, so had started off with the volatile approach. I've now updated the PR to use the holder technique instead. [1] #2893 (comment) |
@jaikiran Thanks for fixing this. Delaying instance creation via a static holder class seems reasonable to me.
@jaikiran This change now passes all automated pre-integration checks. 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 22 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.
|
Thank you Roger, Naoto and Yi Yang for the reviews. |
/integrate |
Going to push as commit ddc2627.
Your commit was automatically rebased without conflicts. |
Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
As noted in that issue, trying to class load
sun.util.calendar.CalendarSystem
andsun.util.calendar.Gregorian
concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:sun.util.calendar.CalendarSystem
.CalendarSystem
.sun.util.calendar.Gregorian
class.Gregorian
.CalendarSystem
attempts to loadGregorian
since it wants to create a (singleton) instance ofGregorian
and assign it to thestatic final GREGORIAN_INSTANCE
member. Since T2 is holding a class init lock onGregorian
, T1 ends up waitingGregorian
class.Gregorian
itself "is a"CalendarSystem
, so during this loading ofGregorian
class, T2 starts travelling up the class hierarchy and asks for a lock onCalendarSystem
. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.The linked JBS issue has a thread dump which shows this in action.
The commit here delays the instance creation of
Gregorian
by moving that instance creation logic from the static initialization of theCalendarSystem
class, to the first call toCalendarSystem#getGregorianCalendar()
. This prevents theCalendarSystem
from needing a lock onGregorian
during its static init (of course, unless some code in this static init flow callsCalendarSystem#getGregorianCalendar()
, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to
CalendarSystem#getGregorianCalendar()
orCalendarSystem#forName()
. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5683/head:pull/5683
$ git checkout pull/5683
Update a local copy of the PR:
$ git checkout pull/5683
$ git pull https://git.openjdk.java.net/jdk pull/5683/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5683
View PR using the GUI difftool:
$ git pr show -t 5683
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5683.diff