OpenJ9

[1stian]

Is your feature request related to a problem? Please describe.
It's not related to a problem, rather a more efficient java.

Not sure what more to bring here.. But OpenJ9 has a smaler footprint etc, reduced ram(Better GC) usage and CPU usage.

So is there a way to implement OpenJ9?

https://www.eclipse.org/openj9/

[Wqrld]

It is possible, for instance deploys does this but i'm guessing there is a reason that pterodactyl hasn't implemented it yet?

[parkervcp]

@1stian can you try out quay.io/parkervcp/pterodactyl-images:debian_openjdk-8-openj9 and let me know how it goes?

[1stian]

@1stian can you try out quay.io/parkervcp/pterodactyl-images:debian_openjdk-8-openj9 and let me know how it goes?

This worked great! Thank you.

[mechoriet]

@parkervcp can confirm this has a 100mb+ less footprint/base memory usage
the servers on the left with the original quay.io/pterodactyl/core:java image
the right is the quay.io/parkervcp/pterodactyl-images:debian_openjdk-8-openj9 image

server left launch options:
java -Xms128M -Xmx{{SERVER_MEMORY}}M -jar {{SERVER_JARFILE}}
server right launch options:
java -Xms128M -Xmx{{SERVER_MEMORY}}M -XX:+IgnoreUnrecognizedVMOptions -XX:+UseContainerSupport -XX:+IdleTuningCompactOnIdle -XX:+IdleTuningGcOnIdle -jar {{SERVER_JARFILE}}
both graphs are from the same server data cause we have 2 of them
so a good test

the only thing i get with the new image is

[13:17:52 WARN]: [HolographicDisplays] Unable to get a stack trace element, please inform the developer. You will only see this error once and a fallback method will be used.
java.lang.NoSuchMethodException: java.lang.Throwable.getStackTraceDepth()

but its not gamebreaking from what i see the holographicdisplays are displaying as normal

gonna keep it running for a few days and will report back on what i noticed if thats okay

[mechoriet]

3 hours in update

left server memory 444mb
right server memory 210mb

will keep running it like this for a day
then ill run them with the same launch options just to reassure its not from the launch options
for the same length

[mechoriet]

24 hour update post:

left server memory 519mb
right server memory 245mb
just for extra context about the servers running:
the two servers are both loginservers meaning alot of player connecting/disconnecting,
so lots of objects are being created/released every minute.

[mechoriet]

i was surfing the net last night
and found something that could potentially scrape off more footprint
Google Distroless image
and maybe base memory usage

what it does a very small base image (smaller then alphine i think)
Base Image

havent tested this yet if i could get this to work with ptero cause the way ptero starts the program is different then how that image does it

this is a openjdk8 image
openjdk8/11 image

and this is the openjdk11 example container(it was upgraded)
the example Dockerfile

[mechoriet]

@parkervcp
am i right that this gets injected always to the jvm
https://github.com/AdoptOpenJDK/openjdk-docker/blob/master/8/jdk/debian/Dockerfile.openj9.releases.slim#L68

if so then the second test is kinda redundant to do

[parkervcp]

I am using the openj9 image as a base. So if it's in there then it is injected every time.

[mechoriet]

I am using the openj9 image as a base. So if it's in there then it is injected every time.

okaj then ignore my second test of the same server

ill try to do it in a more block/action active server see the difference there
can`t test like the test above cause there is only one server of it

so the result will be a graph of heapmemory of last 24hr and the test 24hr

is that accurate data for you @parkervcp or do you need the docker memory value`s?

example of the graph:

[mechoriet]

this is the 48hour graph
the redline in the middle represends the restart point

hope this gives a good amount of info it this image is goodgood

[DaneEveritt]

Thanks, I believe our plan is to release an office OpenJ9 image independent of the current egg so that people can switch to it on their own. :)

[parkervcp]

This is resolved by the existence of this now - https://github.com/pterodactyl/images/tree/java-8-openj9

[melvyn2]

Paper is planning to drop java <11 support, and the only java 11 image is the HotSpot one; is an openj9 image planned?

[DiscoverSquishy]

@melvyn2 To be honest, when I was building the Velocity egg I did some testing with J11 & J15 both OJ9 and HotSpot and hot spot won in stability and startup time. However feel free to do some testing in paper's eggs using the images quay.io/discoversquishy/dockerimages:openjdk-11-openj9 // quay.io/discoversquishy/dockerimages:openjdk-11-hotspot

I'd guess the best way to make this happen if you think it's worth it after testing would be to make a PR in @parkervcp's egg repo & images repo if the images aren't updated.