On Thu, Mar 5, 2009 at 5:40 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Thu, Mar 5, 2009 at 2:25 PM, Rodrigo Kumpera <[email protected]> wrote: > > > On Thu, Mar 5, 2009 at 3:58 PM, Jonathan S. Shapiro <[email protected]> > > 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 > other > > 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 side. At least for ordinary VM systems like the CLR or JVM. For pure functional languages 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 some static data. If both GC's require a stop-the-world phase, the number of STW will increase 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 > for > > 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 kindness, I'll 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 loading. 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.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
