Hacker News new | ask | show | jobs
by slavapestov 2924 days ago
> Suppose everything - even every int - is heap-allocated. You now need a very sophisticated JIT compiler (as in, better than any we have today), or it's going to run dog slow.

Most dynamic language implementations (JavaScript, Lisp, Smalltalk, even Ruby) use a tagged pointer representation allowing integers (and sometimes floats) to be encoded directly in the reference, avoiding heap allocation in this common case.

Another alternate model is to pass the type of a value separately from the value itself, and allow the value to be of variable size.

Java simply made the wrong tradeoff, and while it wasn't fully apparent at the time, there's no good defense of that decision today.
2 comments
mac01021 2924 days ago
Most dynamic language implementations don't let me inline a bunch of 128-bit or 256-bit values in an array, or allocate them on the stack.

Code that deals with a lot of values which are small but larger than a machine word can be made a lot more efficient if there is a way to treat those values as not objects.

link
slavapestov 2924 days ago
That is true, but the original poster was talking about heap allocation of simple integers, not larger values.
link
MaxBarraclough 2924 days ago
> tagged pointer representation allowing integers (and sometimes floats) to be encoded directly in the reference

I don't see how that could work for Java. Every Java object can be used as a mutex. This strikes me as very silly, but it's part of Java. Incidentally .Net went the same way, and I'm not the only person who thinks it was a silly decision for both frameworks [0]

Java also tags objects with type information for runtime checking, but that would play ok with tagged pointers as you're describing, as far as I can see.

Seems to me .Net generally has the right idea on types. Primitives are not objects, but you can do List<int> without autoboxing.

> Another alternate model is to pass the type of a value separately from the value itself, and allow the value to be of variable size.

Wouldn't that bloat the stack considerably? Wouldn't it be better to have a type-system that eliminates the need for that sort of thing?

> Java simply made the wrong tradeoff, and while it wasn't fully apparent at the time, there's no good defense of that decision today.

Are there any modern frameworks at all similar to Java, that do as you describe? Dog-slow dynamic languages aren't really the same beast.

[0] https://stackoverflow.com/a/282342/

link