caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* GC question
@ 2005-07-05  7:59 dmitry grebeniuk
  2005-07-06  7:29 ` [Caml-list] " Jean-Christophe Filliatre
  0 siblings, 1 reply; 7+ messages in thread
From: dmitry grebeniuk @ 2005-07-05  7:59 UTC (permalink / raw)
  To: caml-list

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Caml-list] GC question
  2005-07-05  7:59 GC question dmitry grebeniuk
@ 2005-07-06  7:29 ` Jean-Christophe Filliatre
  0 siblings, 0 replies; 7+ messages in thread
From: Jean-Christophe Filliatre @ 2005-07-06  7:29 UTC (permalink / raw)
  To: dmitry grebeniuk; +Cc: caml-list


dmitry grebeniuk writes:
 > 
 >   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)

The two integer parameters "used" and "max" passed to alloc_custom are
controlling how fast the custom blocks are reclaimed by the GC, as
explained in section 18.9.2 of the manual
(see http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html).

I don't think that calling caml_gc_full_major by yourself is a good
idea. You should trust the GC; it will eventually reclaim any block
that is not referenced anymore.

Hope this helps,
-- 
Jean-Christophe


^ permalink raw reply	[flat|nested] 7+ messages in thread

* GC question.
@ 2005-10-24 17:53 MATTHEW HAMMER
  0 siblings, 0 replies; 7+ messages in thread
From: MATTHEW HAMMER @ 2005-10-24 17:53 UTC (permalink / raw)
  To: caml-list

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: GC question
  2001-01-13  2:16 Vitaly Lugovsky
@ 2001-01-23  8:29 ` Xavier Leroy
  0 siblings, 0 replies; 7+ messages in thread
From: Xavier Leroy @ 2001-01-23  8:29 UTC (permalink / raw)
  To: Vitaly Lugovsky; +Cc: caml-list

>  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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* GC question
@ 2001-01-13  2:16 Vitaly Lugovsky
  2001-01-23  8:29 ` Xavier Leroy
  0 siblings, 1 reply; 7+ messages in thread
From: Vitaly Lugovsky @ 2001-01-13  2:16 UTC (permalink / raw)
  To: caml-list


 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)




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re:  Gc Question
@ 1999-12-23 16:54 Damien Doligez
  0 siblings, 0 replies; 7+ messages in thread
From: Damien Doligez @ 1999-12-23 16:54 UTC (permalink / raw)
  To: caml-list

>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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Gc Question
@ 1999-12-12 23:59 skaller
  0 siblings, 0 replies; 7+ messages in thread
From: skaller @ 1999-12-12 23:59 UTC (permalink / raw)
  To: caml-list

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-10-24 17:53 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-07-05  7:59 GC question dmitry grebeniuk
2005-07-06  7:29 ` [Caml-list] " Jean-Christophe Filliatre
  -- strict thread matches above, loose matches on Subject: below --
2005-10-24 17:53 MATTHEW HAMMER
2001-01-13  2:16 Vitaly Lugovsky
2001-01-23  8:29 ` Xavier Leroy
1999-12-23 16:54 Gc Question Damien Doligez
1999-12-12 23:59 skaller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).