Skip to content
This repository has been archived by the owner on Sep 2, 2022. It is now read-only.
/ jdk17 Public archive

JDK-8266310: deadlock between System.loadLibrary and JNI FindClass loading another class #96

Closed
wants to merge 1 commit into from

Conversation

voitylov
Copy link

@voitylov voitylov commented Jun 18, 2021

Resubmitting the following PR openjdk/jdk#3976 against JDK17.

This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.

Further details can be found in the original PR.

Testing: jtreg and jck testing with no regressions. A new regression test was developed.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8266310: deadlock between System.loadLibrary and JNI FindClass loading another class

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk17 pull/96/head:pull/96
$ git checkout pull/96

Update a local copy of the PR:
$ git checkout pull/96
$ git pull https://git.openjdk.java.net/jdk17 pull/96/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 96

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk17/pull/96.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 18, 2021

👋 Welcome back avoitylov! 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 Jun 18, 2021
@openjdk
Copy link

openjdk bot commented Jun 18, 2021

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

  • core-libs

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 core-libs core-libs-dev@openjdk.java.net label Jun 18, 2021
@mlbridge
Copy link

mlbridge bot commented Jun 18, 2021

Webrevs

Copy link
Member

@mlchung mlchung 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.

@openjdk
Copy link

openjdk bot commented Jun 18, 2021

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

8266310: deadlock between System.loadLibrary and JNI FindClass loading another class

Reviewed-by: mchung, dholmes, chegar

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

  • 1323be5: 8269064: Dropped messages of AsyncLogWriter cause memleak
  • ce917b2: 8269148: Update minor GCC version in GitHub Actions pipeline
  • ab7ff1e: 8266885: [aarch64] Crash with 'Field too big for insn' for some tests under compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/
  • 35e4c27: 8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"
  • dc12cb7: 8267652: c2 loop unrolling by 8 results in reading memory past array
  • 578c55b: 8267399: C2: java/text/Normalizer/ConformanceTest.java test failed with assertion
  • 8fa2520: 8268888: Upstream 8268230: Foreign Linker API & Windows user32/kernel32: String conversion seems broken
  • 9ec7180: 8268524: nmethod::post_compiled_method_load_event racingly called on zombie
  • 01f12fb: 8266631: StandardJavaFileManager: getJavaFileObjects() impl violates the spec
  • 6b14c8a: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling
  • ... and 28 more: https://git.openjdk.java.net/jdk17/compare/7ed3634da81b53135c89aa82a1a5d2f4de2c6c5e...master

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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@mlchung, @dholmes-ora, @ChrisHegarty) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jun 18, 2021
@AlanBateman
Copy link
Contributor

@voitylov JDK 17 is an RDP 1 and I wonder if this long standing issue is critical or not. I've skimmed through the changes and I don't see any issue but if this is really intended for openjdk/jdk17 then I think it would be useful to have more eyes on it.

@mlchung
Copy link
Member

mlchung commented Jun 21, 2021

@dholmes-ora @ChrisHegarty @plevart reviewed PR openjdk/jdk#3976. Can you re-review this PR?

@voitylov
Copy link
Author

@AlanBateman I think it's worth to be included in JDK17 because in case someone hits this (like netty), the impact is high (a framework or an application can't start) and there is no viable workaround without rewriting code. The scope of change in the last version, at the same time, is limited.

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.

I've re-reviewed the locking aspect of this, but can't comment on the NativeLibraryContext changes.

Thanks,
David

@voitylov
Copy link
Author

Thank you @mlchung @dholmes-ora @ChrisHegarty for re-reviews.

@AlanBateman is it ok with you?

@AlanBateman
Copy link
Contributor

@AlanBateman is it ok with you?

Okay with me but as a general point I don't think we should be fixing long standing issues in risky areas during RDP1. This is a change that really needs several months of bake time.

@mlchung
Copy link
Member

mlchung commented Jun 24, 2021

This is a risky area and I agree it needs some bake time. The fix has been ready for some time but it takes longer than we hope to get this reviewed and approved (I was one causing the delay). I am not uncomfortable getting this in JDK 17 but I will not object if others think this should be fixed in JDK 18 (and backport to 17 update if desirable) as this is a long standing issue and no urgency to get this fixed.

@mlbridge
Copy link

mlbridge bot commented Jun 25, 2021

Mailing list message from Chris Hegarty on core-libs-dev:

On 24 Jun 2021, at 22:27, Mandy Chung <mchung at openjdk.java.net> wrote:

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.

This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.

Further details can be found in the original PR.

Testing: jtreg and jck testing with no regressions. A new regression test was developed.

This is a risky area and I agree it needs some bake time. The fix has been ready for some time but it takes longer than we hope to get this reviewed and approved (I was one causing the delay). I am not uncomfortable getting this in JDK 17 but I will not object if others think this should be fixed in JDK 18 (and backport to 17 update if desirable) as this is a long standing issue and no urgency to get this fixed.

Fixing initially in 18, allowing some ?bake? time, then considering a backport to a 17 update, seems prudent.

-Chris.

1 similar comment
@mlbridge
Copy link

mlbridge bot commented Jun 25, 2021

Mailing list message from Chris Hegarty on core-libs-dev:

On 24 Jun 2021, at 22:27, Mandy Chung <mchung at openjdk.java.net> wrote:

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against JDK17.

This fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.

Further details can be found in the original PR.

Testing: jtreg and jck testing with no regressions. A new regression test was developed.

This is a risky area and I agree it needs some bake time. The fix has been ready for some time but it takes longer than we hope to get this reviewed and approved (I was one causing the delay). I am not uncomfortable getting this in JDK 17 but I will not object if others think this should be fixed in JDK 18 (and backport to 17 update if desirable) as this is a long standing issue and no urgency to get this fixed.

Fixing initially in 18, allowing some ?bake? time, then considering a backport to a 17 update, seems prudent.

-Chris.

@voitylov
Copy link
Author

OK, let it bake in 18 first.

@voitylov voitylov closed this Jun 25, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
core-libs core-libs-dev@openjdk.java.net ready Pull request is ready to be integrated rfr Pull request is ready for review
5 participants