2009/1/13 Weed <resume...@mail.ru>: > Andrei Alexandrescu пишет: >> 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 > > 10 *cycles* per allocation? > >> 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. > > In any case, we cannot add such memory manager in D. And such resource > allocation does not approach us, and mandatory creation of objects in a > heap does not approach for D.
I'm not and expert in garbage collection but... An interesting point was made yesterday on the GDAlgorithms mailing list. Acording to this one game industry veteran, you don't need a fully moving garbage collector to get many of the benefits. If *some* of the memory can be moved around then often that's enough to fill in the gaps and keep fragmentation down. So it may be worth while to have a special kind construct for containing data that the compiler is free to move around. This type would have a hidden pointer inside of it that can be moved around by the gc, but applications would not be allowed to access that pointer. And I suppose that means all access to the data would given via lvalue only. Probably wouldn't take much on the part of the GC to provide the necessary hooks. Just some sort of "relocatable alloc" call. Rest could probably be handled in higher level libs. But like I said I don't know much about GC. --bb
