Hacker News Reader

Comment by ggm | Hacker News Reader

It's also a tribute to the hosted VMs and the framework in general. Virtualisation has been an amazing boost, to reliability. Get on a platform with variant HW and then expose it as an idealised machine, to clients which can behave predictably.

I ran NetBSD systems for years, but I don't think any of the BSD I have operated managed 13 years. Even 3-4 years felt like a big win!

I think how manufacturers of embedded OS looked at the field and went VxWorks, Linux or BSD is interesting too. By no means is it automatic you go to a linux kernel for a small device.

View on HN

>It's also a tribute to the hosted VMs and the framework in general. Virtualisation has been an amazing boost, to reliability. Get on a platform with variant HW and then expose it as an idealised machine, to clients which can behave predictably.

It's ironic that Java was supposed to be that idealized machine, but native virtualization caught up. The JVM has it's benefits, but x86 itself ended up eating java bytecode's lunch, which isn't something anyone predicted. Indeed, even javascript of all things is becoming a strong contender for this role, something no-one predicted either.

Java VM and especially GC tuning, like Oracle DBA tuning, seems to be a black magic art few learn. I disliked XML configuration immensely, and have had some instances where (earlier, pre jdk11) JVM did not understand they had to introspect to be told how much memory they had (arguably the fault of the container/virtualisation they in turn sat inside)

I still run all my PROD JVM applications with `-Xms=a -Xmx=a` to just remove all questions about heap memory. I already allocated that slice of the machine's memory for the application; I don't need the JVM trying to handle shrinking and growing it. This also removes pressure from the GC if the amount allocated is some multiple of typical operations. A lot more operations complete without ever leaving generation 0.

JVM solves a very different problem. It makes some very strong assumptions: everything is an object (no functions!), garbage collection, no easy structs, etc. All this prevents easy porting of lots of existing software written in C, C++, Fortran, etc. In exchange you can be oblivious of the underlying OS and even CPU architecture.

Instead, x64 virtualization easily allows to run not just your existing software, but your existing OS, at practically native speed.

FYI. Java has functions now as well, although they are indeed also objects. Records have been introduced as a flavour of structs.

Java has functions, JVM does not :)

Records are indeed a serious change. (Fibers, too.)

JVM runs a bunch of languages that are pretty dissimilar to Java, like Clojure or JRuby. It takes certain creativity, but it works pretty well.

Java the language has a lambda / function-literal syntax, not first-class functions. (You know this, obviously.)

The `struct` bit can refer to a few things: value typing, stack allocation, and explicit memory layout. I think records give you value typing, but not stack allocation or explicit memory layout. They are just syntactic sugar for immutable POJOs.

It's not quite true that everything is an object. In fact, Java famously has a primitive/object split.

I see the JVM is getting new relevance when it comes to x86 and arm.

Reply on news.ycombinator.com