[squeak-dev] Re: Suspending process fix

Igor Stasenko siguctua at gmail.com
Thu May 7 22:56:44 UTC 2009


2009/5/8 Michael van der Gulik <mikevdg at gmail.com>:
> On 5/7/09, Igor Stasenko <siguctua at gmail.com> 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? :)
>
> Just delete the special GC image when it's finished and make a new one
> when you want to run another GC.
>
ouch :)  I'd prefer more efficient ways.

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



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list