<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Igor Stasenko wrote:<br>
<blockquote
cite="mid:4a5f5f320905061900i38ea42bfo7ac08556b665d8c@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">
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).
</pre>
</blockquote>
<pre wrap=""><!---->
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 :)
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Josh<br>
<br>
</body>
</html>