Hacker News new | ask | show | jobs
by quelltext 1029 days ago
From the start I was wondering if there's no way for the JVM to solve this with less cruft on the bytecode level. Of course, that doesn't mean I was aware of the challenges, just an intuition.

I do think they must have had similar intuitions in the beginning. Then identified big challenges with that and that what would be needed to overcome it more streamlined is some set of features or optimizations. It seems though that these emerged in isolation? At least to cross the threshold to saying "there's a way".

Seeing how long Valhalla has been in development, I'm curious how things went the way they did. The article mentions hindsight but that alone doesn't explain the change in direction.

2 comments

There is always the cheap way out - generate garbage bytecode and leave it to the hotspot team to clean up the mess with intrinsics. Sort of like the vector API is implemented with objects, but obviously no one wants allocations in the middle of tight vector loops, so HotSpot just treats them as a special case.
This was not so much a „change in direction“ but rather having a guiding model which assumes the worst case. But by now enough evidence has emerged that the same performance can be achieved with object descriptors.

Discussion on the mailing list: https://mail.openjdk.org/pipermail/valhalla-spec-experts/202...