GC question.

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

Re: [Caml-list] GC question.

[Damien Doligez]

On Oct 24, 2005, at 19:53, MATTHEW HAMMER wrote:

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

What kind of GC information do you want to modify?

-- Damien

Re: [Caml-list] GC question.

[MATTHEW HAMMER]

I'm not certain what style of garbage collection is done in the ocaml
runtime environment, but if its generational for example, I'd like to
move certain values into the 'oldest' generation, so that the garbage
collector doesn't waste time on them.

The running program in question has a large datastructure that is very
persistent which takes a lot of GC time if it is transversed too
often.

So I suppose what I'm asking is: is there a way to give the GC'er
'hints' through the Obj module, or any other method?

Thanks,
Matt

On Tue, Oct 25, 2005 at 08:41:34PM +0200, Damien Doligez wrote:
> 
> On Oct 24, 2005, at 19:53, MATTHEW HAMMER wrote:
> 
> >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.
> 
> What kind of GC information do you want to modify?
> 
> -- Damien
> 
> _______________________________________________
> 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

Re: [Caml-list] GC question.

[Damien Doligez]

On Oct 25, 2005, at 21:20, MATTHEW HAMMER wrote:

> I'm not certain what style of garbage collection is done in the ocaml
> runtime environment,

Generational with two generations, and incremental for the old
generation.

> but if its generational for example, I'd like to
> move certain values into the 'oldest' generation, so that the garbage
> collector doesn't waste time on them.

The only way to do that is to call Gc.minor, but it won't save any time.

> The running program in question has a large datastructure that is very
> persistent which takes a lot of GC time if it is transversed too
> often.

If it's large, it's going to be in the major heap anyway.  If you
don't want the GC to traverse it, you'll have to put it outside the
heap, but it might will require a lot of work.  For example, bigarrays
are outside the heap.  Or you could write some C code to build your
structure out of malloc blocks, but I'd count that as a desperate
measure.

> So I suppose what I'm asking is: is there a way to give the GC'er
> 'hints' through the Obj module, or any other method?

You can control some parameters with the Gc module, but there's
no way to give hints about a specific piece of data.

-- Damien

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

[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

[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

[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