Extensions for OpenJDK 11 for Eclipse OpenJ9
License: GNU General Public License v2.0
For details of how to build Eclipse OpenJ9 see https://github.com/eclipse-openj9/openj9/tree/master/doc/build-instructions.
I downloaded the source file from https://github.com/ibmruntimes/openj9-openjdk-jdk11/archive/jdk-11.0.1+13.tar.gz. Seems it missed some files under directory closed/ , get_source.sh and README.md.
Is that work as design?
Builds are missing the java*.properties files that should be present in the image/jdk/lib directory.
Assuming its broken for jdk11 since ibmruntimes/openj9-openjdk-jdk#17
This failure is intermittent, and I've been seeing it more often lately.
https://ci.eclipse.org/openj9/job/Build-JDK11-linux_390-64_cmprssptrs/542
01:08:38 Compiling 3086 files for java.base
01:08:39 Creating ct.sym classes
01:08:51 error: module not found: jdk.hotspot.agent
01:08:51 Creating support/symbols/ct.sym
01:09:03 ar: creating apps/libapps.a
01:09:03 ar: creating libssl.a
01:09:03 ar: creating test/libtestutil.a
01:09:10 ar: creating libcrypto.a
01:09:14 Staging OpenJ9 sourcetools in /home/jenkins/jenkins-agent/workspace/Build-JDK11-linux_390-64_cmprssptrs/build/linux-s390x-normal-server-release/vm
01:09:14 Overriding jvm.cfg with J9VM version
01:09:14 /bin/ln: failed to create symbolic link '/home/jenkins/jenkins-agent/workspace/Build-JDK11-linux_390-64_cmprssptrs/build/linux-s390x-normal-server-release/jdk/lib/jvm.cfg': File exists
01:09:14 make[3]: *** [/home/jenkins/jenkins-agent/workspace/Build-JDK11-linux_390-64_cmprssptrs/build/linux-s390x-normal-server-release/jdk/lib/jvm.cfg] Error 1
01:09:14 make[3]: *** Deleting file '/home/jenkins/jenkins-agent/workspace/Build-JDK11-linux_390-64_cmprssptrs/build/linux-s390x-normal-server-release/jdk/lib/jvm.cfg'
01:09:14 ModuleWrapper.gmk:72: recipe for target '/home/jenkins/jenkins-agent/workspace/Build-JDK11-linux_390-64_cmprssptrs/build/linux-s390x-normal-server-release/jdk/lib/jvm.cfg' failed
01:09:14 make/Main.gmk:162: recipe for target 'java.base-copy' failed
01:09:14 make[2]: *** [java.base-copy] Error 1
The jsig.lib file should be included in the lib directory.
The java implementation of crypto is not performing very well with openJ9-OpenJDK build. To improve the crypto performance, native implementation can be used.
OpenSSL is an open source crypto TLS/SSL implementation [https://www.openssl.org/] and it is well established and stable native implementation used with enterprise applications. The source code is available at https://github.com/openssl/openssl.
The proposal is to use the OpenSSL crypto algorithms with OpenJ9-OpenJDK for better performance.
The design approach is to provide a switch in the existing security providers to switch to the native crypto implementation instead of creating a new security provider.
In the first phase, three crypto algorithms from OpenSSL are enabled for the native crypto. They are Digest [only SHA algorithms], Cipher Block Chaining [CBC] and Galois Counter Mode [GCM]. We can consider enabling more algorithms from OpenSSL in future.
The native crypto implementation is disabled by default and can be enabled using one or more of the following properties.
-Djdk.nativeCrypto=true
-Djdk.nativeDigest=true
-Djdk.nativeCBC=true
-Djdk.nativeGCM=true
If all three crypto algorithms from openssl to be enabled, use jdk.nativeCrypto. If any specific crypto algorithms only or its combinations to be enabled, use the corresponding property [jdk.nativeDigest, jdk.nativeCBC or jdk. nativeGCM]. Once the native implementation is stable, we can consider enabling them by default.
From the driver programs of the Digest [sun/security/provider/SunEntries], CBC and GCM [com/sun/crypto/provider/CipherCore] algorithms, check for the new property and switch to the native implementation.
A java interface [jdk.crypto.jniprovider.NativeCrypto] is introduced to call the JNI program [native/jdk/crypto /jniprovider/NativeCrypto.c] which act as a native wrapper program to make openssl calls for the Digest, CBC and GCM algorithms.
The high level design approach for implementing the openssl support is added as an attachment.
OpenJDK_NativeCrypto_DesignApproach.pptx
Specific version of openssl source can be cloned from the github based on the version specified with get_source.sh using --openssl-version=1.1.xx. Currently, only the latest version [1.1.xx] is supported. We can consider supporting other versions later. If openssl-version is not specified, openssl source does not get downloaded. If the openssl-version is specified, it will check if the same version is already available in standard download location SRC_DIR/openssl. If same version exists, it will skip downloading the source. Otherwise, it cleanup the openssl directory and download the source.
While configuring, user can select the openssl directory which is used for building opendk and whether the openssl crypto library [libcrypto.so] needs to be included in jre/lib/arch path.
The configure option --with-openssl can be used to select the openssl directory. The user can specify three options:
fetched - to use the downloaded openssl source.
system - to use the package installed openssl library
path to openssl library - to use a custom openssl library already built.
By default, the openssl crypto library[libcrypto.so] is not bundled with JDK build. If user wants to include the crypto library while building openj9-openjdk, they can use the option --enable-openssl-bundling. The openj9-openjdk8 build systems (AdoptOpenJDK and Eclipse OpenJ9 CI) can use the property --enable-openssl-bundling to include the crypto library with JDK which makes it easier for the Java users to exploit openssl crypto as otherwise, they have to build/install the openssl library in the target system.
A new library libjncrypto [where jn stands for java-native] is introduced to include the NativeCrypto object module. The libcrypto is dynamically linked to libjncrypto so that user has the flexibility to decide whether the crypto libraries need to be bundled with the JDK or not.
With the openssl support, the user is able to build OpenJDK_8-Eclipse_OpenJ9 with and without openssl.
For developers who want to continue without openssl, they can continue to do so without making any changes.
For developers who want to generate JDK with openssl can use the option '--with-openssl=path_to_crypto_library | fetched | system'
For developers who want to generate JDK with openssl and bundle the crypto library with JDK build can use the options -with-openssl= and --enable-openssl-bundling
In order to merge the openssl support change-set, there is no build environment dependency for AdoptOpenJDK and Eclipse OpenJ9. When ever, we install the pre-built openssl binaries in the build system and enable the property, it started building JDK with openssl support. Till then it continue to build the JDK as it was before.
Create the issue for tracking the OpenJDK exclude tests list updates for Java Restricted Security Mode.
In the Java Restricted Security Mode, the not allowed providers will not be loaded from the ServiceLoader. So, those test cases which create or add its own providers will definately failed when running the extended.openjdk tests. Add those test cases into the exclude list, so those test cases will be excluded when running the extended.openjdk tests.
I'm trying to build Java 11 with downloading sources from
https://github.com/ibmruntimes/openj9-openjdk-jdk11/archive/openj9-0.11.zip
https://github.com/eclipse/openj9-omr/archive/openj9-0.11.0.tar.gz
https://github.com/eclipse/openj9/archive/openj9-0.11.0.zip
There is no .git directory in zip file. BUT seems java 11 build depends on information under .git dir, like getting component(OMR/OpenJ9/JCL) version from the last commit id or tag.
Can you create releases for the OpenJ9 release branch, like openj9-0.11? Then we can use zip/tar files directly for build.
On AIX, use following code to get the default charset. On AIX, by default, it is IS8859-1. If I specify -Dfile.encoding=Cp037, it returned UTF-8 as default charset. But with Java 8, it could return IBM037 as default.
public class CheckVM {
public static void main(String[] args) {
System.out.println("Default Charset: " + Charset.defaultCharset());
}
}
Following an issue: eclipse-openj9/openj9#5530 which was resolved a strange error is now reported 'loadquery failed (12 Not enough space)`. A fix needs to be identified and contributed to the upstream projects in order to not display this error message.
Error message seen during a JDK11 OpenJ9 build:
Generating DDR pointer and structure class files
Exception in thread "main" java.lang.RuntimeException: Failed to load alias map from resource: /com/ibm/j9ddr/StructureAliases29.dat - cannot continue
at com.ibm.j9ddr.StructureReader.loadAliasMapData(StructureReader.java:438)
at com.ibm.j9ddr.StructureReader.loadAliasMap(StructureReader.java:306)
at com.ibm.j9ddr.StructureReader.applyAliases(StructureReader.java:222)
at com.ibm.j9ddr.StructureReader.<init>(StructureReader.java:120)
at com.ibm.j9ddr.tools.ClassGenerator.readBlob(ClassGenerator.java:93)
at com.ibm.j9ddr.tools.ClassGenerator.run(ClassGenerator.java:174)
at com.ibm.j9ddr.tools.ClassGenerator.main(ClassGenerator.java:79)
Link: https://github.com/adamfarley/build-jdk/runs/2722774171?check_suite_focus=true
This error appears to be a regression for this issue, which is supported by the fact that the fix now appears to be missing from the relevant file.
@keithc-ca - Do you know if this fix was removed deliberately?
We are using 2 jre releases for our 2 IBM SPSS Modeler releases:
In MacOS M1 processor MacBook, performances for Modeler 18.4 are drastically bad so that the product can't be used (it takes hours to process what should be done in one minute..)
When we replace JRE by the one from Modeler 18.3, there is no performance issue anymore.
Upgrading to last JRE release https://github.com/ibmruntimes/semeru11-binaries/releases/tag/jdk-11.0.15%2B10_openj9-0.32.0 doesn't fix this issue.
The problem doesn't appear with Intel processor MacBooks.
Let me know if you need further details
https://ci.eclipse.org/openj9/job/Build_JDK11_x86-64_windows_OpenJDK11/65/console
06:43:04 Creating support/test/jdk/jtreg/native/bin/JliLaunchTest.exe from 1 file(s)
06:43:06 ./src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c(113): error C2220: warning treated as error - no 'object' file generated
06:43:06 ./src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c(113): warning C4028: formal parameter 2 different from declaration
06:43:06 make[3]: *** [Lib-jdk.jdwp.agent.gmk:55: /cygdrive/c/Users/jenkins/workspace/Build_JDK11_x86-64_windows_OpenJDK11/build/windows-x86_64-normal-server-release/support/native/jdk.jdwp.agent/libjdwp/linker_md.obj] Error 1
06:43:06 make[2]: *** [make/Main.gmk:215: jdk.jdwp.agent-libs] Error 2
xlc_r -q64 -qmkshrobj -Wl,-brtl -Wl,-G -Wl,-bernotok -Wl,-bnoentry -Wl,-bmap:j9zlib.map -Wl,-bE:j9zlib.exp -L/usr/lib/threads
-L. -L../ -L../lib/ -o ../libj9zlib29.so
zlib_copyright.o adler32.o compress.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o
-lc_r -lm -lpthreads
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_adler32
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_compress
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_compress2
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_crc32
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_deflate
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_deflateCopy
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_deflateEnd
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_deflateInit_
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_deflateInit2_
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_deflateParams
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_deflateReset
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_deflateSetDictionary
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_get_crc_table
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflate
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflateCopy
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflateEnd
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflateInit_
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflateInit2_
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflateReset
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflateSetDictionary
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflateSync
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_inflateSyncPoint
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_uncompress
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_zError
ld: 0711-319 WARNING: Exported symbol not defined: j9zlib_zlibVersion
ld: 0711-244 ERROR: No csects or exported symbols have been saved.
../makelib/targets.mk:359: recipe for target '../libj9zlib29.so' failed
gmake[5]: *** [../libj9zlib29.so] Error 8
gmake[5]: Leaving directory '/home/builder/openj9-openjdk-jdk11/build/aix-ppc64-normal-server-release/vm/zlib'
makefile:101: recipe for target 'j9zlib' failed
gmake[4]: Leaving directory '/home/builder/openj9-openjdk-jdk11/build/aix-ppc64-normal-server-release/vm'
gmake[4]: *** [j9zlib] Error 2
/home/builder/openj9-openjdk-jdk11/closed/OpenJ9.gmk:422: recipe for target 'build-j9' failed
gmake[3]: *** [build-j9] Error 2
/home/builder/openj9-openjdk-jdk11/closed/make/Main.gmk:39: recipe for target 'j9vm-build' failed
gmake[2]: *** [j9vm-build] Error 2
ERROR: Build failed for target 'all' in configuration 'aix-ppc64-normal-server-release' (exit code 2)
=== Make failed targets repeated here ===
../makelib/targets.mk:359: recipe for target '../libj9zlib29.so' failed
makefile:101: recipe for target 'j9zlib' failed
/home/builder/openj9-openjdk-jdk11/closed/OpenJ9.gmk:422: recipe for target 'build-j9' failed
/home/builder/openj9-openjdk-jdk11/closed/make/Main.gmk:39: recipe for target 'j9vm-build' failed
=== End of repeated output ===
Hint: Try searching the build log for the name of the first failed target.
Hint: See doc/building.html#troubleshooting for assistance.
/home/builder/openj9-openjdk-jdk11/make/Init.gmk:300: recipe for target 'main' failed
make[1]: *** [main] Error 2
/home/builder/openj9-openjdk-jdk11/make/Init.gmk:186: recipe for target 'all' failed
make: *** [all] Error 2
It was enabled and then reverted because it caused some build errors. See #230
The issue is opened to include all the changes in JDK11 for eclipse-openj9/openj9#5058 to enable RISCV 64 bit as follows:
#219 , #220, #297
FYI: @keithc-ca, @pshipton , @DanHeidinga
java.management.jmod and jdk.management.jmod on AIX include different classes with HotSpot OpenJDK 11. Does it work as design? If so, I want to know how you passed Java11 regression test on AIX. I found some classes are required by Java 11 regression test.
Some classes are required and I can find the source code, but they are not included in the corresponding jmod files, like java.management.jmod and jdk.management.jmod.
src/jdk.management/share/classes/com/sun/management/VMOption.java
src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java
src/java.management/share/classes/sun/management/HotspotRuntimeMBean.java
src/java.management/share/classes/sun/management/HotspotClassLoadingMBean.java
src/java.management/share/classes/sun/management/LazyCompositeData.java
src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java
src/java.management/share/classes/sun/management/ManagementFactoryHelper.java
src/java.management/share/classes/sun/management/MemoryUsageCompositeData.java
src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java
Result of Openj9 OpenJDK 11 on AIX.:
bash-4.4$ ../bin/jmod list jdk.management.jmod | grep "com/sun/management"
classes/com/sun/management/DiagnosticCommandMBean.class
classes/com/sun/management/GarbageCollectionNotificationInfo.class
classes/com/sun/management/GarbageCollectorMXBean.class
classes/com/sun/management/GcInfo.class
classes/com/sun/management/HotSpotDiagnosticMXBean.class
classes/com/sun/management/OperatingSystemMXBean.class
classes/com/sun/management/ThreadMXBean.class
classes/com/sun/management/UnixOperatingSystemMXBean.class
classes/com/sun/management/internal/GarbageCollectionNotificationInfoUtil.class
classes/com/sun/management/internal/GcInfoUtil$1.class
classes/com/sun/management/internal/GcInfoUtil.class
Result of HotSpot OpenJDK 11 on Mac.:(There is no AIX version, so I tried mac version)
bash-4.2$ ../bin/jmod list jdk.management.jmod | grep "com/sun/management"
classes/com/sun/management/DiagnosticCommandMBean.class
classes/com/sun/management/GarbageCollectionNotificationInfo.class
classes/com/sun/management/GarbageCollectorMXBean.class
classes/com/sun/management/GcInfo.class
classes/com/sun/management/HotSpotDiagnosticMXBean.class
classes/com/sun/management/internal/DiagnosticCommandArgumentInfo.class
classes/com/sun/management/internal/DiagnosticCommandImpl$OperationInfoComparator.class
classes/com/sun/management/internal/DiagnosticCommandImpl$Wrapper.class
classes/com/sun/management/internal/DiagnosticCommandImpl.class
classes/com/sun/management/internal/DiagnosticCommandInfo.class
classes/com/sun/management/internal/Flag$1.class
classes/com/sun/management/internal/Flag.class
classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData$1.class
classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.class
classes/com/sun/management/internal/GarbageCollectorExtImpl.class
classes/com/sun/management/internal/GcInfoBuilder.class
classes/com/sun/management/internal/GcInfoCompositeData$1.class
classes/com/sun/management/internal/GcInfoCompositeData$2.class
classes/com/sun/management/internal/GcInfoCompositeData.class
classes/com/sun/management/internal/HotSpotDiagnostic.class
classes/com/sun/management/internal/HotSpotThreadImpl.class
classes/com/sun/management/internal/OperatingSystemImpl.class
classes/com/sun/management/internal/PlatformMBeanProviderImpl$1.class
classes/com/sun/management/internal/PlatformMBeanProviderImpl$2.class
classes/com/sun/management/internal/PlatformMBeanProviderImpl$3.class
classes/com/sun/management/internal/PlatformMBeanProviderImpl$4.class
classes/com/sun/management/internal/PlatformMBeanProviderImpl$5.class
classes/com/sun/management/internal/PlatformMBeanProviderImpl.class
classes/com/sun/management/internal/VMOptionCompositeData.class
classes/com/sun/management/OperatingSystemMXBean.class
classes/com/sun/management/ThreadMXBean.class
classes/com/sun/management/UnixOperatingSystemMXBean.class
classes/com/sun/management/VMOption$Origin.class
classes/com/sun/management/VMOption.class
Result of Openj9 OpenJDK 11 on AIX.:
bash-4.4$ ../bin/jmod list java.management.jmod | grep "sun/management"
classes/sun/management/Util.class
classes/sun/management/counter/AbstractCounter$Flags.class
classes/sun/management/counter/AbstractCounter.class
classes/sun/management/counter/ByteArrayCounter.class
classes/sun/management/counter/Counter.class
classes/sun/management/counter/LongArrayCounter.class
classes/sun/management/counter/LongCounter.class
classes/sun/management/counter/StringCounter.class
classes/sun/management/counter/Units.class
classes/sun/management/counter/Variability.class
classes/sun/management/counter/perf/ByteArrayCounterSnapshot.class
classes/sun/management/counter/perf/InstrumentationException.class
classes/sun/management/counter/perf/LongArrayCounterSnapshot.class
classes/sun/management/counter/perf/LongCounterSnapshot.class
classes/sun/management/counter/perf/PerfByteArrayCounter.class
classes/sun/management/counter/perf/PerfDataEntry$EntryFieldOffset.class
classes/sun/management/counter/perf/PerfDataEntry.class
classes/sun/management/counter/perf/PerfDataType.class
classes/sun/management/counter/perf/PerfInstrumentation.class
classes/sun/management/counter/perf/PerfLongArrayCounter.class
classes/sun/management/counter/perf/PerfLongCounter.class
classes/sun/management/counter/perf/PerfStringCounter.class
classes/sun/management/counter/perf/Prologue$PrologueFieldOffset.class
classes/sun/management/counter/perf/Prologue.class
classes/sun/management/counter/perf/StringCounterSnapshot.class
classes/sun/management/spi/PlatformMBeanProvider$PlatformComponent.class
classes/sun/management/spi/PlatformMBeanProvider.class
Result of HotSpot OpenJDK 11 on Mac.:
classes/sun/management/BaseOperatingSystemImpl.class
classes/sun/management/ClassLoadingImpl.class
classes/sun/management/CompilationImpl.class
classes/sun/management/CompilerThreadStat.class
classes/sun/management/counter/AbstractCounter$Flags.class
classes/sun/management/counter/AbstractCounter.class
classes/sun/management/counter/ByteArrayCounter.class
classes/sun/management/counter/Counter.class
classes/sun/management/counter/LongArrayCounter.class
classes/sun/management/counter/LongCounter.class
classes/sun/management/counter/perf/ByteArrayCounterSnapshot.class
classes/sun/management/counter/perf/InstrumentationException.class
classes/sun/management/counter/perf/LongArrayCounterSnapshot.class
classes/sun/management/counter/perf/LongCounterSnapshot.class
classes/sun/management/counter/perf/PerfByteArrayCounter.class
classes/sun/management/counter/perf/PerfDataEntry$EntryFieldOffset.class
classes/sun/management/counter/perf/PerfDataEntry.class
classes/sun/management/counter/perf/PerfDataType.class
classes/sun/management/counter/perf/PerfInstrumentation.class
classes/sun/management/counter/perf/PerfLongArrayCounter.class
classes/sun/management/counter/perf/PerfLongCounter.class
classes/sun/management/counter/perf/PerfStringCounter.class
classes/sun/management/counter/perf/Prologue$PrologueFieldOffset.class
classes/sun/management/counter/perf/Prologue.class
classes/sun/management/counter/perf/StringCounterSnapshot.class
classes/sun/management/counter/StringCounter.class
classes/sun/management/counter/Units.class
classes/sun/management/counter/Variability.class
classes/sun/management/GarbageCollectorImpl.class
classes/sun/management/HotspotClassLoading.class
classes/sun/management/HotspotClassLoadingMBean.class
classes/sun/management/HotspotCompilation$CompilerThreadInfo.class
classes/sun/management/HotspotCompilation.class
classes/sun/management/HotspotCompilationMBean.class
classes/sun/management/HotspotInternal.class
classes/sun/management/HotspotInternalMBean.class
classes/sun/management/HotspotMemory.class
classes/sun/management/HotspotMemoryMBean.class
classes/sun/management/HotspotRuntime.class
classes/sun/management/HotspotRuntimeMBean.class
classes/sun/management/HotspotThread.class
classes/sun/management/HotspotThreadMBean.class
classes/sun/management/LazyCompositeData.class
classes/sun/management/LockInfoCompositeData.class
classes/sun/management/ManagementFactoryHelper$1.class
classes/sun/management/ManagementFactoryHelper$2.class
classes/sun/management/ManagementFactoryHelper$3.class
classes/sun/management/ManagementFactoryHelper$LoggingMXBeanAccess$1.class
classes/sun/management/ManagementFactoryHelper$LoggingMXBeanAccess.class
classes/sun/management/ManagementFactoryHelper$PlatformLoggingImpl.class
classes/sun/management/ManagementFactoryHelper.class
classes/sun/management/MappedMXBeanType$ArrayMXBeanType.class
classes/sun/management/MappedMXBeanType$BasicMXBeanType.class
classes/sun/management/MappedMXBeanType$CompositeDataMXBeanType$1.class
classes/sun/management/MappedMXBeanType$CompositeDataMXBeanType$2.class
classes/sun/management/MappedMXBeanType$CompositeDataMXBeanType.class
classes/sun/management/MappedMXBeanType$EnumMXBeanType.class
classes/sun/management/MappedMXBeanType$GenericArrayMXBeanType.class
classes/sun/management/MappedMXBeanType$InProgress.class
classes/sun/management/MappedMXBeanType$ListMXBeanType.class
classes/sun/management/MappedMXBeanType$MapMXBeanType.class
classes/sun/management/MappedMXBeanType.class
classes/sun/management/MemoryImpl.class
classes/sun/management/MemoryManagerImpl.class
classes/sun/management/MemoryNotifInfoCompositeData.class
classes/sun/management/MemoryPoolImpl$CollectionSensor.class
classes/sun/management/MemoryPoolImpl$PoolSensor.class
classes/sun/management/MemoryPoolImpl.class
classes/sun/management/MemoryUsageCompositeData.class
classes/sun/management/MethodInfo.class
classes/sun/management/MonitorInfoCompositeData.class
classes/sun/management/NotificationEmitterSupport$ListenerInfo.class
classes/sun/management/NotificationEmitterSupport.class
classes/sun/management/RuntimeImpl.class
classes/sun/management/Sensor.class
classes/sun/management/spi/PlatformMBeanProvider$PlatformComponent.class
classes/sun/management/spi/PlatformMBeanProvider.class
classes/sun/management/StackTraceElementCompositeData.class
classes/sun/management/ThreadImpl.class
classes/sun/management/ThreadInfoCompositeData$ThreadInfoCompositeTypes.class
classes/sun/management/ThreadInfoCompositeData.class
classes/sun/management/Util.class
classes/sun/management/VMManagement.class
classes/sun/management/VMManagementImpl$1.class
classes/sun/management/VMManagementImpl.class
Hi Cheng Jin,
My host machine is ubuntu 16.04
with gcc and g++ 7.4 on my Host Machine.
I am following your build instructions from the below link to cross compile openj9-openjdk-jdk11 using your private repositories for riscv, while building i am stuck with building errors.
I am following this below thread also
eclipse-openj9/openj9#5058
I am here by attaching my configure and build logs.
Plz correct me if anything wrong with steps.
Plz help me to resolve the issue.
Regards & Thanks
MD SADIQ
Consistent failure with jdk11-openj9 (all generic operating systems)
13:29:44 --- Actual ---
13:29:44 java.base/java.lang.Thread.getStackTrace(Thread.java:1169)
13:29:44 DumpStackTest.consumeLambda(DumpStackTest.java:147)
13:29:44 DumpStackTest.lambda$testLambda$0(DumpStackTest.java:129)
13:29:44 DumpStackTest$$Lambda$3.000000009FE08CD0.accept(Unknown Source)
13:29:44 DumpStackTest.testLambda(DumpStackTest.java:130)
13:29:44 DumpStackTest.main(DumpStackTest.java:45)
13:29:44 java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
13:29:44 java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
13:29:44 java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
13:29:44 java.base/java.lang.reflect.Method.invoke(Method.java:566)
13:29:44 com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
13:29:44 java.base/java.lang.Thread.run(Thread.java:831)
13:29:44 --- Expected ---
13:29:44 java.lang.Thread.getStackTrace(Thread.java)
13:29:44 DumpStackTest.consumeLambda(DumpStackTest.java)
13:29:44 DumpStackTest.lambda$testLambda$0(DumpStackTest.java)
13:29:44 DumpStackTest.testLambda(DumpStackTest.java)
13:29:44 DumpStackTest.main(DumpStackTest.java)
13:29:44 jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java)
13:29:44 jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java)
13:29:44 jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java)
13:29:44 java.lang.reflect.Method.invoke(Method.java)
13:29:44 java.lang.Thread.run(Thread.java)
13:29:44 STDERR:
13:29:44 java.lang.RuntimeException: StackTraceElements mismatch at index 3. Expected [DumpStackTest.testLambda(DumpStackTest.java)], but get [DumpStackTest$$Lambda$3.000000009FE08CD0.accept(Unknown Source)]
13:29:44 at DumpStackTest.assertEquals(DumpStackTest.java:227)
13:29:44 at DumpStackTest.assertStackTrace(DumpStackTest.java:219)
13:29:44 at DumpStackTest.consumeLambda(DumpStackTest.java:147)
13:29:44 at DumpStackTest.lambda$testLambda$0(DumpStackTest.java:129)
13:29:44 at DumpStackTest$$Lambda$3.000000009FE08CD0.accept(Unknown Source)
13:29:44 at DumpStackTest.testLambda(DumpStackTest.java:130)
13:29:44 at DumpStackTest.main(DumpStackTest.java:45)
13:29:44 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
13:29:44 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
13:29:44 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
13:29:44 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
13:29:44 at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
13:29:44 at java.base/java.lang.Thread.run(Thread.java:831)
13:29:44
13:29:44 JavaTest Message: Test threw exception: java.lang.RuntimeException: StackTraceElements mismatch at index 3. Expected [DumpStackTest.testLambda(DumpStackTest.java)], but get [DumpStackTest$$Lambda$3.000000009FE08CD0.accept(Unknown Source)]
13:29:44 JavaTest Message: shutting down test
The issue is a failed assertEquals() caused by an unexpected call frame in the consumeLambda() test.
ACTUAL:
DumpStackTest$$Lambda$3.000000009FE08CD0.accept(Unknown Source)
EXPECTED:
DumpStackTest.testLambda(DumpStackTest.java)
As you can see above, while the test does find the right call frame, the unknown element replaces it's expected position in the stack, causing the failure.
(On line 279)
By default, JUnit5 ignore those tests
References: https://rules.sonarsource.com/java/tag/junit/RSPEC-5810
Support was added for openssl 1.0.2, however some older OSes like RHEL 6 and Debian 8 are still using the 1.0.1 version. When OpenJDK + OpenJ9 runs on these older OSes, a supported version of openssl is unlikely to be found. The crypto will revert to the java implementation which doesn't perform well with OpenJ9.
There is a version check in the openssl support code. This can be modified to accept the 1.0.1 version as well, and then run testing to confirm if it is working.
See also adoptium/temurin-build#1039
When running the cleaner thread creation in the security provider "SunPKCS11" of module "jdk.crypto.cryptoki", and meanwhile the security manager is enabled. The access denied error "Caused by: java.security.AccessControlException: Access denied ("java.lang.RuntimePermission" "getClassLoader")" happens.
The FIPS mode has restrictive security providers, so update the OpenJDK exclude tests list “ProblemList-fips.txt” for the FIPS testing, after jdk_security3 test target enabled.
Using gcc 7.3. Ref: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-linux-s390x-openj9/52/console until that expires.
Had to switch to using --with-openssl=fetched instead of --with-openssl=/usr/local/openssl-1.1.1 (which we use for building JDK8 on Linux/s390x) due to #80
Compiling 224 properties into resource bundles for jdk.localedata
Compiling 1 properties into resource bundles for jdk.jlink
Compiling 67 files for COMPILE_CREATE_SYMBOLS
Creating ct.sym classes
error: module not found: jdk.hotspot.agent
Creating support/symbols/ct.sym
Compiling 3085 files for java.base
ar: creating apps/libapps.a
crypto/sha/keccak1600-s390x.S: Assembler messages:
crypto/sha/keccak1600-s390x.S:356: Error: operand out of range (0xfffffffffffffff8 is not between 0x0000000000000000 and 0x0000000000000fff)
Makefile:4903: recipe for target 'crypto/sha/keccak1600-s390x.o' failed
gmake[5]: *** [crypto/sha/keccak1600-s390x.o] Error 1
gmake[5]: *** Waiting for unfinished jobs....
Makefile:171: recipe for target 'all' failed
gmake[4]: *** [all] Error 2
gmake[3]: *** [build_openssl] Error 1
/data/jenkins/workspace/build-scripts/jobs/jdk11u/jdk11u-linux-s390x-openj9/workspace/build/src/closed/openssl.gmk:41: recipe for target 'build_openssl' failed
/data/jenkins/workspace/build-scripts/jobs/jdk11u/jdk11u-linux-s390x-openj9/workspace/build/src/closed/make/Main.gmk:42: recipe for target 'openssl-build' failed
gmake[2]: *** [openssl-build] Error 2
New test cmdLineTester_CryptoTest is created to test OpenSSL natives are being loaded properly. The test passed on other platforms, but it failed on osx and windows jdk11 with message Warning: Native crypto library load failed. Using Java crypto implementation
osx jdk8 also failed. windows jdk8 worked as expected.
Please see comment for detail: eclipse-openj9/openj9#4376 (comment)
#52 copies the jsig library into the places where it should be. It doesn't need to be in the compressedrefs/default directory.
Has been ok on JDK8 but doesn't seem to like the same directory when I point to it in a JDK11 build.
I understand #79 was an initial attempt to fix it.
For now, I've modified the Linux/s390x build at adoptopenjdk to build from source, since that works with JDK11 but not JDK8 (Ref: adoptium/temurin-build#804)
We should resolve this for the future though.
checking if build directory is on local disk... yes
checking for OPENSSL... configure: error: Unable to find openssl in specified location /usr/local/openssl-1.1.1
no
configure exiting with result code 1
The FIPS mode has restrictive security providers, so update the OpenJDK exclude tests list “ProblemList-fips.txt” for the FIPS testing.
Hi chengjin,
while cross building jdk for riscv i stuck with the following error
config.sub: missing argument
Host machine
ubuntu 16.04
I am attaching my error log.
could you please help to resolve the issue.
Thank you
Snathick
We build a Java11 on IBM i platform. Without adding any specify options related to jdk versions in configuration phase. Following is the output of "java -version".
bash-4.4$ bin/java -version
openjdk version "11.0.1-internal" 2018-10-16
OpenJDK Runtime Environment (build 11.0.1-internal+0-adhoc.gaolibj.openj9-openjdk-jdk11)
Eclipse OpenJ9 VM (build openj9-0.11.0, JRE 11 OS/400 ppc64-64-Bit Compressed References 20190311_000000 (JIT enabled, AOT enabled)
OpenJ9 - 090ff9d
OMR - ea548a6
JCL - d445507 based on jdk-11.0.3+2)
Get source codes with following steps.
The string "11.0.1" 2018-10-16 is hardcoded in file openj9-openjdk-jdk11/make/autoconf/version-numbers as below.
DEFAULT_VERSION_FEATURE=11
DEFAULT_VERSION_INTERIM=0
DEFAULT_VERSION_UPDATE=1
DEFAULT_VERSION_PATCH=0
DEFAULT_VERSION_DATE=2018-10-16
The string jdk-11.0.3+2 is set with OPENJDK_TAG in file
openj9-openjdk-jdk11/closed/autoconf/custom-hook.m4.
AC_DEFUN_ONCE([OPENJDK_VERSION_DETAILS],
[
OPENJDK_SHA=`git -C $TOPDIR rev-parse --short HEAD`
LAST_TAGGED_SHA=`git -C $TOPDIR rev-list --tags="jdk-11*" --topo-order --max-count=1 2>/dev/null`
if test "x$LAST_TAGGED_SHA" != x; then
OPENJDK_TAG=`git -C $TOPDIR describe --tags "$LAST_TAGGED_SHA"`
else
OPENJDK_TAG=
fi
AC_SUBST(OPENJDK_SHA)
AC_SUBST(OPENJDK_TAG)
# Outer [ ] to quote m4.
[ USERNAME=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` ]
AC_SUBST(USERNAME)
])
I want to know why it's different. We only work on branch openj9-0.11.
If change the command as below, it can get string ”jdk-11.0.1+13" instead of ”jdk-11.0.3+2".
bash-4.4$ git describe --tags git rev-list -1 openj9-0.11
jdk-11.0.1+13-654-gd445507
We want these two versions to be consistent like it on AIX.
bash-4.4$ bin/java -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.2+9)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.12.1, JRE 11 AIX ppc64-64-Bit Compressed References 20190204_121 (JIT enabled, AOT enabled)
OpenJ9 - 90dd8cb
OMR - d2f4534
JCL - 289c70b based on jdk-11.0.2+9)
I know there are some options can be used to effect version string, like --with-version-date,--with-version-string and --with-version-. But seems it will not effect OPENJDK_TAG.
How can I make the version numbers be consistent? Thanks.
MessageDigest openssl acceleration was disabled due to eclipse-openj9/openj9#4530. This issue tracks fixing the problems and re-enabling MessageDigest openssl support.
https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/564/console
18:34:00 -jdk:"/home/jenkins/workspace/Grinder/openjdkbinary/j2sdk-image/bin/.."
18:34:00 -exclude:"/home/jenkins/workspace/Grinder/openjdk-tests/TestConfig/scripts/testKitGen/../../../../jvmtest/openjdk_regression/ProblemList_openjdk11-openj9.txt"
18:34:00 "/home/jenkins/workspace/Grinder/openjdk-tests/TestConfig/scripts/testKitGen/../../../openjdk_regression/openjdk-jdk/test/hotspot/jtreg/runtime/Nestmates";
18:34:00 if [ $? -eq 0 ] ; then echo ""; echo "runtime_nestmate_0""_PASSED"; echo ""; cd /home/jenkins/workspace/Grinder/openjdk-tests/TestConfig/scripts/testKitGen/../../..; else echo ""; echo "runtime_nestmate_0""_FAILED"; echo ""; fi; } 2>&1 | tee -a "/home/jenkins/workspace/Grinder/openjdk-tests/TestConfig/scripts/testKitGen/../../../TestConfig/test_output_15445496393623/TestTargetResult";
18:34:03 Directory "/home/jenkins/workspace/Grinder/openjdk-tests/TestConfig/scripts/testKitGen/../../../../jvmtest/openjdk_regression/work" not found: creating
18:34:03 Directory "/home/jenkins/workspace/Grinder/openjdk-tests/TestConfig/scripts/testKitGen/../../../../jvmtest/openjdk_regression/report" not found: creating
18:34:14 Exception while calling user-specified class: requires.VMProps
18:34:14 java.lang.UnsatisfiedLinkError: sun/hotspot/WhiteBox.registerNatives()V
18:34:14 at sun.hotspot.WhiteBox.(WhiteBox.java:66)
18:34:14 at requires.VMProps.(VMProps.java:57)
18:34:14 at java.base/java.lang.Class.forNameImpl(Native Method)
18:34:14 at java.base/java.lang.Class.forName(Class.java:339)
18:34:14 at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:78)
18:34:14 at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:54)
18:34:14 Error: failed to get JDK properties for /home/jenkins/workspace/Grinder/openjdkbinary/j2sdk-image/bin/../bin/java -ea -esa -Xmx512m -Xcompressedrefs; exit code 1
Should same changes as 8023785#diff-d8b9c32ba7ff50cca3a301dcfe5cb243 fix this?
autoconf always picks 32-bit MSVC toolchain even if 64-bit ones are available. By switching to 64-bit toolchain, the compilation time is significantly reduced. Disassembly of JIT dll generates by 32-bit and 64-bit toolchains confirms identical codes have been generated.
To avoid having to consider the precedence of --with-mixedrefs (introduced in #359) and --with-noncompressedrefs, we should introduce a new configure option --with-references=[full|compressed|mixed-static|mixed-dynamic] to cover all reference representation modes.
Proposed by @keithc-ca (#359 (review)).
These changes will need to go in each of the extensions repos.
More mixed builds discussion: eclipse-openj9/openj9#8878
An interim release is required at AdoptOpenJDK for Windows and Mac to include openssl 1.1.1d (update from 1.1.1a).
This AdoptOpenJDK release will be jdk-11.0.5+10.1_openj9-0.17.0, essentially a repackage of the jdk-11.0.5+10_openj9-0.17.0 release which includes openssl 1.1.1a.
This requires updates to the build scripts and playbooks at AdoptOpenJDK and also a change to the openj9-openjdk-jdk11 openj9-0.17.0 branch to set the extensions repository fix version (displayed via java -Xinternal version) to 11.0.5.1 to distinguish the release from the jdk-11.0.5+10_openj9-0.17.0 release, extensions version 11.0.5.0.
The openj9-0.14.2 branch has been created for the creation of the jdk-11.0.3+7_openj9-0.14.2 adoptopenjdk.
It was created from the openj9-0-14.0 branch with just the changes to check out the openj9-0-14-2 tags from the eclipse/openj9 and eclipse/omr repositories and to update the extensions version.
This issue is to define which additional commits need to be included in this release.
(Note that the commit which created the openj9-0.14.2 branch has the commit message "Create openj9-0.14.0 branch" in error.
There is a potential problem in code like the following. It may be possible for the RSAPublicKeyImpl to be finalized and the nativePtr freed while the native code is using it.
The solution is to use a try{ } finally to put a call to java.lang.ref.Reference.reachabilityFence(key); after the native call. Or for Java 8, java.nio.Bits.keepAlive(key);.
The eclipse/openj9 and eclipse/openj9-omr openj9-0.15.0-m1 milestone tags have been created.
An openj9-0.15.0 branch needs to be created in this repository to build the correct levels of openj9 and openjdk for the jdk11 July quarterly update.
The most recent jdk11 openj9 acceptance testing job https://ci.eclipse.org/openj9/job/Pipeline-OpenJDK11-Acceptance/26/ successfully merged openj9-staging into openj9 following a successful build + test run.
@pshipton - please can you confirm
Hi,
This may not be the right place to put this issue, but I'm not 100% sure, what the root cause is.
I have a Java EE application, that access a DB2 on IBM cloud and the application used to work w/o issues.
The application uses the Liberty for Java Buildpack.
With the recent update of the Buildpack the application fails to connect to the database.
I was able to track the issue down to the change in the used Java JRE. With ibm-semeru-open-jre_x64_linux_11.0.14.1_1_openj9-0.30.1 all is fine. And with the current ibm-semeru-open-jre_x64_linux_11.0.15_10_openj9-0.32.0 I see messages like this:
[INFO] Caused by: com.ibm.db2.jcc.am.SqlException: [jcc][t4][20133][12451][4.29.24] Caught NoSuchAlgorithmException while doing SSL Connection. See attached Throwable for details. ERRORCODE=-4499, SQLSTATE=null
[INFO] at com.ibm.db2.jcc.am.b7.a(b7.java:794)
[INFO] at com.ibm.db2.jcc.am.b7.a(b7.java:66)
[INFO] at com.ibm.db2.jcc.am.b7.a(b7.java:98)
[INFO] at com.ibm.db2.jcc.t4.w.run(w.java:287)
[INFO] at java.base/java.security.AccessController.doPrivileged(AccessController.java:747)
[INFO] at com.ibm.db2.jcc.t4.a0.a(a0.java:435)
[INFO] ... 28 more
[INFO] Caused by: java.security.NoSuchAlgorithmException: SSL_TLSv2 SSLContext not available
[INFO] at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
[INFO] at java.base/javax.net.ssl.SSLContext.getInstance(SSLContext.java:168)
[INFO] at com.ibm.db2.jcc.t4.w.run(w.java:141)
[INFO] ... 30 more
Here is some sample code that reflects the issue:
public static Connection getConnectionToDatabase() throws SQLException {
final var jdbcString = "jdbc:db2://HOSTNAME.databases.appdomain.cloud:31322/bludb:"
+ "user=USERNAME;" + "password=PASSWORD;" +
"sslConnection=true;" +
"traceLevel=TRACE_ALL;" +
"traceFile=jcctrace;";
var conn = DriverManager.getConnection(jdbcString);
System.out.println("Connected to database");
return conn;
}The trace file shows the same message regarding the NoSuchAlgorithmException.
Any help or hint is appreciated.
adoptium/aqa-tests#585
Test fails on all OS's for jdk11-openj9 due to an assertEquals() fail
10:49:12 java.lang.RuntimeException: Expected: app/[email protected]/com.acme.Widget.frobnicate(Widget.java:42) but found: jdk.module/com.acme.Widget.frobnicate(Widget.java:42)
10:49:12 at PublicConstructor.assertEquals(PublicConstructor.java:92)
10:49:12 at PublicConstructor.testConstructorWithModule(PublicConstructor.java:86)
10:49:12 at PublicConstructor.main(PublicConstructor.java:36)
10:49:12 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:49:12 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
10:49:12 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
10:49:12 at java.base/java.lang.reflect.Method.invoke(Method.java:566)
10:49:12 at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
10:49:12 at java.base/java.lang.Thread.run(Thread.java:831)
10:49:12
10:49:12 JavaTest Message: Test threw exception: java.lang.RuntimeException
The issue is within printStackTraceElement() which is called when toString() is called in the test. See code below:
public static void printStackTraceElement(StackTraceElement e, Object elementSource, Appendable buf, boolean extended) {
final java.lang.String modName = e.getModuleName();
if (null != modName) {
appendTo(buf, modName);
if (extended) {
String mVer = e.getModuleVersion();
if (null != mVer) {
appendTo(buf, "@"); //$NON-NLS-1$
appendTo(buf, mVer);
}
}
appendTo(buf, "/"); //$NON-NLS-1$
} else if (extended) {
appendTo(buf, "app//"); //$NON-NLS-1$
}
The issue is with the module version, which doesn't get executed due to the extended boolean being declared as false in the StackTraceElement class. See code below:
public String toString() {
StringBuilder buf = new StringBuilder(80);
Util.printStackTraceElement(this, source, buf, false);
return buf.toString();
extended variable to test compatibility with the testIt appears the StackTraceElement.class above was a compiler generated file and as such, can't be edited. The actual method used by the compiler is:
@Override
public String toString() {
String mid = getClassLoaderName(c);
Module module = c.getModule();
if (module.isNamed()) {
ModuleDescriptor md = module.getDescriptor();
mid = md.name();
if (md.version().isPresent())
mid += "@" + md.version().get().toString();
mid += "/";
}
String fileName = getFileName();
int lineNumber = getLineNumber();
String sourceinfo = "Unknown Source";
if (isNativeMethod()) {
sourceinfo = "Native Method";
} else if (fileName != null && lineNumber >= 0) {
sourceinfo = fileName + ":" + lineNumber;
}
return String.format("%s/%s.%s(%s)", mid, getClassName(), getMethodName(),
sourceinfo);
The getProcessCpuLoad() method of class com.sun.management.OperatingSystemMXBean always return -1 (invaild ret value) in the first call, while in the following calls it will get the correct cpu load value.
I tried to call the same function using OpenJDK11 and AdoptOpenJDK11 with Hotspot, and it will return 0 with these JDKs which is within the valid ret value range. So I expect Openj9 should also have the same behavior for the first call. Here is a simple test code that could reproduce the issue:
import java.lang.management.ManagementFactory;
import com.sun.management.OperatingSystemMXBean;
class Test{
public static void main(String[] args) {
while (true) {
try
{
Thread.sleep(10000);
}
catch(InterruptedException ex)
{
Thread.currentThread().interrupt();
}
double cpuUtil = ((com.sun.management.OperatingSystemMXBean) ManagementFactory.getOperatingSystemMXBean()).getProcessCpuLoad();
System.out.println(cpuUtil);
}
}
}The output I got with different JDK variants is:
sidong@sidong-u18-x1:~$ java --version
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Temurin-11.0.12+7 (build 11.0.12+7)
OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode)
sidong@sidong-u18-x1:~$ java Test
0.0
0.001002004008016032
5.00751126690035E-4
0.0010035122930255895
5.00751126690035E-4
5.015045135406219E-4
sidong@sidong-u18-x1:~$ java --version
openjdk 11.0.12 2021-07-20
IBM Semeru Runtime Open Edition 11.0.12.0 (build 11.0.12+7)
Eclipse OpenJ9 VM 11.0.12.0 (build openj9-0.27.0, JRE 11 Linux amd64-64-Bit Compressed References 20210729_228 (JIT enabled, AOT enabled)
OpenJ9 - 1851b0074
OMR - 9db1c870d
JCL - 21849e2ca0 based on jdk-11.0.12+7)
sidong@sidong-u18-x1:~$ java Test
-1.0
0.0031686181725441823
2.0872289188482128E-4
2.556149850413811E-4
3.1896885482841735E-4
1.4443471779581417E-4
2.252603035480593E-4I also tried the previous stable release (11.0.11+9) and the current openj9 branch and the output is similar.
Although ibmruntimes/openj9-openjdk-jdk8 and 9 removed them (ibmruntimes/openj9-openjdk-jdk8#18), a subset of the executables unsupported by OpenJ9 are present in jdk11 (and 10, and jdk) builds.
jinfo
jps
jmap
jstack
jstat
Also
ibmruntimes/openj9-openjdk-jdk10#47
ibmruntimes/openj9-openjdk-jdk#16
@andrew-m-leonard In MethodTypeForm, field names have changed between JDK11 and JDK14. Do we plan to backport the JDK14 MethodTypeForm changes to JDK11 and JDK8?
fyi - @fengxue-IS
Copied from ibmruntimes/openj9-openjdk-jdk8#57
If smt is enabled the correct number of processors is not correct on configure.
There are a number of ways that can be used to determine actual number of processors, I found this works for me on the systems I have access to, smt enabled or not at time of configure
--with-jobs='pmcycles -m | wc -l | awk '{print $1}''
Running regression tests and got:
04:55:29 Exception in thread "main" java.lang.UnsatisfiedLinkError: sun/hotspot/WhiteBox.registerNatives()V
04:55:29 at sun.hotspot.WhiteBox.(WhiteBox.java:66)
04:55:29 at requires.VMProps.(VMProps.java:57)
04:55:29 at java.lang.Class.forNameImpl(java.base@11/Native Method)
04:55:29 at java.lang.Class.forName(java.base@11/Class.java:335)
04:55:29 at com.sun.javatest.regtest.agent.GetJDKProperties.run(GetJDKProperties.java:63)
04:55:29 at com.sun.javatest.regtest.agent.GetJDKProperties.main(GetJDKProperties.java:46)
04:55:29 Error: failed to get JDK properties for /home/jenkins/workspace/openjdk11_j9_openjdktest_x86-64_linux/openjdkbinary/j2sdk-image/bin/../bin/java -ea -esa -Xmx512m -Xcompressedrefs; exit code 1
https://ci.adoptopenjdk.net/view/all/job/openjdk11_j9_openjdktest_x86-64_linux/3/console
In JDK11, it seems that the MessageDigest object initialized from provider such as SunPKCS11-NSS-FIPS is not cloneable. The following code is the sample test.
import java.security.MessageDigest;
class testMD {
public static void main(String[] args) throws Exception {
MessageDigest md = MessageDigest.getInstance("SHA-256");
System.out.println("Debug - provider: " + md.getProvider());
System.out.println("Debug - cloneable: " + (md instanceof Cloneable));
}
}
After compiling and running, we got the following message.
javac testMD.java
------------------
java -Dsemeru.fips=true testMD
Debug - provider: SunPKCS11-NSS-FIPS version 11
Debug - cloneable: false
In jdk11, it seems that the MessageObject is not cloneable.
We are using the latest code from openj9-openjdk-jdk11/openj9 branch.
Issue reported at eclipse/openj9:
eclipse-openj9/openj9#4927
openjdk fix was created for jdk13, backported to jdk12, but not jdk11.
Short term resolution is to backport the fix to openj9-openjdk-jdk11: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8218618
Longer term solution is to backport the fix to openjdk jdk11u.
From issue https://github.com/ibmruntimes/openj9-openjdk-jdk11/issues/1, seems following are unsupported executable. But they are still in jdk11 builds. Have a quick try and found the function is limited compared with the tools in Hotspot jvm. Just want to confirm if they are work as design. Thanks.
jinfo
jps
jmap
jstack
jstat
e.g
jstat in hotspot JVM on AIX.
bash-4.2$ jstat -options
-class
-compiler
-gc
-gccapacity
-gccause
-gcmetacapacity
-gcnew
-gcnewcapacity
-gcold
-gcoldcapacity
-gcutil
-printcompilation
jstat in J9 JVM on AIX
bash-4.2$ jstat -options
-class
Running make all in a cross-building environment fails with the target test-image-openj9, because it runs $(JDK_OUTPUTDIR)/bin/java -version on an incompatible platform.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.