Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eclipse OpenJ9 – Open-source JVM

github.com

Post reply on HN
Print view View original

41–50 of 105 posts

Re: Eclipse OpenJ9 – Open-source JVM

#41

Post by jsiepkes »

pron wrote: post #31
bobsgame wrote: post #25

Earlier quoted context omitted.

One example would be game development, where people end up doing object pooling to avoid GC pauses dropping frames.

There are better ways to eliminate GC pauses than manual memory management (even ignoring the relatively new "pauseless" GCs). See the new RTSJ (realtime Java) specification here: https://www.aicas.com/cms/en/rtsj . Not that it's designed for far stricter requirements than games (cases where even microseconds of unexpected latency may result in actual life safety concerns). Manual memory management is a good choice i…

JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector (http://openjdk.java.net/jeps/189) could help with that.

Re: Eclipse OpenJ9 – Open-source JVM

#42

Post by merb »

kuschku wrote: post #36
pron wrote: post #31

Earlier quoted context omitted.

There are better ways to eliminate GC pauses than manual memory management (even ignoring the relatively new "pauseless" GCs). See the new RTSJ (realtime Java) specification here: https://www.aicas.com/cms/en/rtsj . Not that it's designed for far stricter requirements than games (cases where even microseconds of unexpected latency may result in actual life safety concerns). Manual memory management is a good choice i…

The RTSJ solution is to simply pre-allocate everything you could ever want and reuse that. That’s horrible to use for game development.

I'm not a game developer, so why is that horrible? consider I have an array/map of my game objects and the rest only works with methods, so most stuff does not lie on the heap, well that means basically no strings, since they would add to heap memory aswell, but only using basic datatypes and arrays.

why would some kind of that be problematic? I mean graphics programmic is kind of new to me, but considering that you could offload that to a c/c++ engine via jni (that's another horrible thing of some kind), but just the game code itself doesn't seems to be to bad, does it?

Re: Eclipse OpenJ9 – Open-source JVM

#43

Post by kodablah »

filereaper wrote: post #10
kodablah wrote: post #5

So is this OpenJDK-derived? If so, too bad, I've been hoping for a truly independent implementation. If not, does it pass the TCK?

Ex-J9 engineer here, J9 was built completely in a clean-room. It does pass the TCK tests.

Will they now be denied to use the TCK going forward like Harmony was? If not, why? Because they were proprietary first? Because Oracle likes the Eclipse license better than the Apache one?

Oracle has stated that for open source, only OpenJDK derivatives get access to the TCK.

Re: Eclipse OpenJ9 – Open-source JVM

#44

Post by bitwize »

shemnon42 wrote: post #24
bobsgame wrote: post #21

Will a Java expert (JVM developer) please answer this question? Thank you. How impossible would it be to add a delete keyword to the JVM, and why?

Java does memory recovery strictly by garbage collection. To delete an object remove all references to that object and wait. A "delete now" operation imposes requirements on implementations that are not strictly required. Any advantages gained from destructors can be realized via explicit cleanup methods and (as a hedge against mis-use) state checking for initialized and destroyed objects. A delete operation also add…

What about the "automatically gets cleaned up when the object goes out of scope" advantage of destructors?

Re: Eclipse OpenJ9 – Open-source JVM

#45

Post by guipsp »

bitwize wrote: post #44
shemnon42 wrote: post #24

Earlier quoted context omitted.

Java does memory recovery strictly by garbage collection. To delete an object remove all references to that object and wait. A "delete now" operation imposes requirements on implementations that are not strictly required. Any advantages gained from destructors can be realized via explicit cleanup methods and (as a hedge against mis-use) state checking for initialized and destroyed objects. A delete operation also add…

What about the "automatically gets cleaned up when the object goes out of scope" advantage of destructors?

You can do that with try-with-resources

Re: Eclipse OpenJ9 – Open-source JVM

#46

Post by solarengineer »

emmelaich wrote: post #18
oblio wrote: post #17

Earlier quoted context omitted.

ECJ is in Tomcat? What for?

Compiling Java :-) To be more precise, a compiler is required for JSP, which is a mixture of html and java that is compiled to servlets. Theoretically you can compile them ahead of time (before deployment) but as far as I can tell no-one does.

Those who want to provide only class files and no jsp code use the JSP pre-compilation approach. The JSP folks get compiled to Java servlet byte code the same as at runtime.

Re: Eclipse OpenJ9 – Open-source JVM

#47

Post by kodablah »

hyperrail wrote: post #13

It seems like such a long time ago since Sun/Oracle and Apache Software Foundation fought over the licensing of the Java Technology Compatibility Kit (Java implementation test suite) for Apache Harmony, their JVM and Java class library implementation which was used as part of Android for a long time.[1,2] Hopefully OpenJ9 will meet with better success. On paper, it seems to meet the restrictions that Oracle currently…

> namely that it is available under a GPL license

Not exclusively from what I see, seems you can choose the Eclipse Public License. From your #4 link:

> Licensee may not: [...] (iii) distribute a Licensee Implementation under any license other than a GPL License

I hope they revoke their TCK license personally (ex-dev below stated it passed). I would hope then implementations would stop supporting this "Java" naming/certification single-company gatekeeping and instead support and contribute to the open test suite.

Re: Eclipse OpenJ9 – Open-source JVM

#48

Post by hiram112 »

jsiepkes wrote: post #40
vbezhenar wrote: post #30

That's awesome. It was always some weird situation with abstract JVM specification but only one de-facto standard implementation which everyone used. I hope J9 will be a viable alternative, so everyone wins.

How so? There was BEA JRockIT, IBM J9, Azuul, Oracle and HP also have a JVM iirc.

I've been a Java dev for a decade, and I never once used anything but Sun / Oracle's version (now OpenJDK, which is almost the same thing).

I really have no idea who ever used these other JVM implementations. I'm guessing it would be companies with specialized hardware such as IBM mainframes or finance firms paying a lot of money to squeeze out performance with WebLogic. Either because of poor marketing or some other reason, no developer or company I worked with had a reason to use anything else.

Re: Eclipse OpenJ9 – Open-source JVM

#50

Post by rlp »

bobsgame wrote: post #25
koolba wrote: post #23

Earlier quoted context omitted.

Why would you want to add a delete keyword? Are you trying to add explicit memory management to simplify the work of the garbage collector?

One example would be game development, where people end up doing object pooling to avoid GC pauses dropping frames.

Even in game development in C/C++, you wouldn't want to be allocating/deleting heap objects in every frame. You'd probably end up pooling there too, unless you're referring to the problem that the JVM has no value types and forces heap allocation for all objects. This will be fixed in JDK 10 (see Project Valhalla).
Post reply on HN