ibmruntimes / openj9-openjdk-jdk Goto Github PK
View Code? Open in Web Editor NEWExtensions for OpenJDK for Eclipse OpenJ9
License: GNU General Public License v2.0
Extensions for OpenJDK for Eclipse OpenJ9
License: GNU General Public License v2.0
jenkins copyright check
jenkins signed off by check
jenkins line endings check
Seems OpenJDK added Github actions to their repo recently
https://github.com/ibmruntimes/openj9-openjdk-jdk/commits/openj9/.github/workflows/submit.yml
This will cause these checks to run on our PRs.
Few options to take
Current openjdk-tag.gmk
content:
OPENJDK_TAG := jdk-20+25
jdk-20+26 is already in the repo.
This is a mismatch, openjdk-tag.gmk
missed a update.
ibmruntimes/openj9-openjdk-jdk11#670 (comment)
Strange: the test job didn't use this change; instead it used the [current openj9 branch - b33416dc888](https://github.com/ibmruntimes/openj9-openjdk-jdk11/commit/b33416dc888ee757c6761810bf416f37c6b17e8a).
I think this is a known issue as well, the test change is not picked up, it was determined a low priority item.
FYI @AdamBrousseau
 javax/security/auth/login/modules/JaasModularClientTest.java.JaasModularClientTest
 javax/security/auth/login/modules/JaasModularDefaultHandlerTest.java.JaasModularDefaultHandlerTest
 sun/security/mscapi/CastError.java.CastError
 sun/security/mscapi/InteropWithSunRsaSign.java.InteropWithSunRsaSign
 sun/security/mscapi/KeyStoreEmptyCertChain.java.KeyStoreEmptyCertChain
 sun/security/mscapi/PublicKeyInterop.java.PublicKeyInterop
 sun/security/mscapi/RSAEncryptDecrypt.java.RSAEncryptDecrypt
 sun/security/mscapi/ShortRSAKeyWithinTLS.java.ShortRSAKeyWithinTLS
 sun/security/mscapi/SignUsingNONEwithRSA.java.SignUsingNONEwithRSA
 sun/security/mscapi/SignUsingSHA2withRSA.java.SignUsingSHA2withRSA
 sun/security/mscapi/SignatureOffsets.java.SignatureOffsets
 sun/security/mscapi/SignedObjectChain.java.SignedObjectChain
 sun/security/mscapi/SmallPrimeExponentP.java.SmallPrimeExponentP
 sun/security/pkcs12/P12SecretKey.java.P12SecretKey
 sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java.FileInputStreamPoolTest
 com/sun/net/httpserver/SelCacheTest.java.SelCacheTest
com/sun/net/httpserver/Test12.java.Test12
 com/sun/net/httpserver/Test9.java.Test9
 com/sun/net/httpserver/Test9a.java.Test9a
 java/net/URLClassLoader/B7050028.java.B7050028
 java/net/URLConnection/UnknownContentType.java.UnknownContentType
 java/security/KeyPairGenerator/FinalizeHalf.java.FinalizeHalf
 java/security/Provider/SecurityProviderModularTest.java.SecurityProviderModularTest
 java/security/Signature/ResetAfterException.java.ResetAfterException
 java/security/Signature/SignatureLength.java.SignatureLength
 sun/net/www/protocol/file/FileMap.java.FileMap
 sun/net/www/protocol/file/GetLastModified.java.GetLastModified
Details in attached jtr files:
jtr_test_output.tar.gz
Addressed by ibmruntimes/openj9-openjdk-jdk8#107 for Windows jdk8, but should be fixed for other platforms and other jdk versions.
See ibmruntimes/openj9-openjdk-jdk17#166 (comment) for an explanation of why the size of padding elements is incorrect in CallGeneratorHelper
.
extended.openjdk
PR build still shows the errors eclipse-openj9/openj9#16074 due to the test framework taking the default JDK19 extension repo instead of this PR.
Launched an internal grinder w/ this change and the three tests in question are skipped or passed.
Originally posted by @JasonFengJ9 in ibmruntimes/openj9-openjdk-jdk19#34 (comment)
FYI @llxia @AdamBrousseau
On RHEL 7, the libcrypto library is not loaded. Looking at the library names on the machine, the library used for 1.0.x is not currently supported.
libcrypto.so.10 (libc6,x86-64) => /lib64/libcrypto.so.10
libcrypto.so.10 (libc6) => /lib/libcrypto.so.10
libcrypto.so.6 (libc6,x86-64) => /lib64/libcrypto.so.6
-rwxr-xr-x 1 root root 1440264 Mar 4 2016 libcrypto.so.0.9.8e
-rwxr-xr-x 1 root root 2512264 May 17 2017 libcrypto.so.1.0.2k
lrwxrwxrwx 1 root root 19 Sep 3 2017 libcrypto.so.10 -> libcrypto.so.1.0.2k
lrwxrwxrwx 1 root root 19 Mar 20 2016 libcrypto.so.6 -> libcrypto.so.0.9.8e
const char *libname = "libcrypto.so.1.1"; // Library name for OpenSSL 1.1.0 and 1.1.1
const char *oldname = "libcrypto.so.1.0.0"; // Library name for OpenSSL 1.0.2
const char *symlink = "libcrypto.so"; // Library name for possible symbolic links
The custom-hook.m4 logic to determine the "based -on " queries all jdk matching tags across the whole repo, meaning if more recent levels have been merged into master, then a build of openj9 branch which does not have those reachable will still display them.
Eg.jdk11 openj9 branch is in fact at jdk-11.0.3+2, but as master & openj9-0.14 have jdk-11.0.3+7 it incorrectly chooses that level.
We've just gotten OpenJ9 testing running for jdknext, and enabled openssl support. The following problems are found.
https://ci.eclipse.org/openj9/job/Build_JDKnext_x86-64_mac_Nightly/28/
00:48:11 /Users/jenkins/workspace/Build_JDKnext_x86-64_mac_Nightly/closed/src/java.base/macosx/native/libjncrypto/NativeCrypto_md.c:63:14: error: implicit declaration of function 'dlinfo' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
00:48:11 if (0 != dlinfo(handle, RTLD_DI_ORIGIN, library_path)) {
00:48:11 ^
00:48:11 /Users/jenkins/workspace/Build_JDKnext_x86-64_mac_Nightly/closed/src/java.base/macosx/native/libjncrypto/NativeCrypto_md.c:63:29: error: use of undeclared identifier 'RTLD_DI_ORIGIN'
00:48:11 if (0 != dlinfo(handle, RTLD_DI_ORIGIN, library_path)) {
00:48:11 ^
00:48:11 2 errors generated.
https://ci.eclipse.org/openj9/job/Build_JDKnext_ppc64_aix_Nightly/28/
01:21:41 "/home/u0020236/workspace/Build_JDKnext_ppc64_aix_Nightly/closed/src/java.base/aix/native/libjncrypto/NativeCrypto_md.c", line 65.29: 1506-045 (S) Undeclared identifier RTLD_DI_ORIGIN.
ibmruntimes/openj9-openjdk-jdk8#210
https://ci.eclipse.org/openj9/job/PullRequest-CopyrightCheck-OpenJDK8/345/
14:11:32 The following files were modified and have incorrect copyrights
[Pipeline] echo
14:11:32 common/autoconf/generated-configure.sh
14:11:32 IBM Copyright (basic) is missing from the file
[Pipeline] echo
14:11:32 jdk/make/closed/autoconf/generated-configure.sh
14:11:32 IBM Copyright (basic) is missing from the file
there are IBM copyrights, but not in the first 100 lines.
How can I pass the OpenJDK GHA Sanity Checks?
There seems to be a perf regression between these two builds
openjdk version "11.0.15-internal" 2022-04-19
OpenJDK Runtime Environment (build 11.0.15-internal+0-adhoc.jenkins.BuildJDK11x86-64linuxcriuPersonal)
Eclipse OpenJ9 VM (build master-2ea2b1ea4ce, JRE 11 Linux amd64-64-Bit Compressed References 20220322_5 (JIT enabled, AOT enabled)
OpenJ9 - 2ea2b1ea4ce
OMR - 644b9078b90
JCL - f8e09fe3452 based on jdk-11.0.15+6)
openjdk version "11.0.15-internal" 2022-04-19
OpenJDK Runtime Environment (build 11.0.15-internal+0-adhoc.jenkins.BuildJDK11x86-64linuxcriuPersonal)
Eclipse OpenJ9 VM (build master-2ea2b1ea4ce, JRE 11 Linux amd64-64-Bit Compressed References 20220323_6 (JIT enabled, AOT enabled)
OpenJ9 - 2ea2b1ea4ce
OMR - 644b9078b90
JCL - 2e2a51b2f0d based on jdk-11.0.15+6)
The openj9/omr versions are the same, which makes me think that ibmruntimes/openj9-openjdk-jdk11#486 is the cause.
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}''
Builds are missing the java*.properties files that should be present in the image/jdk/lib directory, as well as the options.default file.
Tested with a build from June 27th.
Openj9PropsExt.java need to be updated to support setting Properties required by @requires expressions.
For example Property vm.bits
, otherwise tests with @requires property
will be skipped.
Looking at adoptium/temurin-build#2178, it's a failure to build the JVM, so there is no -version output. I don't see anywhere in the output where the OpenJ9 and OMR SHAs are shown. The get_j9_source.sh script could print them out after doing a clone.
The OpenJ9 builds determine the SHAs ahead of time and specify them to the script, but Adopt and other builds don't do this.
Rename github.com:ibmruntimes/openj9-openjdk-jdk "jdk" & "openj9-jdk" branches to be consistent with jdk 8/9/10/11, where they are called master & openj9
Any time there is a change to the openj9 branch in an extensions repo, the staging branch is updated as well by the automated merge process, and this causes an unnecessary acceptance build to occur.
See discussions here:
eclipse-openj9/openj9#7827 (comment)
eclipse-openj9/openj9#7827 (comment)
Currently we do not zip the debug symbols into the SDKs built at https://ci.eclipse.org/openj9/, making it hard to see the native stack information from a core file generated from a test failure.
If the SunPKCS11 provider is specified on the getInstance call a no such provider exception will be thrown. If no provider is specified on the getInstance call the first provider in the java security provider list will be used, if the customer is relying on the provider order and have placed SunPKCS11 above others with the intent of using that provider, it will not be used, another provider will be used without notifying the customer. Thus if the customer is relying on the use of Crypto cards for auditing or to meet requirements they will have a silent failure in their process. When debugging why the SunPKCS11 provider is not being used, one might specify -Djava.security.debug=sunpkcs11, there will be no output. Thus there is no indication of what the cause of the problem is.
Merge master HEAD into openj9-staging
#322 includes 8255557: Decouple GCM from CipherCore
55387a2 which moved GCM within com.sun.crypto.provider.CipherCore
via 278b628, and effectively removed OpenJ9 JCL patch for NativeGCM
while NativeCBC
still stays.
NativeGCM
implementation requires revisiting and to be re-enabled.
fyi @ashbm5
This causes the jobs to consume valuable space on our worker machine.
Recommend adding a try/finally block around the code.
node ('worker') {
try {
// Stuff
} finally {
cleanWs()
}
}
Disabled the jobs temporarily
https://ci.eclipse.org/openj9/view/Infrastructure/job/CopyrightCheck-OpenJDK/
https://ci.eclipse.org/openj9/view/Infrastructure/job/CopyrightCheck-OpenJDK12/
https://ci.eclipse.org/openj9/view/Infrastructure/job/CopyrightCheck-OpenJDK11/
https://ci.eclipse.org/openj9/view/Infrastructure/job/CopyrightCheck-OpenJDK8/
This issue relates to eclipse-openj9/openj9#12276 (comment)
For jdk8, serviceability tests are defined in hotspot_serviceability target. When attempting to run this target against openj9, there appears not be a hotspot/test/TEST.groups file where this target is normally defined in a typical jdk8u mirror (see: https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/hotspot/test/TEST.groups#L141-L142).
From https://openj9-jenkins.osuosl.org/view/Test/job/Grinder/80/console:
12:47:58 Error: Group spec does not specify a valid test suite: /home/jenkins/workspace/Grinder/aqa-tests/TKG/../openjdk/openjdk-jdk/hotspot/test:hotspot_serviceability
12:47:58
12:47:58 hotspot_serviceability_1_FAILED
The eclipse/openj9-systemtest repository includes Eclipse .project files, enabling users to check out the repository directly into an Eclipse IDE and exploit the IDE features such as dynamic compilation and debugging.
.project files are not currently excluded from the PR copyright checker which, as automatically generated files, they should be.
#282 should be contributed to OpenJDK.
@andrew-m-leonard
Just noticed that there are some strange tag number difference among extension repos.
https://github.com/ibmruntimes/openj9-openjdk-jdk8 - 104 tags
https://github.com/ibmruntimes/openj9-openjdk-jdk11 - 642 tags
https://github.com/ibmruntimes/openj9-openjdk-jdk16 - 1361 tags
https://github.com/ibmruntimes/openj9-openjdk-jdk17 - 717 tags
https://github.com/ibmruntimes/openj9-openjdk-jdk - 1385 tags
JDK17
has much less number of tags than JDK
head and JDK16
which is strange.
Also noticed that JDK16
& JDK
have many hg-jdk-*
tags which shouldn't in these repos, these extra tags probably are the reason why JDK16
has more tags than JDK17
.
Adopting RI java.lang.Thread
/ThreadGroup
can be enabled via --enable-openjdk-thread-support
at JavaNext extension repo. This is to support project loom.
This will be ported to other Java levels according to priorities.
#260 should be contributed to OpenJDK.
@andrew-m-leonard
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 jdk (and 10, 11) builds.
jinfo
jps
jmap
jstack
jstat
Also
ibmruntimes/openj9-openjdk-jdk10#47
ibmruntimes/openj9-openjdk-jdk11#1
https://ci.eclipse.org/openj9/job/Build_JDKnext_x86-64_windows_OpenJDK/77
22:57:15 c:/Users/jenkins/workspace/Build_JDKnext_x86-64_windows_OpenJDK/src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c(113): error C2220: warning treated as error - no 'object' file generated
22:57:15 c:/Users/jenkins/workspace/Build_JDKnext_x86-64_windows_OpenJDK/src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c(113): warning C4028: formal parameter 2 different from declaration
openj9 branch is
dbgsysBuildLibName(char *holder, size_t holderlen, const char *pname, const char *fname)
while openj9-staging and master branch is
dbgsysBuildLibName(char *holder, int holderlen, const char *pname, const char *fname)
The CMake code should now be able to handle cross compile builds. This issue is to track any problems / objections anybody has before making cross-compile builds use cmake by default. CMake builds can currently be tested by passing --with-cmake
when calling configure. In addition, where CMake is used by default, uma can still be used by passing --without-cmake
.
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 is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
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.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.