[bitc-dev] Pools in lieu of GC

Rodrigo Kumpera kumpera at gmail.com
Thu Mar 5 14:25:48 EST 2009

On Thu, Mar 5, 2009 at 3:58 PM, Jonathan S. Shapiro <shap at eros-os.com>wrote:

> On Thu, Mar 5, 2009 at 12:56 PM, Rodrigo Kumpera <kumpera at gmail.com>
> wrote:
> > I'm, for one, am thinking about using BitC to write virtual machines.
>  If you mean "virtual machine" in the sense of a JVM, you will find in
> practice that a sensibly written virtual machine observes the
> above-stated rule. While it does allocate in certain situations, every
> allocation after startup will end up in the application heap. At most,
> you will end up in a situation where you are managing a small number
> of very large blocks.

I mean't a VM in the sense of a managed execution enviroment, not in as in

By that statement all current VMs are completely full on non-sense. A VM to
be performant, and correct, it must do everything as lazily as possible.
This means
allocating memory in very small units from a few pools.
Dynamic code loading and generation by the target environment imposes other
as well.

But, in the end, it's sensible to expect that for programs that reach a
steady state,
all allocations can be drawn from the the managed pool.

> > On this case, using just a GC is pretty complex, as it would require a
> > meta-circular design...
> I'm not clear why you think this should be true. Can you explain? GC
> at the level of the VM should be completely separated from GC at the
> level of the bytecode application.

Actually, it shouldn't. Having multiple separated GC's will only hurt
for little gain as there will be more STW requests and more root set
This is, of course, if you assume a traditional collector design of
non-specific spaces.

My issue with having separated GC's is due to the fact that it's common for
a VM to directly
manipulate a managed object by the means of having a structural mirror
defined. IOW, with C
we define a struct that mirror the managed layout of a given object and use
that explicitly in
VM internal calls.
It would require an alien memory annotation to let one GC (the one managing
BitC memory) knows
that such memory belongs to the other.

> > At the same time, there is no reason for a GC written in BitC to require
> the
> > use of big chunks
> > of unsafe code just because it has to deal with low level memory
> management
> > - as, obviously,
> > it can't use another GC for this job.
> Correct. And I can see no reason why GC cannot be written in BitC
> today. The part where I think you are getting hung up lies in assuming
> that the design must be metacircular. I agree that is hard.

A metacircular design has some very nice properties, but at the same time,
a huge set on engineering challenges. A more sane compromise, where the GC
precisely scan VM frames is more than enough to me.

> > There are some issues with been GC only for memory allocation. Generating
> > code that is good for precise GC is tricky, either you make a performance
> compromise or you
> > generate huge stack maps;
> > object placement is another issue, as some objects used by the GC itself
> > can't be moved.
> What objects are used by the GC itself? That shouldn't happen. Is this
> the metacircular problem again?

This is a problem if you have a single GC for the whole thing. If the
collector is written in a language
which memory is managed by it. Moving the objects required to perform the
collection itself (type maps, scan stacks, etc)
is something no implementation I know tries to do.

> > On the
> > end of the day, a VM will have to replace the BitC runtime provided
> > collector with one that bends well
> > with the target runtime.
> It will almost certainly have to replace the GC subsystem, but not to
> mesh it with the target runtime.
> I do not assume that there will ever exist a "one size fits all"
> implementation of GC, and I DO assume that applications which take on
> the characteristics of runtime systems will tend to need specialized
> GC systems.
This is a complex problem on itself, allowing to make such thing pluggable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20090305/4059fae2/attachment-0001.html 

More information about the bitc-dev mailing list