[Caml-list] Stopping a value from getting GC'd

[Caml-list] Stopping a value from getting GC'd

[Jonathan Roewen]

Hi,

I have the following in my C code:

struct caml_thread_struct {
	char * bottom_of_stack;
	unsigned long last_retaddr;
	value * gc_regs;
	char * exception_pointer;
	struct caml__roots_block * local_roots;
	int is_running;
	value closure;
};

typedef struct caml_thread_struct * caml_thread_t;

static value Val_thread(caml_thread_t thread) {
	CAMLparam0();
	CAMLlocal1(rv);
	rv = caml_alloc(1, Abstract_tag);
	Field(rv,0) = (value) thread;
	CAMLreturn(rv);
}

#define Thread_val(rv) ((caml_thread_t)Field((rv),0))

Now my question is, since my Thread.t is abstract, once I pass my
value to my Thread.create, there'll soon be nothing referencing the
closure for the thread that's visible by the GC.

If I'm correct, the GC would then be allowed to reclaim this closure.
So how do I stop the GC from doing that?

Jonathan

Re: Stopping a value from getting GC'd

[Bardur Arantsson]

Jonathan Roewen wrote:
> Hi,
> 
> I have the following in my C code:
> 
> struct caml_thread_struct {
> 	char * bottom_of_stack;
> 	unsigned long last_retaddr;
> 	value * gc_regs;
> 	char * exception_pointer;
> 	struct caml__roots_block * local_roots;
> 	int is_running;
> 	value closure;
> };
> 
> typedef struct caml_thread_struct * caml_thread_t;
> 
> static value Val_thread(caml_thread_t thread) {
> 	CAMLparam0();
> 	CAMLlocal1(rv);
> 	rv = caml_alloc(1, Abstract_tag);
> 	Field(rv,0) = (value) thread;
> 	CAMLreturn(rv);
> }
> 
> #define Thread_val(rv) ((caml_thread_t)Field((rv),0))
> 
> Now my question is, since my Thread.t is abstract, once I pass my
> value to my Thread.create, there'll soon be nothing referencing the
> closure for the thread that's visible by the GC.
> 
> If I'm correct, the GC would then be allowed to reclaim this closure.
> So how do I stop the GC from doing that?
> 

register_global_root (or as some others would say: RTFM).

-- 
Bardur Arantsson
<bardur@imada.sdu.dk>
<bardur@scientician.net>

- Oh, did I say corpse hatch? I meant... innocence tube.
                                  Montgomery Burns, 'The Simpsons'

Cost of register_global_root (was: Stopping a value from getting GC'd)

[Nathaniel Gray]

On 8/16/05, Bardur Arantsson <spam@scientician.net> wrote:
> Jonathan Roewen wrote:
> >
> > Now my question is, since my Thread.t is abstract, once I pass my
> > value to my Thread.create, there'll soon be nothing referencing the
> > closure for the thread that's visible by the GC.
> >
> > If I'm correct, the GC would then be allowed to reclaim this closure.
> > So how do I stop the GC from doing that?
> >
> 
> register_global_root (or as some others would say: RTFM).

One thing that the FM doesn't mention is how expensive it is to
register a global root.  Can I register thousands of them or will
there be performance problems?

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

Re: [Caml-list] Cost of register_global_root

[Alain Frisch]

Nathaniel Gray wrote:
> One thing that the FM doesn't mention is how expensive it is to
> register a global root.  Can I register thousands of them or will
> there be performance problems?

The runtime system stores the global roots in a skip list. One should
expect probabilistic O(log n) complexity with a small constant for each
insertion and deletion, where n is the number of already registered
global roots.

Another option is to manage the roots yourself (e.g. you put them in an
array and store indexes into this array in your custom data structure).
This might be necessary if the custom blocks are under the control of
another memory management system which can moves blocks around.

-- Alain

Re: [Caml-list] Cost of register_global_root

[Nathaniel Gray]

On 8/17/05, Alain Frisch <Alain.Frisch@inria.fr> wrote:
> Nathaniel Gray wrote:
> > One thing that the FM doesn't mention is how expensive it is to
> > register a global root.  Can I register thousands of them or will
> > there be performance problems?
> 
> The runtime system stores the global roots in a skip list. One should
> expect probabilistic O(log n) complexity with a small constant for each
> insertion and deletion, where n is the number of already registered
> global roots.

Sounds reasonable.

> Another option is to manage the roots yourself (e.g. you put them in an
> array and store indexes into this array in your custom data structure).

That's exactly what I was planning, but I wasn't entirely sure it was
actually necessary.

> This might be necessary if the custom blocks are under the control of
> another memory management system which can moves blocks around.

Thanks,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

Re: [Caml-list] Cost of register_global_root (was: Stopping a value from getting GC'd)

[Markus Mottl]

On 8/17/05, Nathaniel Gray <n8gray@gmail.com> wrote:
> One thing that the FM doesn't mention is how expensive it is to
> register a global root.  Can I register thousands of them or will
> there be performance problems?

There is a severe performance penalty for registering many thousands
of roots as I have seen in one of our applications.  AFAIK, they are
scanned at each minor collection.  This will drive up CPU-usage even
if your program doesn't do much otherwise.  Maybe the GC could be
improved in that area.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com

Re: [Caml-list] Cost of register_global_root (was: Stopping a value from getting GC'd)

[skaller]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Wed, 2005-08-17 at 23:57 -0400, Markus Mottl wrote:
> On 8/17/05, Nathaniel Gray <n8gray@gmail.com> wrote:
> > One thing that the FM doesn't mention is how expensive it is to
> > register a global root.  Can I register thousands of them or will
> > there be performance problems?
> 
> There is a severe performance penalty for registering many thousands
> of roots as I have seen in one of our applications.  AFAIK, they are
> scanned at each minor collection.  This will drive up CPU-usage even
> if your program doesn't do much otherwise.  Maybe the GC could be
> improved in that area.

Why not just put the pointers into a (reachable) hashtable?

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Cost of register_global_root (was: Stopping a value from getting GC'd)

[Richard Jones]

On Wed, Aug 17, 2005 at 06:31:13PM -0700, Nathaniel Gray wrote:
> One thing that the FM doesn't mention is how expensive it is to
> register a global root.  Can I register thousands of them or will
> there be performance problems?

Yes, there is a performance problem.

A Gtk program we wrote used (IIRC) GtkListView, which caused 1000s of
roots to be registered.  The program slowed down appreciably.

http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk-list/1062

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com