Hello.<br><br>Maybe "Heap of heaps" shoud be controlled by VM (god:)<br><br><div class="gmail_quote">2009/5/7 Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">2009/5/7 Joshua Gargus <<a href="mailto:schwa@fastmail.us">schwa@fastmail.us</a>>:<br>
> Igor Stasenko wrote:<br>
><br>
> 2009/5/7 Joshua Gargus <<a href="mailto:schwa@fastmail.us">schwa@fastmail.us</a>>:<br>
><br>
><br>
> Igor Stasenko wrote:<br>
><br>
> 2009/5/7 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
><br>
><br>
> On Tue, Apr 28, 2009 at 9:26 PM, Michael van der Gulik <<a href="mailto:mikevdg@gmail.com">mikevdg@gmail.com</a>><br>
> wrote:<br>
><br>
><br>
> On 4/29/09, Andreas Raab <<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>> wrote:<br>
><br>
><br>
> Eliot Miranda wrote:<br>
> Note that<br>
> you could even run GC only from the scheduler (i.e., treat GC as an<br>
> external signal that requests a GC from the scheduler) which solves the<br>
> concurrent GC problem even with the current VM design.<br>
><br>
><br>
> ...or even implement the GC in bytecodes. You could provide primitives<br>
> which gives lower level access to the image - raw memory maybe, or<br>
> perhaps objects indexed by oop.<br>
><br>
> It would be a bit tricky managing the garbage the GC itself would<br>
> generate. Maybe you could just leave it lying around, or maybe<br>
> deallocate it manually? And it would be a bit slow.<br>
><br>
><br>
> See Expert to Expert - Erik Meijer and Lars Bak: Inside V8. Lars Bak thinks<br>
> this is a bad idea, and I agree with him :)<br>
><br>
><br>
> Then make GC which can't generate the garbage. Or, in other words, it<br>
> should consume a predictable preallocated limited amount of memory to<br>
> do garbage collection. Since most of GC working in that way, i don't<br>
> see how a bytecode (or better to say - the 'in-language') GC<br>
> implementation could be different. Of course you need to allow a<br>
> direct memory access, and need to be careful with code/objects<br>
> relocations which is used by GC itself during running GC, and of<br>
> course it would be better to run it in native code - for speed reasons<br>
> :)<br>
> This is not something , which is impossible to do.<br>
><br>
><br>
> It would be easier to use Hydra instead of jumping though hoops to run the<br>
> GC code from the same object-memory that you're GCing. And, the effort put<br>
> into making Hydra support this would actually be useful, instead of doing<br>
> something extra-complicated just to show that you can ;-)<br>
><br>
><br>
><br>
> Heh, no this couldn't help. Who will sweep the garbage in object<br>
> memory which used to collect garbage in another object memory? 3rd<br>
> one? :)<br>
><br>
><br>
> Sure, why not? "It's turtles all the way down", and to hell with the<br>
> finite hardware!<br>
><br>
> Of course you don't need an infinite chain of images. An image could<br>
> publish a list of services that it provides, one of them being<br>
> garbage-collection. When an image requires garbage collection, it can send<br>
> a request to one of the images that publish that service. Or more simply,<br>
> just have 2 GC images that take care of each other's needs (in a massively<br>
> multicore scenario, you'd want more than one image performing GCs anyway).<br>
><br>
<br>
</div></div>Consider we're talking about self-sustaining system. In this case, you<br>
have a number of heaps where one of them having permission to access<br>
other(s). But in this scenario you will need to have a 'heap of heaps'<br>
then, to rule them out. And who will control that 'heap of heaps'<br>
then? Chicken & egg problem :)<br>
<div class="im"><br>
> I think that to make an 'in-language' GC possible, it should use an<br>
> object/classes mirrors, which providing methods required by GC in<br>
> functional style i.e.:<br>
> to visit all refs of a single oop, GC would call following method:<br>
> oop mirror iterateReferencesFor: oop iterationCallback: closure.<br>
> instead of:<br>
> oop allReferences do: [:each| GC mark: each ].<br>
><br>
><br>
> Pretty! The point, I gather, is that you would avoid generating garbage<br>
> during the iteration?<br>
><br>
</div>Yup.<br>
<div class="im"><br>
> i started prototyping these things in Moebius. Currently i'm using<br>
> them to bootstrap an object memory. I could instantiate such mirrors<br>
> in Squeak and then using them to fill the oops in newly created object<br>
> memory. It is possible because a functional/declarative code behavior<br>
> is invariant in any environment.<br>
><br>
><br>
><br>
> (BTW, are you still working on Hydra much? Waiting for Cog?)<br>
><br>
><br>
> I'd prefer help finishing Cog first, then we could get back to Hydra sooner<br>
> :)<br>
><br>
><br>
> :-) Hopefully Eliot's "Stack VM" will be released soon; it should be a good<br>
> point to merge the Hydra changes before "Cog" makes it out.<br>
><br>
> Mainly, what i don't like in Squeak VM building process is the<br>
> involvement of C compiler.<br>
> I keep advocating the idea that by having a native code generator, we<br>
> don't need the C compiler anymore.<br>
><br>
><br>
> That would be swell. Eliot met Slava Pestov at PyCon, and was quite<br>
> impressed by the code-generator in Factor<br>
> (<a href="http://www.mirandabanda.org/cogblog/2008/06/06/cog/#comment-4027" target="_blank">http://www.mirandabanda.org/cogblog/2008/06/06/cog/#comment-4027</a>).<br>
><br>
</div>thanks for pointer. i'll read about it now.<br>
<div class="im"><br>
> Cheers,<br>
> Josh<br>
><br>
><br>
><br>
> Cheers,<br>
> Josh<br>
><br>
><br>
><br>
><br>
><br>
> Gulik.<br>
><br>
> --<br>
> <a href="http://gulik.pbwiki.com/" target="_blank">http://gulik.pbwiki.com/</a><br>
><br>
<br>
<br>
<br>
</div><div><div></div><div class="h5">--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>