Brad Roberts wrote:
Andrei Alexandrescu wrote:
Weed wrote:
Weed пишет:
4. Java and C# also uses objects by reference? But both these of
language are interpreted. I assume that the interpreter generally with
identical speed allocates memory in a heap and in a stack, therefore
authors of these languages and used reference model.
Neither of these languages are interpreted, they both are compiled into
native code at runtime.
Oh!:) but I suspect such classes scheme somehow correspond with
JIT-compilation.
I guess allocation in Java occurs fast because of usage of the its own
memory manager.
I do not know how it is fair, but:
http://www.ibm.com/developerworks/java/library/j-jtp09275.html
"Pop quiz: Which language boasts faster raw allocation performance, the
Java language, or C/C++? The answer may surprise you -- allocation in
modern JVMs is far faster than the best performing malloc
implementations. The common code path for new Object() in HotSpot 1.4.2
and later is approximately 10 machine instructions (data provided by
Sun; see Resources), whereas the best performing malloc implementations
in C require on average between 60 and 100 instructions per call
(Detlefs, et. al.; see Resources)."
Meh, that should be taken with a grain of salt. An allocator that only
bumps a pointer will simply eat more memory and be less cache-friendly.
Many applications aren't that thrilled with the costs of such a model.
Andrei
Take it as nicely seasoned. The current jvm gc and memory subsystem is
_extremely_ clever. However, it completely relies on the ability to
move objects during garbage collection. If it was purely the allocator
that behaved that way, you'd be right. But it's interaction with the gc
is where the system comes together to form a useful whole.
I understand. My point is that a 10-cycles-per-allocation allocator will
necessarily use more memory than one that attempts to reuse memory.
There's no way around that. I mean we know what those cycles do :o).
Some application don't work well with that. Escape analysis does reduce
the number of cache-unfriendly patterns, but, as of today, not to the
point the issue can be safely ignored.
There's no contention that GC has made great progress lately, and that's
a great thing.
Andrei
