eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.

Welcome to the Eclipse OpenJ9 repository

We're not sure which route you might have taken on your way here, but we're really pleased to see you! If you came directly from our website, you've probably already learned a lot about Eclipse OpenJ9 and how it fits in to the OpenJDK ecosystem. If you came via some other route, here are a few key links to get you started:

• Eclipse OpenJ9 website - Learn about this high performance, enterprise-grade Java Virtual Machine (JVM) and why we think you want to get involved in its development.
• Build instructions for JDK8, JDK11, and More - Here's how you can build an OpenJDK with OpenJ9 yourself.

If you're looking for ways to help out at the project (thanks!), we have:

• Beginner issues
• Help Wanted issues

If you're here to learn more about the project, read on ...

What is Eclipse OpenJ9?

Eclipse OpenJ9 is an independent implementation of a Java Virtual Machine. "Independent implementation" means it was built using the Java Virtual Machine specification without using any code from any other Java Virtual Machine.

The OpenJ9 JVM combines with the Java Class libraries from OpenJDK to create a complete JDK tuned for footprint, performance, and reliability that is well suited for cloud deployments.

The original source contribution to OpenJ9 came from the IBM "J9" JVM which has been used in production by thousands of Java applications for the last two decades. In September 2017, IBM completed open sourcing the J9 JVM as "Eclipse OpenJ9" at the Eclipse Foundation. Significant parts of J9 are also open source at the Eclipse OMR project. OpenJ9 has a permissive license (Apache License 2.0 or Eclipse Public License 2.0 with a secondary compatibility license for the OpenJDK project's GPLv2 license) that is designed to allow OpenJDK to be built with the OpenJ9 JVM. Please see our LICENSE file for more details.

Eclipse OpenJ9 is a source code project that can be built alongside Java class libraries. See the build instructions. Eclipse Foundation projects are not permitted to distribute, market or promote JDK binaries unless they have passed a Java SE Technology Compatibility Kit licensed from Oracle, to which the OpenJ9 project does not currently have access. See the Eclipse Adoptium Project Charter.

What is the goal of the project?

The long term goal of the Eclipse OpenJ9 project is to foster an open ecosystem of JVM developers that can collaborate and innovate with designers and developers of hardware platforms, operating systems, tools, and frameworks.

The project welcomes collaboration, embraces fresh innovation, and extends an opportunity to influence the development of OpenJ9 for the next generation of Java applications.

The Java community has benefited over its history from having multiple implementations of the JVM specification competing to provide the best runtime for your application. Whether adding compressed references, new Cloud features, AOT (ahead of time compilation), or straight up faster performance and lower memory use, the ecosystem has improved through that competition. Eclipse OpenJ9 aims to continue to spur innovation in the runtimes space.

How do I contribute?

Since we are an Eclipse Foundation project, each contributor needs to sign an Eclipse Contributor Agreement. The Eclipse Foundation operates under the Eclipse Code of Conduct to promote fairness, openness, and inclusion.

To get started, read our Contribution Guide.

If you think you want to contribute but you're not ready to sign the Eclipse Contributor Agreement, why not come along to our weekly Ask the OpenJ9 community calls to find out more about how we work. We talk about new ideas, answer any questions that get raised, and discuss project plans and status. We also do lightning talks on features and functions of the VM. Visit the #planning channel in our Slack workspace for information about upcoming community calls and minutes from previous meetings (Join here).

What repos are part of the project?

• https://github.com/eclipse-openj9/openj9 : OpenJ9 main code base
• https://github.com/eclipse-openj9/openj9-omr : Eclipse OMR clone to stage temporary OMR changes. (None so far!)
• https://github.com/eclipse-openj9/openj9-systemtest : OpenJ9-specific system tests
• https://github.com/eclipse-openj9/openj9-website : OpenJ9 website repo
• https://github.com/eclipse-openj9/openj9-docs : OpenJ9 documentation repo
• https://github.com/eclipse-openj9/build-openj9 : OpenJ9 GitHub actions repo
• https://github.com/eclipse-openj9/openj9-utils : OpenJ9 utility programs / tools repo, a place to develop community around the tools

Where can I learn more?

• Moving to OpenJ9
• User documentation
• Many more resources are available on the OpenJ9 blog

Videos and Presentations

• JavaOne 2017: John Duimovich and Mike Milinkovich having fun chatting about Eclipse OpenJ9 (and EE4J)
• JavaOne 2017: Holly Cummins interviewing Dan Heidinga and Mark Stoodley on Eclipse OpenJ9 and OMR
• JavaOne 2017: Open sourcing the IBM J9 Java Virtual Machine
• JavaOne 2017: Eclipse OpenJ9 Under the hood of the next open source JVM
• JavaOne 2017: Ask the OpenJ9 Architects
• Eclipse OpenJ9 verbose JIT logs
• JavaOne 2017: How to build a debuggable runtime
• Reducing Garbage Collection pause times with Concurrent Scavenge and the Guarded Storage Facility
• How Concurrent Scavenge using the Guarded Storage Facility Works
• Are you still paying for unused memory when your Java app is idle?
• Under the hood of the Testarossa JIT Compiler
• Class sharing In Eclipse OpenJ9

Copyright IBM Corp. and others 2017

openj9's Issues

java.lang.UnsatisfiedLinkError: com/ibm/jvm/Dump.JavaDumpImpl()I

An java.lang.UnsatisfiedLinkError: com/ibm/jvm/Dump.JavaDumpImpl()I occurs in Java 9 when calling com.ibm.jvm.Dump.JavaDump(Dump.java:115).

I expect this is caused by #58 @JasonFengJ9

HOWTO Request: Managing changes across dependent repos

Like all projects, OpenJ9 builds on the shoulders of Giants. As a potential contributor, one of my concerns is understanding how I make a contribution to OpenJ9 that might span OpenJ9, OMR, an/or the OpenJDK extensions

Pull Request Automatic Copyright Check

Setup a Jenkins build at the Eclipse OpenJ9 JIPP instance to automatically run copyright checks against PRs.
The check should ensure the following about modified or added files:

• The file contains a copyright header if it is needed (based on file extension?). All files
• The Copyright header matches the template in CONTRIBUTING.md. We're only checking the "year" line
• The second date in the copyright matches the current year.

Other Requirements:

• The job should run automatically when a PR is opened since no PR code is being built/executed.
• The job should detail all the files that cause the check to fail.
• The job should have a trigger phrase to rerun the check manually.
• The pipeline code should be checked into the openj9 rpeo.
• There should be doc available at/in the repo about the job.

Support for Truffle API

Does OpenJ9 has support for the Truffle API?

would you please add an ubuntu ppa for openj9?

would you please add an ubuntu ppa for openj9?

Use `update-alternatives` in docker files rather than straight symlinks

In #23, it was discovered minor changes to the docker file can break it

I suspect switching to update-alternative will fix this.

Compilation Output is too Verbose

The output when compiling the OpenJ9 source code is extremely verbose. The core OpenJDK project is much briefer by default. I'd recommend changing our default compilation output to more closely match that of OpenJDK.

e.g., OpenJ9 output:

cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o mgmtmemory.o ../common/mgmtmemory.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o mgmtmempool.o ../common/mgmtmempool.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o mgmtos.o ../common/mgmtos.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o mgmtosext.o ../common/mgmtosext.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o mgmtprocessor.o ../common/mgmtprocessor.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o mgmtruntime.o ../common/mgmtruntime.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o mgmtthread.o ../common/mgmtthread.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o orbvmhelpers.o ../common/orbvmhelpers.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o proxy.o ../common/proxy.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o reflecthelp.o ../common/reflecthelp.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o shared.o ../common/shared.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o sigquit.o ../common/sigquit.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o stdinit.o ../common/stdinit.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o string.o ../common/string.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o sun_misc_Perf.o ../common/sun_misc_Perf.c
c++ -O3 -fno-strict-aliasing -fno-exceptions -fno-rtti -fno-threadsafe-statics -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wreturn-type -Werror -Wall -Wno-non-virtual-dtor -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c ../common/sun_misc_Unsafe.cpp
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o sun_reflect_ConstantPool.o ../common/sun_reflect_ConstantPool.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o syshelp.o ../unix/syshelp.c
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o system.o ../common/system.c
c++ -O3 -fno-strict-aliasing -fno-exceptions -fno-rtti -fno-threadsafe-statics -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wreturn-type -Werror -Wall -Wno-non-virtual-dtor -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c ../common/thread.cpp
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64  -fPIC  -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -Wall  -I. -I../../include -I../../oti -I../../zlib -I../../util -I../../gc_include -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../../gc_glue_java -I../../j9vm -I../../shared_common/include -I../unix -I../crypto -I../filerms -I../filesys -I../common -I../inl -I../. -I../../nls -I/root/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core  -DJ9VM_JCL_SE7_BASIC  -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c -o unsafe_mem.o ../common/unsafe_mem.c

vs. OpenJDK output:

Compiling 21 files for java.smartcardio
Compiling 18 files for jdk.accessibility
Compiling 59 files for jdk.internal.jvmstat
Compiling 18 files for jdk.attach
Compiling 118 files for jdk.charsets
Compiling 399 files for jdk.compiler
Compiling 8 files for jdk.crypto.ec
Compiling 67 files for jdk.crypto.cryptoki

would you please publish docker image on hub.docker.com?

would you please publish docker image on hub.docker.com?
We want to try openj9 with docker

Supporting OS X Mac builds

It has been pointed out that Eclipse OpenJ9 does not yet have OS X builds. Eclipse OMR provides OS X support. In this issue we can discuss what would be needed.

document tr.jit options

It would be worthwhile to document the hidden treasures of trjjit optimizations (a significant portion of j9options.cpp) for:

• Users to gain insight into the (so far) under-documented tr jit features, take advantage of it by applying fine grained compiler customizations based on the specific environment and workload.
• Community members to better acquiant with the optimizations, hack around with the code with ease, get upto speed for large scale collaboration.

Docs for "Configuring your Runtime Environment" is 404

Might be the wrong place to report it but I found no other.

On the "Read the docs"-page, https://www.ibm.com/support/knowledgecenter/SSYKE2_9.0.0/welcome/welcome_javasdk_version.html, when you press "Configuring your Runtime Environment" you get the message:
The requested resource is not found: /support/knowledgecenter/SSYKE2_9.0.0/com.ibm.java.multiplatform.90.doc/user/configuring.html

Trademark symbol for Eclipse OpenJ9

At the top of Eclipse OpenJ9's landing page, it says "Eclipse OpenJ9". There is a no trademark symbol next to it as it is on Eclipse OMR's landing page.

Is this intentional? Either way, we should add an explanation for the difference between OpenJ9 and OMR.

libhyprtshim29.so is unnecessarily loaded

libhyprtshim29.so is always loaded, but is only needed for IBM's Java 8 builds.

Getting Hash Sum mismatch while building openj9 image

I was running "docker build -t openj9 -f Dockerfile ." to build the dockerfile on linux x86-64. I ended up with the below error.

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/universe/source/by-hash/SHA256/e201ab73d77c0208d5dcd4844b6215bc5e18b49d9f9b58d0fb627c47c0438ecd Hash Sum mismatch
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/main/binary-amd64/by-hash/SHA256/8d6ab57abf517d7712e4e4d23d762485af49f8140a83b221ea7282f82a51c795
E: Some index files failed to download. They have been ignored, or old ones used instead.

I already had a ubuntu image installed. Not sure if this was causing any issues. So, i did docker pull of ubuntu image and updated it. But no luck.

I'm not able to understand why is this happening.

Workaround:
Added "rm -rf /var/lib/apt/lists/* && apt-get clean" before apt-get update (based on google search) in the dockerfile and it helped.

Excessive use of j9file_lastmod from shared class cache

So what I believe is happening is there are two pairs of places that can trigger a notifyClasspathEntryStateChange through j9shr_hookZipLoadEvent. One pair is through the JVM_ZipHook out of Java_java_util_zip_ZipFile_close / Java_java_util_zip_ZipFile_open (handle zip file access from Java), and the other pair is from the J9HOOK_VM_ZIP_LOAD event registered in shrinit.cpp, which receives notification from TRIGGER_J9HOOK_VM_ZIP_LOAD, used by the zip cache library used by the zip file access from native.

So even though a file is open and stays open in the zip cache by native, a Java application can open and close a duplicate zip file, breaking the state of the timestamp cache used by hasTimestampChanged() as it doesn't keep track of open count.

Essentially we get something like:

open(xml.jar) from J9HOOK_VM_ZIP_LOAD
open(xml.jar) from JVM_ZipHook
close(xml.jar) from JVM_ZipHook

After this point hasTimestampChanged(xml.jar) fails to identify xml.jar as an already open file and continues to invoke the localCheckTimestamp() routine, driving j9file_lastmod.

OpenJ9 is incompatible with sbt's shell mode...

SBT is a build tool for the scala programming language. When I try to run it in interactive mode with the command sbt using the openj9+openjdk jre obtained here, I get the following error:

java.lang.IllegalArgumentException: Signal already used by VM or OS: SIGCONT
   at jdk.internal.misc.Signal.handle(java.base@9-internal/Signal.java:173)
   at sun.misc.Signal.handle(jdk.unsupported@9-internal/Signal.java:157)
   at sbt.Signals0.withHandler(Signal.scala:79)
   at sbt.Signals$.withHandler(Signal.scala:11)
   at sbt.JLine.readLineDirect(LineReader.scala:34)
   at sbt.JLine.readLineWithHistory(LineReader.scala:27)
   at sbt.JLine.sbt$JLine$$unsynchronizedReadLine(LineReader.scala:19)
   at sbt.JLine$$anonfun$readLine$1.apply(LineReader.scala:16)
   at sbt.JLine$$anonfun$readLine$1.apply(LineReader.scala:16)
   at sbt.JLine$$anonfun$withJLine$1.apply(LineReader.scala:117)
   at sbt.JLine$$anonfun$withJLine$1.apply(LineReader.scala:115)
   at sbt.JLine$.withTerminal(LineReader.scala:89)
   at sbt.JLine$.withJLine(LineReader.scala:115)
   at sbt.JLine.readLine(LineReader.scala:16)
   at sbt.BasicCommands$$anonfun$shell$1.apply(BasicCommands.scala:185)
   at sbt.BasicCommands$$anonfun$shell$1.apply(BasicCommands.scala:181)
   at sbt.Command$$anonfun$command$1$$anonfun$apply$1.apply(Command.scala:30)
   at sbt.Command$$anonfun$command$1$$anonfun$apply$1.apply(Command.scala:30)
   at sbt.Command$.process(Command.scala:93)
   at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:96)
   at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:96)
   at sbt.State$$anon$1.runCmd$1(State.scala:183)
   at sbt.State$$anon$1.process(State.scala:187)
   at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:96)
   at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:96)
   at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
   at sbt.MainLoop$.next(MainLoop.scala:96)
   at sbt.MainLoop$.run(MainLoop.scala:89)
   at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:68)
   at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:63)
   at sbt.Using.apply(Using.scala:24)
   at sbt.MainLoop$.runWithNewLog(MainLoop.scala:63)
   at sbt.MainLoop$.runAndClearLast(MainLoop.scala:46)
   at sbt.MainLoop$.runLoggedLoop(MainLoop.scala:30)
   at sbt.MainLoop$.runLogged(MainLoop.scala:22)
   at sbt.StandardMain$.runManaged(Main.scala:61)
   at sbt.xMain.run(Main.scala:35)
   at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:109)
   at xsbt.boot.Launch$.withContextLoader(Launch.scala:128)
   at xsbt.boot.Launch$.run(Launch.scala:109)
   at xsbt.boot.Launch$$anonfun$apply$1.apply(Launch.scala:35)
   at xsbt.boot.Launch$.launch(Launch.scala:117)
   at xsbt.boot.Launch$.apply(Launch.scala:18)
   at xsbt.boot.Boot$.runImpl(Boot.scala:41)
   at xsbt.boot.Boot$.main(Boot.scala:17)
   at xsbt.boot.Boot.main(Boot.scala)
