From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <7d0c2d03cf49fc0835ab54c2f203c90b@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: advantages of limbo
From: lucio@proxima.alt.za
In-Reply-To: <200403020658.i226w3An070941@adat.davidashen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Tue,  2 Mar 2004 09:50:05 +0200
Topicbox-Message-UUID: 0a62ae00-eacd-11e9-9e20-41e7f4b1d025

>> The Inferno/Java paper (somewhere on the web site, but likely also in
>> the Plan 9 distribution) covers it rather nicely.
> 
> Google brings inexistent link.
> 
Hm, maybe forsyth can help you with a copy, I'd have to search for one
myself.  If you want to wait, I must have one on the old Inferno CD.

> The only claim I have found is that reference counting + coloring
> is better than mark'n'sweep. Given that Java's GC is not mark'n'sweep
> for a long time already, and the performance problems related to
> memory management are insignificant since the release of HotSpot,
> are there any other advantages of limbo over Java?
> 
No, at that level of detail I'm really neither competent nor really
likely to be persuaded that computer languages can be meaningfully
compared.  When you start going that deep into the architecture, you
may as well resort to assembler.  At least, I would, largely because I
enjoy assmebler programming unless the host architecture is positively
foul.

> Besides, are there measured comparisons of Java and Limbo in the
> area of memory usage and GC performance? My experience with implementing
> GC in virtual machines is that reference-counting+graph coloring can
> easily result in slower execution than mark'n'sweep.
> 
Again, too detailed to be interesting, in my opinion.  Programming
languages are notations to express algorithms: the efficiency must lie
in the algorithms, not the translators (also, in my opinion).

++L