<br><br><div class="gmail_quote">On Thu, Mar 5, 2009 at 3:58 PM, Jonathan S. Shapiro <span dir="ltr"><<a href="mailto:shap@eros-os.com">shap@eros-os.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, Mar 5, 2009 at 12:56 PM, Rodrigo Kumpera <<a href="mailto:kumpera@gmail.com">kumpera@gmail.com</a>> wrote:<br>
> I'm, for one, am thinking about using BitC to write virtual machines.<br>
<br>
</div>
If you mean "virtual machine" in the sense of a JVM, you will find in<br>
practice that a sensibly written virtual machine observes the<br>
above-stated rule. While it does allocate in certain situations, every<br>
allocation after startup will end up in the application heap. At most,<br>
you will end up in a situation where you are managing a small number<br>
of very large blocks.<br>
<div class="im"></div></blockquote><div><br>I mean't a VM in the sense of a managed execution enviroment, not in as in virtualization.<br><br>By that statement all current VMs are completely full on non-sense. A VM to<br>
be performant, and correct, it must do everything as lazily as possible. This means<br>allocating memory in very small units from a few pools.<br>Dynamic code loading and generation by the target environment imposes other issues<br>
as well.<br><br>But, in the end, it's sensible to expect that for programs that reach a steady state,<br>all allocations can be drawn from the the managed pool.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> On this case, using just a GC is pretty complex, as it would require a<br>
</div>> meta-circular design...<br>
<br>
I'm not clear why you think this should be true. Can you explain? GC<br>
at the level of the VM should be completely separated from GC at the<br>
level of the bytecode application.<br>
<div class="im"></div></blockquote><div><br>Actually, it shouldn't. Having multiple separated GC's will only hurt performance<br>for little gain as there will be more STW requests and more root set scanning. <br>
This is, of course, if you assume a traditional collector design of non-specific spaces.<br><br>My issue with having separated GC's is due to the fact that it's common for a VM to directly<br>manipulate a managed object by the means of having a structural mirror defined. IOW, with C<br>
we define a struct that mirror the managed layout of a given object and use that explicitly in<br>VM internal calls.<br>It would require an alien memory annotation to let one GC (the one managing BitC memory) knows<br>that such memory belongs to the other.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> At the same time, there is no reason for a GC written in BitC to require the<br>
> use of big chunks<br>
> of unsafe code just because it has to deal with low level memory management<br>
> - as, obviously,<br>
> it can't use another GC for this job.<br>
<br>
</div>Correct. And I can see no reason why GC cannot be written in BitC<br>
today. The part where I think you are getting hung up lies in assuming<br>
that the design must be metacircular. I agree that is hard.<br>
<div class="im"></div></blockquote><div><br>A metacircular design has some very nice properties, but at the same time, imposes<br>a huge set on engineering challenges. A more sane compromise, where the GC can<br>precisely scan VM frames is more than enough to me. <br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> There are some issues with been GC only for memory allocation. Generating<br>
> code that is good for precise GC is tricky, either you make a performance compromise or you<br>
> generate huge stack maps;<br>
> object placement is another issue, as some objects used by the GC itself<br>
> can't be moved.<br>
<br>
</div>What objects are used by the GC itself? That shouldn't happen. Is this<br>
the metacircular problem again?<br>
<div class="im"></div></blockquote><div><br>This is a problem if you have a single GC for the whole thing. If the collector is written in a language<br>which memory is managed by it. Moving the objects required to perform the collection itself (type maps, scan stacks, etc)<br>
is something no implementation I know tries to do.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> On the<br>
> end of the day, a VM will have to replace the BitC runtime provided<br>
> collector with one that bends well<br>
> with the target runtime.<br>
<br>
</div>It will almost certainly have to replace the GC subsystem, but not to<br>
mesh it with the target runtime.<br>
<br>
I do not assume that there will ever exist a "one size fits all"<br>
implementation of GC, and I DO assume that applications which take on<br>
the characteristics of runtime systems will tend to need specialized<br>
GC systems.<br>
<div><div></div><div class="h5"><br></div></div></blockquote></div><br>This is a complex problem on itself, allowing to make such thing pluggable.<br><br>