[error] java.lang.IllegalArgumentException: Signal already used by VM or OS: SIGCONT
[error] Use 'last' for the full log.

My operating system is fedora 26, and the openj9 --version string is as follows:

openjdk 9-internal
OpenJDK Runtime Environment (build 9-internal+0-adhoc.jenkins.openjdk)
Eclipse OpenJ9 VM (build 2.9, JRE 9 Linux amd64-64 Compressed References 20170915_6 (JIT enabled, AOT enabled)
J9VM - cea1ed7
JIT  - cea1ed7
OMR  - 617de12
OpenJDK  - 83f5cd0 based on )

Upgrade website to improve compilation instructions.

Hi,

This morning I was testing the whole process to compile #openj9 with the first Docker image and I had a minor problem with the previous step to make all.
https://www.eclipse.org/openj9/oj9_build.html

Evidence:

root@ef8bdb6be04e:~/openj9-openjdk-jdk9# bash ./configure --with-freemarker-jar=~/freemarker.jar
Running custom generated-configure.sh
configure: Configuration created at Sat Sep 23 11:47:20 UTC 2017.
configure: configure script generated at timestamp 1506103370.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /usr/bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for gunzip... /bin/gunzip
checking for pigz... no
checking for gzip... /bin/gzip
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for mkdir... /bin/mkdir
checking for mktemp... /bin/mktemp
checking for mv... /bin/mv
checking for nawk... /usr/bin/nawk
checking for printf... /usr/bin/printf
checking for rm... /bin/rm
checking for rmdir... /bin/rmdir
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for gtar... no
checking for tar... /bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... no
checking for mawk... mawk
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for a sed that does not truncate output... /bin/sed
checking for cygpath... no
checking for greadlink... no
checking for readlink... /bin/readlink
checking for df... /bin/df
checking for cpio... /bin/cpio
checking for nice... /usr/bin/nice
checking for pandoc... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking openjdk-build os-cpu... linux-x86_64
checking openjdk-target os-cpu... linux-x86_64
checking compilation type... native
checking for top-level directory... /root/openj9-openjdk-jdk9
checking if custom source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which debug level to use... release
checking which variants of the JVM to build... server
checking that freemarker location is set... yes
checking for ~/freemarker.jar... no
configure: error: freemarker.jar not found in directory indicated
configure exiting with result code 1
root@ef8bdb6be04e:~/openj9-openjdk-jdk9# make all
Error: No configurations found for /root/openj9-openjdk-jdk9.
Please run 'bash configure' to create a configuration.

