Hacker News new | ask | show | jobs
by pjmlp 3172 days ago
The trend of finally adopting AOT on OpenJDK and .NET (NGEN is just for faster startup) kind of prove the point they should have offered AOT since v1.0 instead of leaving it to third parties.

Another example is the ongoing efforts to improve their support for value types.

A 20 years delay to catch up with what Common Lisp, Eiffel, Modula-3 and Oberon variants already offered in those days.

1 comments

Well AOT even in OpenJDK is not necessarily about resource savings, just startup time. Native code is much larger than the equivalent bytecode, so compiling lots of cold code that's rarely used AOT to native can make things more bloated and slower, rather than tighter and faster.

I suspect we'll see the same thing for value types: it's not going to be quite the easy win it seems. Even in C++, it's easy to create accidental footprint explosions with templates and lose performance to excessive copying with value types. And C++ allows mutable values, which are out of fashion now so Java won't allow them ...

I was curious if the article would mention memory chips that knew how to do bulk memmoves by themselves. Does anyone know if memory subsystems can already do that? If you issue a memmove() for, say, 3kb of memory, does the CPU still have to read it all into the cache and then immediately write it out again, or is there some way the CPU can signal to the DRAM chips that they should do the copy themselves? Fast copying of memory would be useful for GCs.

30 years ago we had blitter chips dedicated to moving memory around without using cpu, pretty sure most memory controllers would have something similar these days
memcpy is done by the CPU core, at least for x86. The IMCs don't process data.

The CPU core has more bandwidth than the IMC anyway, so there would be no speed-up from adding this complexity to the IMC (it would not only need to perform the operation, but it would also need a way to maintain cache coherence and communicate with the issuing CPU, none of which is a problem if you just do it in the core). It might not even save power.

> Well AOT even in OpenJDK is not necessarily about resource savings, just startup time.

No quite, the long term idea is to bootstrap OpenJDK as much as possible, making it a meta-circular VM.

Check Project Metropolis and SubstrateVM projects.

Also the commercial JDKs with AOT support, do it for deployment scenarios where JIT isn't desired, e.g. embedded devices.