2009/5/7 Joshua Gargus <schwa at fastmail.us>:
> Igor Stasenko wrote:
>
> 2009/5/7 Joshua Gargus <schwa at fastmail.us>:
>
>
> Igor Stasenko wrote:
>
> 2009/5/7 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Tue, Apr 28, 2009 at 9:26 PM, Michael van der Gulik <mikevdg at gmail.com>
> wrote:
>
>
> On 4/29/09, Andreas Raab <andreas.raab at gmx.de> wrote:
>
>
> Eliot Miranda wrote:
> Note that
> you could even run GC only from the scheduler (i.e., treat GC as an
> external signal that requests a GC from the scheduler) which solves the
> concurrent GC problem even with the current VM design.
>
>
> ...or even implement the GC in bytecodes. You could provide primitives
> which gives lower level access to the image - raw memory maybe, or
> perhaps objects indexed by oop.
>
> It would be a bit tricky managing the garbage the GC itself would
> generate. Maybe you could just leave it lying around, or maybe
> deallocate it manually? And it would be a bit slow.
>
>
> See Expert to Expert - Erik Meijer and Lars Bak: Inside V8.  Lars Bak thinks
> this is a bad idea, and I agree with him :)
>
>
> Then make GC which can't generate the garbage. Or, in other words, it
> should consume a predictable preallocated limited amount of memory to
> do garbage collection. Since most of GC working in that way, i don't
> see how a bytecode (or better to say - the 'in-language') GC
> implementation could be different. Of course you need to allow a
> direct memory access, and need to be careful with code/objects
> relocations which is used by GC itself during running GC, and of
> course it would be better to run it in native code - for speed reasons
> :)
> This is not something , which is impossible to do.
>
>
> It would be easier to use Hydra instead of jumping though hoops to run the
> GC code from the same object-memory that you're GCing.  And, the effort put
> into making Hydra support this would actually be useful, instead of doing
> something extra-complicated just to show that you can ;-)
>
>
>
> Heh, no this couldn't help. Who will sweep the garbage in object
> memory which used to collect garbage in another object memory? 3rd
> one? :)
>
>
> Sure, why not?   "It's turtles all the way down", and to hell with the
> finite hardware!
>
> Of course you don't need an infinite chain of images.  An image could
> publish a list of services that it provides, one of them being
> garbage-collection.  When an image requires garbage collection, it can send
> a request to one of the images that publish that service.  Or more simply,
> just have 2 GC images that take care of each other's needs (in a massively
> multicore scenario, you'd want more than one image performing GCs anyway).
>

Consider we're talking about self-sustaining system. In this case, you
have a number of heaps where one of them having permission to access
other(s). But in this scenario you will need to have a 'heap of heaps'
then, to rule them out. And who will control that 'heap of heaps'
then? Chicken & egg problem :)

> I think that to make an 'in-language' GC possible, it should use an
> object/classes mirrors, which providing methods required by GC in
> functional style i.e.:
> to visit all refs of a single oop, GC would call following method:
> oop mirror iterateReferencesFor: oop iterationCallback: closure.
> instead of:
> oop allReferences do: [:each| GC mark: each ].
>
>
> Pretty!  The point, I gather, is that you would avoid generating garbage
> during the iteration?
>
Yup.

> i started prototyping these things in Moebius. Currently i'm using
> them to bootstrap an object memory. I could instantiate such mirrors
> in Squeak and then using them to fill the oops in newly created object
> memory. It is possible because a functional/declarative code behavior
> is invariant in any environment.
>
>
>
> (BTW, are you still working on Hydra much?  Waiting for Cog?)
>
>
> I'd prefer help finishing Cog first, then we could get back to Hydra sooner
> :)
>
>
> :-)  Hopefully Eliot's "Stack VM" will be released soon; it should be a good
> point to merge the Hydra changes before "Cog" makes it out.
>
> Mainly, what i don't like in Squeak VM building process is the
> involvement of C compiler.
> I keep advocating the idea that by having a native code generator, we
> don't need the C compiler anymore.
>
>
> That would be swell.  Eliot met Slava Pestov at PyCon, and was quite
> impressed by the code-generator in Factor
> (http://www.mirandabanda.org/cogblog/2008/06/06/cog/#comment-4027).
>
thanks for pointer. i'll read about it now.

> Cheers,
> Josh
>
>
>
> Cheers,
> Josh
>
>
>
>
>
> Gulik.
>
> --
> http://gulik.pbwiki.com/
>



-- 
Best regards,
Igor Stasenko AKA sig.