/root/openj9-openjdk-jdk9/make/Init.gmk:124: *** Cannot continue.  Stop.

To finish the process, I had to set the absolute path in the step:

root@ef8bdb6be04e:~/openj9-openjdk-jdk9# bash ./configure --with-freemarker-jar=/root/freemarker.jar

If you indicate the repo for the microsite, I could do a PR.

Many thanks in advance.

Cheers

Juan Antonio

PROPOSAL: Labeling schema for managing issues

As this project grows, and the number of open issues being tracked grows, a common labeling schema will be helpful to manage the project's issues.

Taking some of the best practices at other large open projects I propose the following

• defining an small initial set of reserved labels generally applicable to majority of issues
• defining a reserved label colour for each category of label, ie. Priority labels are Green, component labels are blue. This enables quick location of relevant labels.
• label text should start with the category, ie. not "Medium", but "Pri: Medium", or "Comp: VM" . Helps new people identify purpose quickly
• Reserve a red "HOT" or similar red label for drawing attention to Urgent issues.

For the initial set of labels to define ( beyond the Git Default set)

• Priority,
• Component,
• Type (bug vs. discussion vs enhancement vs question),
• Size (fixed unitless values),
• JDK Level (as a project that supports multiple JDK API levels, identifying when a issue is unique to only 1 level will be useful),
• red "Hot" label,
• Beginner label to identify easy to take on work for new contributors.

