> Most GCs want to be able to compact the heap, that means they lean in favor of reference based models by default.
I don't see how this follows. Copying GCs do compact the heap, but when you use values you're basically saying "these two things go together". You're only making life easier for the GC (well, you're also creating larger objects, but that might just require a small adjustment of the GC strategy).
> how long till we can reasonably see this in production?
Four years probably... Still, that doesn't change the fact that layout and GCs are orthogonal.
Expanding on my point a bit, I'm not arguing that in theory GC and memory layout are orthogonal.
Just that in practice you don't see memory layout in languages that are managed. Since I'm usually not in a habit of building a new languages to solve problems it's something worth understanding when making a technical selection on a language.
Most GCs want to be able to compact the heap, that means they lean in favor of reference based models by default.
It's not exclusive like you mention but to my knowledge C# is the only language with explicit guarantees. I was aware of the effort around Java's value types, however how long till we can reasonably see this in production?
You can do this in Java today but it involves lots of nasty ByteBuffer manipulation(in which FlatBuffers is fantastic for). You'll still pay for the conversions from bytes to the actual types you want.
If you're dealing with these types of performance problems it's best to treat them with a language that's well suited to deal with them. There's nothing wrong with using Java for higher level business logic and delegating the heavy lifting to a stack that's designed to deal with them.