OpenJ9
JDK
OpenJ9 | JDK | |
---|---|---|
7 | 193 | |
3,216 | 18,442 | |
0.1% | 1.4% | |
9.9 | 10.0 | |
3 days ago | 3 days ago | |
Java | Java | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
OpenJ9
-
I have been trying to make a second server but at the moment I am getting errors does anyone know how to fix?
Source
-
OpenJDK Proposes Project Galahad to Merge GraalVM Native Compilation
I keep forgetting about J9 but they're not doing themselves any branding favors since there actually is J17 on J9 :-/ https://github.com/eclipse-openj9/openj9/blob/openj9-0.35.0/... (Also that 0.35 versioning ...)
As best I can tell, these are the docker images: https://hub.docker.com/_/ibm-semeru-runtimes
$ docker run --rm ibm-semeru-runtimes:open-11-jdk java -version
-
IBM Semeru Runtimes (Eclipse OpenJ9 JVM)
On another note, I'm still not sure if there is a viable way to microbench code running on OpenJ9. It seems that there is still no official support from JMH, at least I'm getting warnings such as "This VM is not supported by JMH. The produced benchmark data can be completely wrong". Apparently it should work, however, my results for runs on OpenJ9 show (by a large margin) much higher variance compared to Hotspot which doesn't exactly inspire confidence.
-
Increasing Performance with OpenJ9 GC Tuning - a guide
-Xjit:disableGuardedStaticFinalFieldFoldingFlat out improves performance, working around a bug in -XaggressiveEnables performance optimizations and new platform exploitation that are expected to be the default in future releases of OpenJ9. -Xmns128M -Xmnx1024MSets minimum and maximum size of the nursery for the gencon (default) GC. Having a small nursery allows garbage collection to be really fast, especially with how many short lived objects Minecraft makes. These values shouldn't need to be changed.If you want to know more about the gencon GC and its nursery and tenure zones you can find something here. -XdisableexplicitgcDoesn't allow mods to force a full garbage collection. Removes some lagspikes from misbehaving mods. -Xgc:concurrentScavengeLets gencon GC collect garbage in the background, without stopping the game thread to do it. Gives a very noticeable boost to "smoothness". -Xgc:dnssExpectedTimeRatioMaximum=95 -Xgc:dnssExpectedTimeRatioMinimum=70Lets gencon GC know that it's gotta spend most of its time cleaning up the nursery, instead of the rest of the heap. Most of the garbage is in the nursery instead of the tenure zone so this works incredibly well on modded MC.
-
IBM joins Eclipse Adoptium and offers free certified JDKs with Eclipse OpenJ9
I like this part "We continue to employ dozens of developers that work directly and openly in the Eclipse OMR and Eclipse OpenJ9 projects at GitHub. IBM doesn’t produce a separate enterprise version of OpenJ9; we don’t hold back any of the innovation in our runtime."
-
Is there any other updated implementation of the Java class library?
OpenJ9 (heavily based on OpenJDK, especially later versions): https://github.com/eclipse/openj9/blob/master/jcl/src/java.base/share/classes/java/lang/Throwable.java
-
Is Lombok in danger of becoming incompatible with future JDK's?
In 1.18.16 they "added support for compiling projects with OpenJ9". Turns out the hack to access Hotspot's sun.misc.Unsafe doesn't quite work with OpenJ9 . Oh, really? So surprising. This is exactly the reason why the OpenJDK project pushes their encapsulation agenda so hard!
JDK
- Intel submitted OpenJDK PRs for supporting new 64 bit general purpose registers
-
Show HN: I Built a Java IDE for iPad
I felt out of the loop, thinking that Zero VM was some kind of new distro for OpenJDK but chasing <https://packages.debian.org/sid/openjdk-22-jre-zero#:~:text=...> to <https://sources.debian.org/src/openjdk-11/11.0.23%2B9-1/debi...> lead me to https://github.com/openjdk/jdk/tree/jdk-22-ga/src/hotspot/cp...
It seems that it's a specific CPU target for the Hotspot JIT for non-mainstream architectures (or for research purposes, as I saw mentioned once)
- JEP draft: Exception handling in switch
-
Java 23: The New Features Are Officially Announced
Completely gutted from the OpenJDK, last I checked. See here for the culprit PR: https://github.com/openjdk/jdk/pull/18688
-
macOS 14.4 might break Java on your machine
> Yes, they're changing one aspect of signal handler use to work around this problem. They're not stopping the use of signal handlers in general. Hotspot continues to use signals for efficiency in general. See https://github.com/openjdk/jdk/blob/9059727df135dc90311bd476...
This whole thread is about SIGSEGV, and specifically their SIGSEGV handling. However, catching normal signals is not about efficiency.
Some of their exception handling is still odd: There is no reason for a program that receives SIGILL to ever attempt continuing. But others is fine, like catching SIGFPE to just forward an exception to the calling code.
(Sure, you could construct an argument to say that this is for efficiency if you considered the alternative to be implementing floating point in software so that all exceptions exist in user-space, but hardware floating point is the norm and such alternative would be wholly unreasonable.)
> The wonderful thing about choosing not to care about facts is having whatever opinions you want.
I appreciate the irony of you making such statement, proudly thinking that your opinion equals fact, and therefore any other opinion is not.
This discussion is nothing but subjective opinion vs. subjective opinion. Facts are (hopefully, as I can only speak for myself) inputs to both our opinions, but no opinion about "good" or "bad", "nasty" or not can ever be objective. Objective code quality does not exist.
-
The Return of the Frame Pointers
I remember talking to Brendan about the PreserveFramePointer patch during my first months at Netflix in 2015. As of JDK 21, unfortunately it is no longer a general purpose solution for the JVM, because it prevents a fast path being taken for stack thawing for virtual threads: https://github.com/openjdk/jdk/blob/d32ce65781c1d7815a69ceac...
- JDK-8180450: secondary_super_cache does not scale well
- The One Billion Row Challenge
- AVX2 intrinsics for Arrays.sort methods (int, float arrays)
- A gentle introduction to two's complement
What are some alternatives?
Avian - [INACTIVE] Avian is a lightweight virtual machine and class library designed to provide a useful subset of Java's features, suitable for building self-contained applications.
Graal - GraalVM compiles Java applications into native executables that start instantly, scale fast, and use fewer compute resources 🚀
ParparVM
aircraft - The A32NX & A380X Project are community driven open source projects to create free Airbus aircraft in Microsoft Flight Simulator that are as close to reality as possible.
jmh - https://openjdk.org/projects/code-tools/jmh
steam-runtime - A runtime environment for Steam applications
Error Prone - Catch common Java mistakes as compile-time errors
OkHttp - Square’s meticulous HTTP client for the JVM, Android, and GraalVM.
es4x - 🚀 fast JavaScript 4 Eclipse Vert.x
kitten - A statically typed concatenative systems programming language.
jmurmel - A standalone or embeddable JVM based interpreter/ compiler for Murmel, a single-namespace Lisp dialect inspired by Common Lisp
intellij-community - IntelliJ IDEA Community Edition & IntelliJ Platform