Beyond that initial set, individuals might create their own labels as they find them useful, but conflicting with the project's defined set/colours should be discouraged.

Link to DockerFile on build instruction page is broken

Link for DockerFile on build instruction page is broken for Linux on z Systems. It points to https://github.com/eclipse/openj9/blob/master/buildenv/docker/jdk9/390_64/ubuntu16/Dockerfile but it should be https://github.com/eclipse/openj9/blob/master/buildenv/docker/jdk9/s390x/ubuntu16/Dockerfile.

Investigate JVM signal handling functions

The implementations of all 3 Signal JVM functions:

• JVM_RegisterSignal
• JVM_FindSignal
• JVM_RaiseSignal

Are questionable. All three need to be validated and completed.

Solve the 'inline' consternation

The definition of JITINLINE, as well potentially other places in the code, causes consternation. Specifically, if you compile C files with newer C compilers, JITINLINE doesn't emit a symbol, causing compilation failures such as

../tr.source/trj9/runtime/MethodMetaData.h:366:18: error: inline function ‘getByteCodeInfoFromStackMap’ declared but never defined [-Werror]

This has been worked around previously by forcing newer C compilers to use the old standard, but this really should be resolved once and for all, and likely, across the whole codebase.

Enable requesting PR builds with dependent changes (Jenkins)

Related #91 #11 #24

Background

By default, a PR build will pull the openj9 branches of the openj9-openjdk-jdk9 and the openj9-omr repos. Sometimes developers have changes in openj9 that depend on changes they are working on in one or both of the other repos. We therefore need a process to request PR builds which can checkout the PR(s) of the other repo(s).

• A dependent change must be at eclipse/omr, eclipse/openj9-omr or ibmruntimes/openj9-openjdk-jdk9
• A PR with the dependent change must be open at the appropriate repo
• A committer must be able to request an openj9 PR build with dependent changes by supplying the namespace, repo and PR number in the trigger phrase.

Syntax

Default

Jenkins test sanity

Dependent change at OMR

Jenkins test sanity depends eclipse/omr#<PR#>

Dependent change at OpenJDK

Jenkins test sanity depends ibmruntimes/openj9-openjdk-jdk9#<PR#>

Dependent change at OMR and OpenJDK

Jenkins test sanity depends eclipse/omr#<PR#> ibmruntimes/openj9-openjdk-jdk9#<PR#>

The reason/benefit of supplying the org/repo#PR is that Github will automatically generate a link to the dependent PR in the comment.

Build Eclipse OpenJ9 on Windows

Much of the work to be done to get Eclipse OpenJ9 build on Windows will be done in the https://github.com/ibmruntimes/openj9-openjdk-jdk9/ repository, as the makefiles, configure scripts, etc. live there.

I'm opening this issue: 1) to provide visibility of the work that's (mostly) happening in the other repository, and 2) to cover any work that needs to be done here.

@vsebe is working on this now.

Pull Request builds for z/p linux (test sanity)

Similar to #24, we need pull request builds setup on our Jenkins instance.

• Builds should compile and run the sanity test target.
• Linux-ppc64le
• Linux-s390x
• Whitelist OpenJ9 committers to trigger builds manually using trigger phrase (need this list)
• Trigger phrase jenkins test sanity case insensitive for all platforms
  • jenkins test sanity plinux
  • jenkins test sanity zlinux
• Trigger based on Github hook (not polling)
  • Eclipse bug to request Repo hook

ARM build?

I'm interested in trying out OpenJ9 on e.g Raspberry Pi. It doesn't look like armv7l is supported out-of-the-box although the codebase certainly has some references to ARM arch.
What's the timeline for getting ARM support and/or can I already try and hack something together? If the latter, some initial pointers would be appreciated :-)

Enable a travis.ci-based PR build for linux x86-64

Build a basic PR build based off the linux_x86-64 docker file.

StackOverflow #OpenJ9 tag doesn't exist

The OpenJ9 landing page points to a StackOverflow search for the OpenJ9 tag; however, when I tried to submit a question with the OpenJ9 tag, StackOverflow said that I need to have at least 1,500 reputation to create a new tag.

OpenJ9 does not work with IntellijIDEA OSS from jetbrains

When I try to launch IntellijIDEA with the OpenJ9 JRE, I get the following error:

Internal error. Please report to http://jb.gg/ide/critical-startup-errors

io.netty.channel.ChannelException: Unable to create Channel from class class io.netty.channel.socket.nio.NioServerSocketChannel
    at io.netty.channel.ReflectiveChannelFactory.newChannel(ReflectiveChannelFactory.java:40)
    at io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:321)
    at io.netty.bootstrap.AbstractBootstrap.doBind(AbstractBootstrap.java:283)
    at io.netty.bootstrap.AbstractBootstrap.bind(AbstractBootstrap.java:279)
    at io.netty.bootstrap.AbstractBootstrap.bind(AbstractBootstrap.java:268)
    at org.jetbrains.io.BuiltInServer.bind(BuiltInServer.java:149)
    at org.jetbrains.io.BuiltInServer.start(BuiltInServer.java:118)
    at org.jetbrains.io.BuiltInServer.startNioOrOio(BuiltInServer.java:105)
    at com.intellij.idea.SocketLock.lambda$lock$2(SocketLock.java:153)
    at com.intellij.idea.SocketLock$$Lambda$189.000000007C182CE0.call(Unknown Source)
    at com.intellij.idea.SocketLock.underLocks(SocketLock.java:181)
    at com.intellij.idea.SocketLock.lock(SocketLock.java:128)
    at com.intellij.idea.StartupUtil.lockSystemFolders(StartupUtil.java:286)
    at com.intellij.idea.StartupUtil.prepareAndStart(StartupUtil.java:122)
    at com.intellij.idea.MainImpl.start(MainImpl.java:34)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-internal/Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-internal/NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-internal/DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(java.base@9-internal/Method.java:564)
    at com.intellij.ide.plugins.PluginManager.lambda$start$0(PluginManager.java:95)
    at com.intellij.ide.plugins.PluginManager$$Lambda$179.0000000024E69BD0.run(Unknown Source)
    at java.lang.Thread.run(java.base@9-internal/Thread.java:835)
