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? :)

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 ].

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 :)
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.

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

-- 
Best regards,
Igor Stasenko AKA sig.