[squeak-dev] Re: Suspending process fix

Igor Stasenko siguctua at gmail.com
Thu May 7 19:50:53 UTC 2009


2009/5/7 Joshua Gargus <schwa at fastmail.us>:
> 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").
I mean you need to have a structure which controls the heaps. And
inevitably - if this structure is implemented in language itself, then
it needs own heap, and someone who can control this heap separately
(since your point is to not allow the object memory to control itself
directly i.e. memory allocation + GC).

> 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.
>
Yes. As i said - since GC's implemented in C generating no garbage,
then why we can't came up with GC, implemented in smalltalk which also
not generating any garbage during running.

> 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.

I don't know yet. What i'm sure about , is that memory managers such
as GC should always use a bounded memory space for own needs.
This even don't needs to be proved, otherwise , regardless the
language where you implementing it you may end up with situation that
GC consuming more memory for own needs than cleans out, and eventually
you run out of physicall memory space.
This is very likely, if you we will use a scheme where collector sits
in own image and collects garbage in another, while during collection
generating own garbage.

>
> Cheers,
> Josh
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list