On 12/7/2010 6:52 AM, Tom Anderson wrote:
On Mon, 6 Dec 2010, Lew wrote:
Peter Duniho wrote:
well, then presumably the value-type is inlined within the class or
similar, rather than being placed on the stack. this is no big issue.
Currently, in the present, likely on your very computer, the
(commercial) JVM (at least in "-server" mode) will inline some things,
enregister others, and convert references into stack-based primitive
values. It's already doing the implementation strategies that have
been mentioned here.
But only where it can prove by escape analysis that it is safe to do so.
Having value types would allow it to prove that of much more code.
yes, having an optimization is one thing, proving where one can safely
use it is another.
a struct need not be "that" much different than a class WRT how the VM
handles it (nevermind the semantic differences), but it does give a very
big hint to an optimizer that it may safely put the thing on the stack,
even when passed around, since it knows that no references to it may
ever be directly captured (only ever copies of it).
this is why, for example, C has some number of little keywords which may
be ignored by the compiler, but may also provide helpful optimizer hints.
it is because, otherwise, there are things that a human programmer may
realize but are beyond the ability of an optimizer to safely infer.
a hint like:
"unless I return the thing, its lifetime WILL end at the end of this
function scope" is a bit stronger than, say, "well, if you can safely
prove that this object is not captured anywhere, then its lifetime may
end at the end of the function scope".
it is in-fact such a big hint that a naive VM can just do it and still
get it right.
safe to optimize, say to place on the stack, even when it might not be later.
situation changes. So Hotspot can invoke these optimizations even when static