> You still need to malloc() your memory; however I realize that the
> allocator can be *really* fast here. But still, you give a lot of the
> gain back during the mark-and-sweep phase, especially if you also
> move/compact the memory.
As you said, the allocator can be really fast. Most advanced gc will
use thread local heap to allocate temp objects, so we don't even have
to sync or membar. The mark-and-sweep is ok for small heap, < 1MB.
For large heap, we can use concurrent gc, multi-threaded gc, multi-heap.
Normally large heap implies SMP, so we have some cpu power to steal to
do expensive gc.
> The big gain only comes in when your program is small/quick enough to
> actually finish before the GC kicks in the first time (think CGI). In
> that case you just discard the whole heap instead of doing a proper
> garbage collection (unless of course someone thought they
> could still do
> something inside a finalizer during global destruction and
> you still need
> to finalize every other object on your heap :).
As I said, the finalization should be discouraged. It is application's
problem if it uses extensive finalization, just like an application uses
bubble sort instead of qsort, there is not much we can do here. That is
one of mistakes of Java. Java promises too much. To do so, Java carries
significant overhead to fullfill its promise. For example, Java has 6+
different types of weak reference, including finalization reference.
There are very few people in the world can understand the difference.
What is the point to have them just for those smart but few people.
> Don't even dream of accessing Perl scalars simultaneously from multiple
> threads without some kind of locking.
That is the problem of Perl. In Smalltalk, every primitive object is
immutable -- Integer, Float, Fraction, Symbol. The String, Array, ByteArray
have fixed size. So there is no need for any synchronization. If you want
to mess up your Array using MT, just do it. In the end, you will get a
messy array, but you can not hurt the system/runtime in anyway.
> You want a modifiable buffer? Get a StringBuilder
> object and lock it on every access.
That is one of stupid design of Java. If I need sync, I can do it myself.
Why StrinBuffer, Vector, Hashtable, XXXStream sync on every access? Stupid.
If I want to have a multi-read data structure, I have to write my own.
What is the point???
Hong