Caused by: java.lang.NoClassDefFoundError: io.netty.buffer.ByteBufAllocator (initialization failure)
    at java.lang.J9VMInternals.initializationAlreadyFailed(java.base@9-internal/J9VMInternals.java:141)
    at io.netty.channel.DefaultChannelConfig.<init>(DefaultChannelConfig.java:56)
    at io.netty.channel.DefaultChannelConfig.<init>(DefaultChannelConfig.java:69)
    at io.netty.channel.socket.DefaultServerSocketChannelConfig.<init>(DefaultServerSocketChannelConfig.java:48)
    at io.netty.channel.socket.nio.NioServerSocketChannel$NioServerSocketChannelConfig.<init>(NioServerSocketChannel.java:195)
    at io.netty.channel.socket.nio.NioServerSocketChannel$NioServerSocketChannelConfig.<init>(NioServerSocketChannel.java:193)
    at io.netty.channel.socket.nio.NioServerSocketChannel.<init>(NioServerSocketChannel.java:87)
    at io.netty.channel.socket.nio.NioServerSocketChannel.<init>(NioServerSocketChannel.java:72)
    at java.lang.J9VMInternals.newInstanceImpl(java.base@9-internal/Native Method)
    at java.lang.Class.newInstance(java.base@9-internal/Class.java:1954)
    at io.netty.channel.ReflectiveChannelFactory.newChannel(ReflectiveChannelFactory.java:38)
    ... 21 more
Caused by: java.lang.UnsupportedOperationException: The method has not yet been implemented for now
    at java.lang.invoke.MethodHandles.privateLookupIn(java.base@9-internal/MethodHandles.java:1538)
    at java.util.concurrent.atomic.Striped64$1.run(java.base@9-internal/Striped64.java:390)
    at java.util.concurrent.atomic.Striped64$1.run(java.base@9-internal/Striped64.java:387)
    at java.security.AccessController.doPrivileged(java.base@9-internal/AccessController.java:638)
    at java.util.concurrent.atomic.Striped64.<clinit>(java.base@9-internal/Striped64.java:386)
    at io.netty.util.internal.PlatformDependent.newLongCounter(PlatformDependent.java:318)
    at io.netty.buffer.PoolArena.<init>(PoolArena.java:67)
    at io.netty.buffer.PoolArena$HeapArena.<init>(PoolArena.java:671)
    at io.netty.buffer.PooledByteBufAllocator.<init>(PooledByteBufAllocator.java:236)
    at io.netty.buffer.PooledByteBufAllocator.<init>(PooledByteBufAllocator.java:187)
    at io.netty.buffer.PooledByteBufAllocator.<init>(PooledByteBufAllocator.java:176)
    at io.netty.buffer.PooledByteBufAllocator.<init>(PooledByteBufAllocator.java:162)
    at io.netty.buffer.PooledByteBufAllocator.<clinit>(PooledByteBufAllocator.java:143)
    at io.netty.buffer.ByteBufUtil.<clinit>(ByteBufUtil.java:79)
    at io.netty.buffer.ByteBufAllocator.<clinit>(ByteBufAllocator.java:24)
    ... 31 more

IntellijIDEA can be downloaded from here. I am using the community edition. My OpenJ9 --version is

openjdk 9-internal
OpenJDK Runtime Environment (build 9-internal+0-adhoc.jenkins.openjdk)
Eclipse OpenJ9 VM (build 2.9, JRE 9 Linux amd64-64 Compressed References 20170915_6 (JIT enabled, AOT enabled)
J9VM - cea1ed7
JIT  - cea1ed7
OMR  - 617de12
OpenJDK  - 83f5cd0 based on )

Create documentation about Shared classes cache and AOT compilation

Is there doc around -Xshareclasses and AOT compilation in OpenJ9? If not, can we reuse existing material to create these?

In general, it looks like OpenJ9 needs some sort of User Guide and documentation around how to use the various jvm (and possibly jit?) options (developers may not always want to look at the code to figure these out).

https://stackoverflow.com/questions/46343352/how-to-use-aot-compiler-in-openj9/46347665#46347665

Crash running gradle reported on StackOverflow

https://stackoverflow.com/questions/46352408/cant-build-openjfx-with-eclipse-openj9181

"The new Eclipse J9 jvm does not come bundled with JavaFX, so I have tried to build OpenJFX but have failed. I believe I have followed all the build instructions on the OpenJFX website. I have Gradle 3.1, Ant, and the required libraries installed. I'm running Fedora 26. J9 appears to be failing with some kind of segmentation fault. Here is the error message I'm getting after I run gradle in the OpenJFX mercurial repository."

