GC question

GC question

[Vitaly Lugovsky]

 What shall I do, if I want to store a pointer to a caml value
in a structure outside the caml heap? Is there any GC hints for it?

--

   V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)

Re: GC question

[Xavier Leroy]

>  What shall I do, if I want to store a pointer to a caml value
> in a structure outside the caml heap? Is there any GC hints for it?

You need to tell the GC the address (outside the heap) where the Caml
value is stored, using register_global_root().  

When the external data structure is no longer relevant, or is about to
be freed, call remove_global_root() to tell the GC that the global
root is no longer there, thus allowing the GC to reclaim the
corresponding Caml data structure.

- Xavier Leroy

GC question.

[MATTHEW HAMMER]

Is there more documentation on the stuff in the Obj module?
What I see/know-about is here:

  http://caml.inria.fr/pub/docs/manual-ocaml/libref/Obj.html

I'm very interested in getting (write) access to GC-information on
ocaml values.

Thanks,
Matt

On Mon, Oct 24, 2005 at 05:51:54PM +0900, Keiko Nakata wrote:
> Hello.
> 
> Why I cannot have *any types* in signatures of functor arguments?
> Concretely, the following F is not typable.
> 
> module F(X:sig type t = [`A of _ ] val f : t -> int end) = 
>   struct
>     let f = function `A x as a -> X.f a | `B -> 0
>   end
> 
> The above F could be made typable as in
> 
> module F(X:sig type s type t = [`A of s ] val f : t -> int end) = 
>   struct
>     let f = function `A x as a -> X.f a | `B -> 0
>   end
> 
> However, this change requires me to add the type component s
> to every module to which F are going to be applied.
> This is not very nice...
> 
> Regards,
> Keiko Nakata
> 
> 
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

GC question

[dmitry grebeniuk]

Hello, caml-list.

  I have some objects (custom blocks with method suite attached)
which can be referenced from caml heap.  How to ensure that
finalisation function is called for all non-referenced objects?
I know, call to caml_gc_full_major(Val_unit) will do this work,
but it can be costly when there are many values on the heap
(or not?).  Are there any quicker solution?  (I can make no
assumptions about "age" (young/old) of allocated custom blocks
and about current GC state)

-- 
WBR,
 dmitry                          mailto:gds-mlsts@moldavcable.com

Re: Gc Question

[Damien Doligez]

>From: skaller <skaller@maxtal.com.au>

>How does (or should I say 'can') the garbage collector
>tell the difference between a pointer to a structured block,
>and a pointer to something else (outside the caml heap)?

Quite simply, a pointer to outside the heap points outside the heap...
Concretely, this is done by dividing the memory into 4k "pages" and
having a table of bytes to tell for each page whether it is in the
heap.


>unless
>the collector 'knows' where all structure blocks live
>and tests for that. [Conservative collectors often do just that]
>Is this the case??

In short, yes, although the collector doesn't know about each block
individually.


-- Damien

Gc Question

[skaller]

How does (or should I say 'can') the garbage collector
tell the difference between a pointer to a structured block,
and a pointer to something else (outside the caml heap)?

I knew that the low bit of a value was used to distinguish 
pointers from integers. I assumed that the bit was set (1) for pointers
to structured blocks (and had to be masked out before dereferencing),
and unset (0) for integers (requiring a right shift to extract the
integers).
This would allow word aligned arbitrary 'foreign' pointers to be used
without special handling (because they just look like ubboxed things
to the collector)

To my surprise, it works the other way. Clearly, this makes
dereferencing pointers more efficient, but it makes
it impossible to use foreign pointers as values -- unless
the collector 'knows' where all structure blocks live
and tests for that. [Conservative collectors often do just that]
Is this the case??

-----------------------------------
By the way, this:

#if SIZEOF_INT == 4
typedef int int32;
typedef unsigned int uint32;
#elif SIZEOF_LONG == 4
typedef long int32;
typedef unsigned long uint32;
#elif SIZEOF_SHORT == 4
typedef short int32;
typedef unsigned short uint32;
#endif

from mlvalues.h is a really bad idea.
The names int32, uint32, etc are commmonly
used by OTHER header files. It is, unfortunately,
better practice to use a name like:

	caml_int32

just to avoid a conflict. [For example, if some other
head file contains:

  #define int32 int

then the caml header will be equivalent to

  typedef int int;

which is invalid syntax]

[The same applies to the header file named 'config.h',
this name is common, and prevents moving the caml header
files into a directory shared by others: 'caml_config.h'
is a better name]


-- 
John Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850