Hello.

Maybe "Heap of heaps" shoud be controlled by VM (god:)

2009/5/7 Igor Stasenko <siguctua at gmail.com>

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090507/1a43291e/attachment.htm