On Thu, Mar 5, 2009 at 5:22 PM, Rodrigo Kumpera <[email protected]> wrote: > 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.
I'm not convinced that this needs to live (or ought to live) in the VM heap, except as a matter of caching. > 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 think our disconnect has to do with which things go in VM memory and which things go in guest memory. >> 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. The GC for the VM implementation should never be scanning guest stacks, and vice versa. >> 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. HDTrans is only a partial predictor, because the metadata issue doesn't really arise. The key point is that the core VM *caches* metadata, but the definitive metadata does not live in core VM memory. >> > 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. Umm. Have you heard of copying collectors? We have a major disconnect here, because what I'm thinking about is very straightforward. > Tagless collectors have been built to dialets of ML, but none worked in face > of dynamic type > loading. Dynamic types are largely irrelevant here, because GC doesn't work at the level of language objects. The type system at the GC level is much thinned. > Anyway, collectors for imperative systems do require information on stack > frames and object layout. Yes, but this is not stored in the heap of the interpreter. > Maybe I should have told you before that my target are VMs for imperative > systems, such as the CLR. Doesn't make a difference. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
