I suspect that I can improve realloc some, as the memcpy routine is never inlined apparently on PPC, by wrtiting my own memcpy. Looked around the net and already found an Altivec memcpy. I wonder how much memory one needs to move, so that it becomes a win, as context switches for non-Altivec code are bound to become much slower. (Sames goes for using doubles in memcpy).
Comments (4)
Why invest work in such a project? As you may have noticed, Apple was actively searching for someone extending the Objective-C runtime for garbage collection!
Obviously this is going to use BoehmGC:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/index.html
which is actually faster than most system malloc implementation! So just ensure that Boehm GC works as a drop in replacement and we get:
FAST malloc,
garbage collection
and
leak tracking
for free.
Posted by The One | July 20, 2003 3:31 AM
Posted on July 20, 2003 03:31
What an excellent idea! Instead of wasting resources on a reimplementation of malloc, we can reuse a well proven malloc library.
Hell, this is even used for the gcj Java runtime, so it has to
be rock solid, being taken as a base for a language relying
on GC.
Posted by Blub | July 20, 2003 3:34 AM
Posted on July 20, 2003 03:34
Hm. All this seems quite nice, but does Boehm GC actually use DOM to represent the malloc management structures like Mullocator?
A malloc library without the ability to serialize it's management structures into XML for further processing using XSLT into XUL UIs seems pretty useless to me!
And doesn't JavaScript already come with J2EE compliant memory management anyway?
Posted by SpiderMonkey | July 20, 2003 3:37 AM
Posted on July 20, 2003 03:37
Garbage collection! Phoeey :)
Who cares about "faster than most", when you can be "faster than all" ? To quote ZNeK, "Being Nr. 1 isn't everything, but being Nr. 2 is nothing."
Thanks for the DOM hint, i think I'll secretly rewrite my code.
Posted by Nat! | July 20, 2003 11:33 PM
Posted on July 20, 2003 23:33