On Thu, Mar 5, 2009 at 2:25 PM, Rodrigo Kumpera <[email protected]> wrote:
> I mean't a VM in the sense of a managed execution enviroment, not in as in > virtualization. Okay. Thanks for clarifying. > On Thu, Mar 5, 2009 at 3:58 PM, Jonathan S. Shapiro <[email protected]> > wrote: >> 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. > By that statement all current VMs are completely full on non-sense. You should not dismiss this likelihood out of hand. > A VM to > be performant, and correct, it must do everything as lazily as possible. Not entirely correct. > 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. >> 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. > 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. Dear God. No wonder most VMs don't work. 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. 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. >> 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 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. Since switching the GC often involves changing compilation strategies, I doubt that it will ever be fully pluggable. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
