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. Later, Brad
