Announcement: micro-libgcj

[Boehm, Hans]

> From: Mike Emmel [mailto:mike.emmel@gmail.com] 

> Yes I agree thats why at the end of the day I think for 
> embedded use a semi-safe javaish language that brings back 
> stack/zone allocation and programmer controlled memory 
> management is really needed.  Despite the work that has gone 
> into garbage collection no one has really proved that they 
> can replace other allocation methods. On the same hand having 
> a good gc when needed or wanted is a good thing.
I think that for stack allocation, there's generally a performance
advantage.  For zone allocation, there may well be, though it depends on
whether you need to keep additional objects around to make it work.  For
explicit deallocation of smallish objects, in a multithreaded
environment, I'll buy the argument if you are trying to optimize average
case space consumption.  I think a GC is typically faster.  And a
compacting GC will give you far better worst-case space bounds.  And for
pause times, it depends very much on how you measure things.
> ...
> But if you accept the concept of desiging a language family 
> then the need to make draconian design decisions in a 
> particular language are removed.  Instead your more concerned 
> with partitioning concept between the languages in the family 
> based on safety syntax etc etc.
> 
Yes.  But I expect the different participants on this list have somewhat
diverging goals.

Hans