[squeak-dev] Re: Suspending process fix
siguctua at gmail.com
Wed May 6 22:17:41 UTC 2009
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>
>> 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.
Igor Stasenko AKA sig.
More information about the Squeak-dev