[_@localhost rt]$ gradle
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.gradle.internal.reflect.JavaMethod (file:/usr/local/share/gradle-3.1/lib/gradle-base-services-3.1.jar) to method java.lang.ClassLoader.getPackages()
WARNING: Please consider reporting this to the maintainers of org.gradle.internal.reflect.JavaMethod
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Unhandled exception
Type=Segmentation error vmState=0x00040000
J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F822A5BF730 Handler2=00007F82297A4D30 InaccessibleAddress=0000000000000008
RDI=00000000013AFA00 RSI=0000000000000000 RAX=0000000000000004 RBX=00007F822400FDA0
RCX=0000000000000011 RDX=0000000000000000 R8=00007F822400FDA0 R9=0000000000000000
R10=00007F822493EDD0 R11=00007F822BCC1610 R12=00000000013AFA00 R13=00007F822400FDA0
R14=00000000013AFA00 R15=00007F822B4E8190
RIP=00007F822A5EBA20 GS=0000 FS=0000 RSP=00007F822B4E8150
EFlags=0000000000010246 CS=0033 RBP=0000000000000000 ERR=0000000000000004
TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000008
xmm0 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm1 726f6674616c502f (f: 1634488320.000000, d: 1.675017e+243)
xmm2 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm3 0000ff0000000000 (f: 0.000000, d: 1.385239e-309)
xmm4 0000000000000000 (f: 0.000000, d: 0.000000e+00)
xmm5 3bbcc86800000000 (f: 0.000000, d: 6.095003e-21)
xmm6 402bd9b2780ad4ad (f: 2013975680.000000, d: 1.392519e+01)
xmm7 402bd9b2780ad4ad (f: 2013975680.000000, d: 1.392519e+01)
xmm8 3ff0000000000000 (f: 0.000000, d: 1.000000e+00)
xmm9 402bd9b1c3a0f13b (f: 3282104576.000000, d: 1.392518e+01)
xmm10 3fee11aacd651245 (f: 3445953024.000000, d: 9.396566e-01)
xmm11 3cc7800000000000 (f: 0.000000, d: 6.522560e-16)
xmm12 bc40000000000000 (f: 0.000000, d: -1.734723e-18)
xmm13 402bb9d3beb8c600 (f: 3199780352.000000, d: 1.386294e+01)
xmm14 3bfc4721da1f8579 (f: 3659498752.000000, d: 9.580912e-20)
xmm15 402bb9d3beb8c600 (f: 3199780352.000000, d: 1.386294e+01)
Module=/usr/java/jdk-9+181/lib/compressedrefs/libj9vm29.so
Module_base_address=00007F822A52F000
Target=2_90_20170915_6 (Linux 4.12.12-300.fc26.x86_64)
CPU=amd64 (8 logical CPUs) (0x3dfa5d000 RAM)
----------- Stack Backtrace -----------
(0x00007F822A5EBA20 [libj9vm29.so+0xbca20])
(0x00007F821BF2D7C4 [libjclse9_29.so+0x457c4])
(0x00007F821BF2DA5B [libjclse9_29.so+0x45a5b])
(0x00007F821BF347C0 [libjclse9_29.so+0x4c7c0])
(0x00007F8229F0B7B4 [libffi29.so+0x67b4])
ffi_call+0x1b8 (0x00007F8229F09EB8 [libffi29.so+0x4eb8])
(0x00007F822A554A9B [libj9vm29.so+0x25a9b])
(0x00007F822A541B3B [libj9vm29.so+0x12b3b])
(0x00007F822A5F82C2 [libj9vm29.so+0xc92c2])
---------------------------------------
JVMDUMP039I Processing dump event "gpf", detail "" at 2017/09/21 15:46:12 - please wait.
JVMDUMP032I JVM requested System dump using '/path/to/openjfx/rt/core.20170921.154612.4490.0001.dmp' in response to an event
JVMPORT030W /proc/sys/kernel/core_pattern setting "|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e" specifies that the core dump is to be piped to an external program.  Attempting to rename either core or core.4526.

JVMDUMP012E Error in System dump: The core file created by child process with pid = 4526 was not found. Expected to find core file with name "/path/to/openjfx/rt/core.4526"
JVMDUMP032I JVM requested Java dump using '/path/to/openjfx/rt/javacore.20170921.154612.4490.0002.txt' in response to an event

Migrate to CMake buildsystem

Long running issue to track progress on migrating openj9 from UMA to CMake/

• Platform Support:

  • xLinux
  • pLinux

Timeline

Nov 23

• Integrate VMCPTool and NLSTool
  • #3675

Dec 17

• JDK 11 Extension changes
  • Remaining changes are ready, just need to open PRs. All fairly trivial, should be merged quickly
  • class library natives
  • redirector
  • #3659
  • #3675
  • #4041
  • #4042
  • #4043

Dec 21

• osx
  • #3293
  • eclipse/omr#3124

March 1

• DDR support for non-windows platforms
  • eclipse/omr#3209
  • eclipse/omr#3308

March 1

• stop staging the source files
  • eclipse/omr#3189
  • eclipse/omr#3213
  • #3725
  • #4928
  • #3726
  • #5341
  • ibmruntimes/openj9-openjdk-jdk11#68

Milestone: First pass of linux x86-64 cmake build modulo any bugs

March 20

• Windows support (un-optimized bytecode interpreter)
  • eclipse/omr#3677
  • eclipse/omr#3669
  • eclipse/omr#3670
  • #5227
  • #5228
  • #5240
  • #5267
  • #5268
  • #5269
  • #5270
  • #5271
  • #5280
  • eclipse/omr#3705
  • #5308

March 22

• Optimized bytecode interpreter on windows

Milestone: First pass of win x86-64 cmake build modulo any bugs

April 12

• AIX Support
• All supported platforms work on cmake
• Turn off UMA

Validation

• TODO: how to validate the cmake build is equivalent to the autotools build?
• Test equivilent build flags between uma and cmake builds
• Testing
• Perf

Misc TODOS

• Copyright info
• Documentation describing how the cmake build is structured

The flsanity test suite is obsolete and should be removed

Also the following functions in util_api.h has declaration only:

