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.

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


-- 
Best regards,
Igor Stasenko AKA sig.