Re: Announcement: micro-libgcj

[Mike Emmel <mike dot emmel at gmail dot com>]

On 1/6/06, Boehm, Hans <hans.boehm@hp.com> wrote:
> > 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.
> > ...

For Zone allocation  you could keep the class pointers at the top of
the zone thus zone allocated object become simple C structures.
If you looked up the class for a instance based on hashing then the beginings
of the zone address could be chosen to either collide or you could
detect a zone allocated object.  Zone or typed allocation thus opens
up the door to remove the redundant class pointer from each object
instance.


Mike

> > 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
>