Igor Stasenko wrote:
>>
>> 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? :)
>>
>>
>> Sure, why not?   "It's turtles all the way down", and to hell with the
>> finite hardware!
>>
>> Of course you don't need an infinite chain of images.  An image could
>> publish a list of services that it provides, one of them being
>> garbage-collection.  When an image requires garbage collection, it can send
>> a request to one of the images that publish that service.  Or more simply,
>> just have 2 GC images that take care of each other's needs (in a massively
>> multicore scenario, you'd want more than one image performing GCs anyway).
>>
>>     
>
> Consider we're talking about self-sustaining system. In this case, you
> have a number of heaps where one of them having permission to access
> other(s). But in this scenario you will need to have a 'heap of heaps'
> then, to rule them out. And who will control that 'heap of heaps'
> then? Chicken & egg problem :)
>   

I'm not sure what the problem is (I'm not sure what you mean by "rule
them out").  Anyway, nevermind... I put this forward as an idea before I
understood your thinking about how to avoid the problem of the GC
generating garbage.  At first, I thought you were proposing some fancy
GC where the garbage generated by the GC was handled in a special
manner, but it now appears that you would like to use special mirror
objects to avoid generating any garbage at all.

The implicit goal behind all of this is to make GC algorithms easier to
implement, to switch at runtime, etc., right?.  You outlined an approach
to using mirrors to avoid generating garbage during GC.  It's a nice
example, but I'm not sure that it scales up to the implementation of a
whole collector.  Do you think that you can define a set of such mirrors
that would allow people to flexibly create new GC schemes without going
through extreme contortions to avoid allocation?  I'm not saying that
you can't, but I'm wondering.

Cheers,
Josh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090507/38729dfa/attachment.htm