<br><br><div class="gmail_quote">On Thu, Mar 5, 2009 at 5:40 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 2:25 PM, Rodrigo Kumpera <<a href="mailto:kumpera@gmail.com">kumpera@gmail.com</a>> wrote:<br>
<br></div>> On Thu, Mar 5, 2009 at 3:58 PM, Jonathan S. Shapiro <<a href="mailto:shap@eros-os.com">shap@eros-os.com</a>><br><div class="im">
> wrote:<br>
</div></blockquote><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>
> A VM to<br>
> be performant, and correct, it must do everything as lazily as possible.<br>
<br>
</div>Not entirely correct.<br>
<div class="im"></div></blockquote><div><br>Well, not everything, but for a large class of problems, lazy construction<br>of metadata is a requirement. For example, to proper support CLR generics,<br>which is based on System F, recursive types must be lazily initialized.<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>
> 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<br>
> issues as well.<br>
<br>
</div>Not that I can see, and I know how to do both of these very efficiently.<br>
<br>
If this is done right, the only thing that really ought to be growing<br>
at run time is the managed pool itself.<br>
<div class="im"></div></blockquote><div><br>There is no way to avoid using an unbound ammount of memory from the VM side.<br>At least for ordinary VM systems like the CLR or JVM. For pure functional languages <br>it might be doable OTOH.<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>
>> 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>
><br>
> Actually, it shouldn't. Having multiple separated GC's will only hurt<br>
> performance<br>
> for little gain as there will be more STW requests and more root set<br>
> scanning.<br>
<br>
</div>This sounds like complete nonsense. The GC for the VM implementation<br>
has no business whatsoever scanning the heaps of applications, and the<br>
VM layer if properly implemented will have only tens of objects that<br>
are potentially collectible.<br>
<div class="im"></div></blockquote><div><br>I wasn't talking heaps, but the root set. Both GCs have to scan stacks and some static<br>data. If both GC's require a stop-the-world phase, the number of STW will increase<br>
and they are pretty expensive with a large number of threads.<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>
> My issue with having separated GC's is due to the fact that it's common for<br>
> a VM to directly<br>
> manipulate a managed object by the means of having a structural mirror<br>
> defined.<br>
<br>
</div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What you are describing is a fundamentally unsafe and unnecessary<br>
approach. It is an explicit goal of BitC to strongly discourage<br>
unnecessarily unsafe approaches, so I'm very glad to hear that they<br>
seem to be terribly difficult.<br>
</blockquote><div><br>It is unsafe, as a lot of stuff a virtual machine does, and that's the main<br>reason why I believe even a less safe version of BitC should improve<br>reliability and maintainability of such class of applications.<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;"><br>
I'll be happy to start a side discussion about VM construction,<br>
however, because I do agree that the existence of a more sensible but<br>
performant construction strategy seems like an important thing to<br>
establish. I'm confident that one exists, because we have accomplished<br>
it in HDTrans and (at a different level of abstraction) in KeyKOS,<br>
EROS, CapROS, and Coyotos.<br>
<div class="im"></div></blockquote><div><br>I would love to hear your opinions on that. But before I abuse of your kindness, I'll<br>properly study HDTRans.<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>
>> What objects are used by the GC itself? That shouldn't happen. Is this<br>
>> the metacircular problem again?<br>
><br>
> This is a problem if you have a single GC for the whole thing. If the<br>
> collector is written in a language<br>
> which memory is managed by it. Moving the objects required to perform the<br>
> collection itself (type maps, scan stacks, etc)<br>
> is something no implementation I know tries to do.<br>
<br>
</div>The problem is that a sensible GC implementation shouldn't require<br>
those objects in the first place.<br>
<div class="im"></div></blockquote><div><br>I haven't seen any research result that suggests that it's possible to accomplish such thing<br>for type systems that require objects tags to be sound.<br>Tagless collectors have been built to dialets of ML, but none worked in face of dynamic type<br>
loading.<br><br>Anyway, collectors for imperative systems do require information on stack frames and object layout.<br></div><div><br>Maybe I should have told you before that my target are VMs for imperative systems, such as the CLR.<br>
<br><br></div></div>