I_32 helperDoubleArcCos(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoubleArcSin(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoubleArcTan(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoubleArcTan2Double(ESDOUBLE *a, ESDOUBLE *b, ESDOUBLE *c);
I_32 helperDoubleExp(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoubleIEEERemainderDouble(ESDOUBLE *a, ESDOUBLE *b, ESDOUBLE *c);
I_32 helperDoubleLn(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoublePowDouble(ESDOUBLE * a, ESDOUBLE * b, ESDOUBLE * c);
I_32 helperDoubleRint(ESDOUBLE * a, ESDOUBLE * b);
I_32 helperDoubleCeil(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoubleCos(ESDOUBLE * a, ESDOUBLE * b);
I_32 helperDoubleFloor(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoubleSin(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoubleSqrt(ESDOUBLE *a, ESDOUBLE *b);
I_32 helperDoubleTan(ESDOUBLE * a, ESDOUBLE * b);

The implementations are removed (file flttrig.c/flttrigcldc.c does not exist anymore), so there is no need to keep the declarations.

add vim to the openj9 docker image

Most linux users will expect vi to be available everywhere, so can vim be added to the Dockerfile for the docker image used for building openj9 please?

FAQ link in the README is broken

FAQ link in the README leads to: http://www.eclipse.org/openj9/faq
the link should be http://www.eclipse.org/openj9/oj9_faq.html

Add GC tuning on Idle part of Xtune:virtualized

JVM idle tuning/optimization is not included as part of Xtune:virtualized. It needs to enabled/set as another separate option(XX:+IdleTuningGcOnIdle). As this option will be beneficial to cloud/virtualized environment specific workloads, it is good to include into Xtune:virtualized optimizations.

Test Output unclear

After following the instructions in test/README for testing a built JDK, the test output does not show:

• Number of completed tests
• Number of passing tests
• Number of failing tests

Instead, the final output after the verbose running output is: All Tests Completed which does not clearly indicate if all tests passed or not.

Support for ARMv5 Linux - Headless EABI, SoftFP ABI

Hi,

I would like to make the proposal for Java 9 with support of ARMv5 - Headless EABI, SoftFP ABI.

Currently, Oracle only supports Java 8, for this version:
http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html

But it is important to have the JVM for this version of ARM. Why?
Exist an important LEGO Mindstorms community and it is necessary to add support for them.

Many thanks in advance.

Juan Antonio

javacore does not identify z/OS hardware

The javacore for z/OS shows "OS Level" like "z/OS 02.02.00", and "Architecture : s390x" but no other details about the hardware being used. @joransiu has suggested adding in the raw STFLE bits.

Documentation references "github.ibm.com" which is not visible to the internet

See https://github.com/eclipse/openj9/blob/master/test/README.md where the git examples are referencing github.ibm.com - should be changed to the appropriate location on github.com

cpu entitlement when hypervisor is present

I believe there are two problems in JIT with respect to getting cpu entitlement information from hypervisor:

1. I noticed this code in TR_CpuEntitlement::computeAndCacheCpuEntitlement

   if (_numTargetCpu == 0)
      _numTargetCpu = 1; // some correction in case we get it wrong
   if (isHypervisorPresent())
      {
      _guestCpuEntitlement = computeGuestCpuEntitlement();
      // If the number of target CPUs is smaller (bind the JVM to a subset of CPUs), use that value
      if (_numTargetCpu < _guestCpuEntitlement || _guestCpuEntitlement <= 0)

It looks like _guestCpuEntitlement is in percentage, but _numTargetCpu is not. The condition _numTargetCpu < _guestCpuEntitlement is likely to be comparing incorrect values in that case.

2. Secondly, it appears TR_CpuEntitlement::isHypervisorPresent will always returns false, no matter what.

bool TR_CpuEntitlement::isHypervisorPresent()
   {
   if (_hypervisorPresent == TR_maybe)
      {
      // Caching works because we don't expect the information to change
      // However, we must call this after portlib is up and running
      PORT_ACCESS_FROM_JITCONFIG(_jitConfig);
      if (j9hypervisor_hypervisor_present() > 0) // J9HYPERVISOR_NOT_PRESENT/J9HYPERVISOR_PRESENT/J9PORT_ERROR_HYPERVISOR_UNSUPPORTED
         {
         _hypervisorPresent = TR_yes;
         }
      else
         {
         _hypervisorPresent = TR_no;
         }
      }
   return (_hypervisorPresent == TR_yes);
   }

_hypervisorPresent gets a default value of TR_no. I don't see it ever getting set to TR_maybe which means isHypervisorPresent will always return false.

I hope I have not missed anything here.
@mpirvu, any idea why is it like this? It appears this is just dead code right now.

Add README.md to buildenv/jenkins

At minimum, we should have a readme in the jenkins folder which documents what builds we have and how they run. If it becomes too large we can consider adding a doc folder there too.

related: #91 #122 #175 #176 eclipse-openj9/openj9-omr#3 eclipse-openj9/openj9-omr#4

Travis PR builds broken

Travis pull request builds are broken. They time out cloning openj9-openjdk-jdk9

remote: Counting objects: 565618, done.
remote: Compressing objects: 100% (13/13), done.
Receiving objects:  98% (558063/565618), 776.86 MiB | 160.00 KiB/s   
The job exceeded the maximum time limit for jobs, and has been terminated.

https://travis-ci.org/eclipse/openj9/builds/278682619

Builds on branches still seem ok I have seen the issue strike on branch builds but much less often than on PR builds

Strange performance issues with OpenJ9 in this jmh bench...

I'm creating a jmh version of the benchmarks of The computer language benchmarks game and I decided to try it out comparing OpenJ9 to Zulu9 from azul. Zulu9's performance is around 2600ms/op on my system, but OpenJ9 shows some strange performance issues where it slows down with every successive warmup iteration:

Zulu9 - sbt "jmh:run -i 10 -wi 20 -f1 -t1 -r 15 -jvmusr/lib/jvm/zulu-9/bin/java"
[info] # Run progress: 0.00% complete, ETA 00:05:40
[info] # Fork: 1 of 1
[info] # Warmup Iteration   1: 2630.687 ms/op
[info] # Warmup Iteration   2: 2780.907 ms/op
[info] # Warmup Iteration   3: 2630.115 ms/op
[info] # Warmup Iteration   4: 2587.016 ms/op
[info] # Warmup Iteration   5: 2504.948 ms/op
[info] # Warmup Iteration   6: 2566.648 ms/op
[info] # Warmup Iteration   7: 2537.053 ms/op
[info] # Warmup Iteration   8: 2500.211 ms/op
[info] # Warmup Iteration   9: 2576.959 ms/op
[info] # Warmup Iteration  10: 2517.836 ms/op
[info] # Warmup Iteration  11: 2514.588 ms/op
[info] # Warmup Iteration  12: 2508.471 ms/op
[info] # Warmup Iteration  13: 2548.678 ms/op
[info] # Warmup Iteration  14: 2529.385 ms/op
[info] # Warmup Iteration  15: 2508.744 ms/op
[info] # Warmup Iteration  16: 2475.521 ms/op
[info] # Warmup Iteration  17: 2518.160 ms/op
[info] # Warmup Iteration  18: 2572.912 ms/op
[info] # Warmup Iteration  19: 2605.698 ms/op
[info] # Warmup Iteration  20: 2556.147 ms/op


OpenJ9 - sbt "jmh:run -i 10 -wi 20 -f1 -t1 -r 15 -jvmhome/mhammons/jdk-9+181/bin/java"
[info] # Run progress: 0.00% complete, ETA 00:05:40
[info] # Fork: 1 of 1
[info] # Warmup Iteration   1: 36902.857 ms/op
[info] # Warmup Iteration   2: 41640.554 ms/op
[info] # Warmup Iteration   3: 49802.187 ms/op
[info] # Warmup Iteration   4: 59686.587 ms/op
[info] # Warmup Iteration   5: 69178.086 ms/op
[info] # Warmup Iteration   6: 78664.955 ms/op
...

As you can see, OpenJ9 starts off markedly slower than Zulu9. But what's more concerning is that instead of improving in performance during the warmup phase as is to be expected, the subsequent warmup iterations grow slower and slower on OpenJ9.

The benches were compiled with openjdk 8, and run with a forked jvm by the jmh harness. You can invoke the benches and indicate the jvm to be used to run them with the following command:
sbt "jmh:run -i 10 -wi 20 -f1 -t1 -r 15 -jvm path/to/jvm"

JVM arguments can be supplied with an added -jvmArgs argument. I did this with -Xjit:verbose to test that jitting was occurring, and it was, so this slowdown is puzzling. Another thing I noted while running this bench is that although it is designed to use as much threading as the system's cpus will allow for, half or less of my cpu was unused with OpenJ9.

Create Dockerfiles that allow test execution

Basing from those Dockerfiles that build openj9 (https://github.com/eclipse/openj9/tree/master/buildenv/docker), we should have matching set to allow test execution.

There are a few additional prereqs needed for test (see https://github.com/eclipse/openj9/blob/master/test/README.md for details on testing openj9).

Discussion on the JIT helpers

Recently I was making changes in to CHelper linkage to call helperCFloatRemainderFloat from JIT (#106) to get rid of unneeded assembly glue from Math.m4 to call helper.
While making changes, I realized that the linkage is really specific to the JIT helpers in cnathelp.cpp and needed extra patches to make linkage compatible to call any arbitrary C functions.

• One issue is order of arguments, A call node will have first argument to the function in first child and subsequently other arguments in subsequent child while JIT helpers have this arguments in reverse order (First child is last argument, last child is second last argument with vmThread is first argument). This makes linkage incompatible for using it to call arbitrary C functions and while using it to call other C functions, we need to pass flag to evaluate child in correct order of prepare list of arguments and pass it.

I am opening this issue to start discussion on issues or concerns for refactoring of JIT helpers in cnathelp.cpp and znathelp.m4 to use more consistent C function linkage.

Pull request format check

We will have a mix of people using hosts where LF is the default line-end and Windows where CR/LF is common.

I suggest that we ought to strive for consistency in the repository. After agreeing on the appropriate line-ends for various file types, perhaps we could add a pull-request check that verifies that proposed changes use the expected line-ends?

I haven't found a way in the web UI to tell what line-ends are used by a given file, so an automatic check would be helpful.

Enable travis.ci builds

Now that #25 has been merged, we need to enable travis ci on this repo. I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=522449 with the Eclipse foundation to enable the travis.ci hook on this repo.

Build issue due to missing openj9_version_info.h

Error:

gmake[5]: Entering directory `/apps/was/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/util'
cc -DJAVA_SPEC_VERSION=9 -O3 -fno-strict-aliasing -g -MMD -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64 -fPIC -DIPv6_FUNCTION_SUPPORT -DJ9HAMMER -m64 -Wimplicit -Wreturn-type -Werror -I. -I../include -I../oti -I../gc_include -I/apps/was/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/gc/include -I../nls -I/apps/was/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/vm/omr/include_core -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -DOPENJ9_BUILD -c -o openj9_version.o openj9_version.c
gmake[3]: warning: -jN forced in submake: disabling jobserver mode.
openj9_version.c:27:33: fatal error: openj9_version_info.h: No such file or directory
#include "openj9_version_info.h"
gmake[5]: *** [openj9_version.o] Error 1
gmake[5]: *** Waiting for unfinished jobs....

Workaround:

diff --git a/runtime/util/openj9_version.c b/runtime/util/openj9_version.c
index dee6a0d..ea50f93 100644
--- a/runtime/util/openj9_version.c
+++ b/runtime/util/openj9_version.c
@@ -22,20 +22,10 @@

 /*The file prints out required version information for Xinternalversion option */
 #include "openj9_version.h"
-#if defined(OPENJ9_BUILD)
-/*The file collects version information in OpenJ9 build */
-#include "openj9_version_info.h"
-#endif /* OPENJ9_BUILD */

 void
 j9print_internal_version(J9PortLibrary *portLib) {
        PORT_ACCESS_FROM_PORT(portLib);

-#if defined(OPENJ9_BUILD)
-       j9tty_err_printf(PORTLIB, "Eclipse OpenJ9 %s %s-bit Server VM (%s) from %s-%s JRE (%s), built on %s %s by %s with %s\n",
-               J9PRODUCT_NAME, J9TARGET_CPU_BITS, J9VERSION_STRING, J9TARGET_OS, J9TARGET_CPU_OSARCH,
-               J9VERSION_STRING, __DATE__, __TIME__, J9USERNAME, J9COMPILER_VERSION_STRING);
-#else /* OPENJ9_BUILD */
        j9tty_err_printf(PORTLIB, "internal version not supported\n");
-#endif /* OPENJ9_BUILD */
 }

This clearly isn't the fix, so not submitting a pull request

OpenJ9 is 2 seconds slower than Azul openjdk9 when running this mandelbrot bench...

I compared Azul OpenJDK9 with OpenJ9 to test the performance of OpenJ9 against relatively standard OpenJDK, and found that it is around 2 seconds slower to run the bench.

MandelbrotBench.tar.gz

My system is Fedora 26, and my OpenJ9 -version is

openjdk 9-internal
OpenJDK Runtime Environment (build 9-internal+0-adhoc.jenkins.openjdk)
Eclipse OpenJ9 VM (build 2.9, JRE 9 Linux amd64-64 Compressed References 20170915_6 (JIT enabled, AOT enabled)
J9VM - cea1ed7
JIT  - cea1ed7
OMR  - 617de12
OpenJDK  - 83f5cd0 based on )

Build instructions link in the README.md points to the internal IBM GitHub

The Build instructions link in the README.md points to the internal IBM GitHub: https://pages.github.ibm.com/runtimes/openj9-website/oj9_build.html The correct link to point to on the public OpenJ9 website is https://www.eclipse.org/openj9/oj9_build.html