[bitc-dev] Pools in lieu of GC
kumpera at gmail.com
Thu Mar 5 17:22:26 EST 2009
On Thu, Mar 5, 2009 at 5:40 PM, Jonathan S. Shapiro <shap at eros-os.com>wrote:
> On Thu, Mar 5, 2009 at 2:25 PM, Rodrigo Kumpera <kumpera at gmail.com> wrote:
> > On Thu, Mar 5, 2009 at 3:58 PM, Jonathan S. Shapiro <shap at eros-os.com>
> > wrote:
> > A VM to
> > be performant, and correct, it must do everything as lazily as possible.
> Not entirely correct.
Well, not everything, but for a large class of problems, lazy construction
of metadata is a requirement. For example, to proper support CLR generics,
which is based on System F, recursive types must be lazily initialized.
> > This means
> > allocating memory in very small units from a few pools.
> > Dynamic code loading and generation by the target environment imposes
> > issues as well.
> Not that I can see, and I know how to do both of these very efficiently.
> If this is done right, the only thing that really ought to be growing
> at run time is the managed pool itself.
There is no way to avoid using an unbound ammount of memory from the VM
At least for ordinary VM systems like the CLR or JVM. For pure functional
it might be doable OTOH.
> >> 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
> > performance
> > for little gain as there will be more STW requests and more root set
> > scanning.
> This sounds like complete nonsense. The GC for the VM implementation
> has no business whatsoever scanning the heaps of applications, and the
> VM layer if properly implemented will have only tens of objects that
> are potentially collectible.
I wasn't talking heaps, but the root set. Both GCs have to scan stacks and
data. If both GC's require a stop-the-world phase, the number of STW will
and they are pretty expensive with a large number of threads.
> > My issue with having separated GC's is due to the fact that it's common
> > a VM to directly
> > manipulate a managed object by the means of having a structural mirror
> > defined.
> What you are describing is a fundamentally unsafe and unnecessary
> approach. It is an explicit goal of BitC to strongly discourage
> unnecessarily unsafe approaches, so I'm very glad to hear that they
> seem to be terribly difficult.
It is unsafe, as a lot of stuff a virtual machine does, and that's the main
reason why I believe even a less safe version of BitC should improve
reliability and maintainability of such class of applications.
> I'll be happy to start a side discussion about VM construction,
> however, because I do agree that the existence of a more sensible but
> performant construction strategy seems like an important thing to
> establish. I'm confident that one exists, because we have accomplished
> it in HDTrans and (at a different level of abstraction) in KeyKOS,
> EROS, CapROS, and Coyotos.
I would love to hear your opinions on that. But before I abuse of your
properly study HDTRans.
> >> 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.
> The problem is that a sensible GC implementation shouldn't require
> those objects in the first place.
I haven't seen any research result that suggests that it's possible to
accomplish such thing
for type systems that require objects tags to be sound.
Tagless collectors have been built to dialets of ML, but none worked in face
of dynamic type
Anyway, collectors for imperative systems do require information on stack
frames and object layout.
Maybe I should have told you before that my target are VMs for imperative
systems, such as the CLR.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev