RFR: 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call
Anton Kozlov
akozlov at azul.com
Wed Oct 9 16:24:16 UTC 2019
Hi Mandy,
thanks for the review!
Updated webrev with fixes:
http://cr.openjdk.java.net/~akozlov/8231584/webrev.03/
Few notes below:
On 08.10.2019 01:20, Mandy Chung wrote:
> I think another way doing it is to initialize ClassLoader.sys_paths and usr_paths fields at System::initPhase1. These static fields can be initialized after the library path system properties are set and before calling VM.initLevel(1). ClassLoader::loadLibrary can assert if sys_path and usr_paths are non-null.
Agree with this. A more natural place would be phase3, where system class loader is initialized. But something from phase2 loads a library.
> I prefer to name the test and directory with the API it verifies. For example rename the directory to loadLibrary and rename the test files to
Renamed, full path to the test is java/lang/Runtime/loadLibrary/LoadLibraryTest, as the issue involves Runtime.loadLibrary in first place.
> 70 static void exitPassed() {
> 71 System.exit(95);
> 72 }
>
> 94 // Finish the test
> 95 exitPassed();
>
>
> Is there a better way to finish up the test? someLibrary does not exist. Can it handshake by setting a global state that Target::<clinit> can validate and expect UnsatisfiedLinkError to be thrown?
Thanks, changed this way. A mark is stored in TestClassLoader after findLibrary passed after the point of deadlock. The mark is checked in the end of the test.
Thanks,
Anton
More information about the core-libs-dev
mailing list