Re: Heap vs Stack allocation

["Randy Brukardt" <randy@rrsoftware.com>]

"Lionel Draghi" <Lionel.nospam.Draghi@Ada-France.org> wrote in message
news:434c2709$0$21298$626a54ce@news.free.fr...
> The paper "Java theory and practice: Urban performance legends,
> revisited - Allocation is faster than you think, and getting faster"
>
(http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-l
nxw07JavaUrbanLegends)
> explains (as far as I understand) how JVMs optimize "on-the-fly" memory
> allocation to use stack instead of heap, by using "Escape Analysis".
>
> My feeling is that those writing JVMs are working hard to guess the data
> lifetime and optimize memory allocation accordingly, because the
> language is unable to express this data locality.
> I think that Ada semantics open much more opportunity to use the stack
> (or registers).
> Am I right, or is this "Escape Analysis" something really powerful?

I guess I would see these as somewhat Apples and Oranges; the JVM is an
interpreter, and that opens a lot of possibilities that aren't every going
to be possible for purely static analysis. Moreover, pretty much everything
that can be done statically can also be done by pure analysis if you want to
spend enough time. (For instance, you don't need strong type to produce good
code, but it certainly makes the job a lot easier.)

That said, I think the more information that the programmer can provide the
compiler about what they're doing, the better code that can be generated.
I'm still convinced that, given a big enough budget, an Ada compiler can
produce faster and smaller programs than that for any of the other
"contenders". But you'd need an Ada-specific optimizer to take full
advantage of the information that Ada provides, and it's probably not cost
effective to create those.

In all honesty, that doesn't matter that much. That last 10% of speed or
space probably doesn't matter in the vast majority of uses. (Which is
probably the real point of the "urban legend" article) What does matter is a
lot of issues that have nothing much to do with the compiler -- tools
support, library support, and language capability.

                               Randy.