RFR: 8266310: deadlock while loading the JNI code [v6]

Mandy Chung mchung at openjdk.java.net
Mon Jun 14 18:42:59 UTC 2021


On Fri, 11 Jun 2021 10:00:14 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java line 84:
>> 
>>> 82: 
>>> 83:     private static OutputAnalyzer createJar(String outputJar, String... classes) throws Throwable {
>>> 84:         String jar = JDKToolFinder.getJDKTool("jar");
>> 
>> You can consider using `jdk.test.lib.util.JarUtils` to reduce the test execution time so that it can create the jar without exec'ing another process.
>
> I tried, but this doesn't work that well unfortunately with JarUtils.createJar() as it only produces a valid jar-file capable of triggering the issue when the compiled class files (jtreg @build output) are in the same directory as the current directory of the process calling JarUtils.createJar(). Jtreg @build outputs the compiled classes to a separate directory. Creation of a new jar process allows to change the current directory so that the relative paths to the class files are such that it would form the valid output jar-file. Alternatively we could copy the class files to the current directory prior to creating the jar-file, but that would introduce an extra step. Would you mind me keeping the createJar() in the test?

Is `jar -C <dir>` option what you want?   FYI.  `jar` tool is a tool provider which is a simple way to run `jar` tool in process (lookup the tool provider by calling `ToolProvider.findFirst("jar")`).

Yes I am fine with what you have if this does not work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976


More information about the core-libs-dev mailing list