On Thu, Mar 5, 2009 at 3:58 PM, Jonathan S. Shapiro <[email protected]>wrote:
> On Thu, Mar 5, 2009 at 12:56 PM, Rodrigo Kumpera <[email protected]> > 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 virtualization. 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 issues 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 performance for little gain as there will be more STW requests and more root set scanning. 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, imposes a huge set on engineering challenges. A more sane compromise, where the GC can 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.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
