Hello Bill,
2009/1/13 Weed <[email protected]>:
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
Recently, I started looking into garbage collection theory. Of course, the
first source I went to was Hans Boem's. Here's a couple of links that might
be interesting:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html
http://www.hpl.hp.com/personal/Hans_Boehm/gc/conservative.html
And a whole list of other articles here:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Lots of interesting material... and a fair bit of it is over my head. But,
nonetheless, the fundamentals are there. I'm not sure if some of there studies
are accurate, biased, or out-dated since I don't keep up with state-of-the-art
gc research. But, it seems to me, that Hans is still one of the top experts
in the field, so some of what's there must be very pertinant.
-JJR
