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 ;-)

(BTW, are you still working on Hydra much?  Waiting for Cog?)

Cheers,
Josh



>   
>>> Gulik.
>>>
>>> --
>>> http://gulik.pbwiki.com/
>>>
>>>       
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090506/5c09db87/attachment.htm