RFR: 8289002: Minimal x86_64 VM build fails with GCC 11: 'this' pointer is null

[Alan Bateman]

On Wed, 3 Aug 2022 08:36:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> These build failures are specific to Minimal VM, because it disables "management" feature, and paths like these start to return NULL:
>> 
>> 
>>   static InstanceKlass* com_sun_management_internal_DiagnosticCommandImpl_klass(TRAPS)
>>       NOT_MANAGEMENT_RETURN_(NULL);
>> ``` 
>> 
>> I propose we handle the `NULL`-s properly and throwing early when those are detected. We return/throw what similar code in the affected methods do. I went back and forth with the patch, and settled on throwing from `MemoryManager::get_memory_manager_instance`, and handling the exception at its uses.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug minimal build with GCC 11.3.0
>>  - [x]  Linux x86_64 fastdebug server with GCC 9.3.0, `tier1`
>>  - [x]  Linux x86_64 fastdebug server with GCC 9.3.0, `tier2`
>>  - [x]  Linux x86_64 fastdebug server with GCC 9.3.0, `hotspot_serviceability`
>
> The minimal VM build dates from the compact profiles defined in Java 8. The compact1 and compact2 profiles didn't have the j.l.management APIs so a minimal VM build of libjvm without the "management" code would have been okay. For Java 9+ then a minimal VM build without "management" only make sense when using jlink to create a run-time image that doesn't have the java.management module.

> Thanks Alan (@AlanBateman )! That is what I was reaching for. I guess we lost the actual constraint when we moved to 9 that the Minimal VM cannot be used when the management module is present, as we presumably have no specification for how that module behaves in that case.

There wasn't any real constraint in JDK 8 either, it was just that the minimal VM build was for compact1 and compact2.  It's a topic that I discussed a few times with Bob Vandette but it never rose to the level of something that the module system should support. A jlink plugin (or an update to ExcludeVMPlugin) could detect attempts to create a run-time image that contains both the minimal VM and the java.management module but may not be worth it.

In any case, a run-time image with the minimal VM will fail with exceptions like this:


Exception in thread "main" java.lang.InternalError: Unsupported Management version
	at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
	at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139)
	at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:249)
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2413)
	at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:849)
	at java.base/java.lang.System.loadLibrary(System.java:2045)
	at java.management/java.lang.management.ManagementFactory.lambda$loadNativeLib$8(ManagementFactory.java:1025)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
	at java.management/java.lang.management.ManagementFactory.loadNativeLib(ManagementFactory.java:1024)
	at java.management/java.lang.management.ManagementFactory.<clinit>(ManagementFactory.java:1019)

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

PR: https://git.openjdk.org/jdk/pull/9718