caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Re: Finalisation in 2.02
@ 1999-12-23 17:06 Damien Doligez
  0 siblings, 0 replies; 5+ messages in thread
From: Damien Doligez @ 1999-12-23 17:06 UTC (permalink / raw)
  To: caml-list

>From: Patrick Goldbronn - SYSCO <patrick.goldbronn@cea.fr>
>
>What's append when we change the finalization parameters values ?
>We alloc an object of type toto with 1,200 and another object toto with
>9,146
>
>It's the last number which is keep by GC (here 146) and erase previous
>value (200)
>The same with the pound (1 and 9) or they are adding -> 1+9 = 10 < 146 ?

Each pair of numbers is actually a rational number and they are added
together to tell the GC how advanced it should be into its cycle.

In your example, you get 1/200 + 9/146 = 973/14600, or about 6.6 %

-- Damien




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

* Re: Finalisation in 2.02
  1999-12-13  9:35 ` Jacques Garrigue
@ 1999-12-15  8:41   ` Patrick Goldbronn - SYSCO
  0 siblings, 0 replies; 5+ messages in thread
From: Patrick Goldbronn - SYSCO @ 1999-12-15  8:41 UTC (permalink / raw)
  To: Jacques.Garrigue; +Cc: skaller, caml-list

Jacques Garrigue wrote:
> 
> From: skaller <skaller@maxtal.com.au>
> 
> > The problem is that when I create an object with alloc_final(_,_,0,1),
> > the finaliser is not called on termination. Using 1,1 seems to cause
> > it to be called almost immediately.
> 
> The meaning of the two last parameters is a fraction giving the
> maximum number of times allocation may be done before GC is
> called. 0/1 means that the GC urgency count is not incremented, so
> this may take an indefinite time. 1/1 means do GC on each allocation.
> 
> As an example, in LablGtk all widgets allocations are finalized, with
> a parameter 1/200. That is, the GC will be called at least every 200
> times I build a pointer to a GtkObject, so that I may not have more
> than 200 stall pointers. This may need some more tuning, but the
> number of pointers you create depends very much on your application.
> 

What's append when we change the finalization parameters values ?
We alloc an object of type toto with 1,200 and another object toto with
9,146

It's the last number which is keep by GC (here 146) and erase previous
value (200)
The same with the pound (1 and 9) or they are adding -> 1+9 = 10 < 146 ?

Thanks,

-- 
#####################################
# Patrick GOLDBRONN                 #
# CEA - DRN/DMT/SYSCO               #
# CE-Saclay, Bâtiment 460           #
# 91191 GIF/YVETTE CEDEX (FRANCE)   #
#                                   #
# Tél : 01 69 08 73 55              #
# Fax : 01 69 08 96 96              #
#####################################




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

* Re:  Finalisation in 2.02
@ 1999-12-13 12:50 Damien Doligez
  0 siblings, 0 replies; 5+ messages in thread
From: Damien Doligez @ 1999-12-13 12:50 UTC (permalink / raw)
  To: caml-list

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

>I'm still using ocaml 2.02, and have encountered what looks like a bug,
>although perhaps it is my understanding, and perhaps it is fixed
>in 2.04, or will be in 3.

IIRC, nothing was changed in that part of the system between 2.02 and
2.04.


>The problem is that when I create an object with alloc_final(_,_,0,1),
>the finaliser is not called on termination. Using 1,1 seems to cause
>it to be called almost immediately.

(0,1) means "don't change the current GC schedule".  It is appropriate
when the resources used by the block (besides heap memory) are
negligible.  (1,1) means "do a major collection right now".


>I'm modifying mlgtk by boxing GtkObjects, this seems necessary
>to allow the collector to call the finaliser which decrements
>the reference count -- however, at least the memory of the object
>doesn't seem to be released when caml terminates.

That's right.  You could say that "exit" deallocates everything, but
the finalisers are not called for that kind of deallocation, only for
normal deallocation during the program's execution.


>Perhaps I should force a full GC collection, just before
>termination? 

That would be a workable solution.  But blocks reachable from global
variables still won't be finalised.


> [I seem to also get this
>behaviour with output to stdout -- I have to flush the file
>after every write, in case an exception terminates the program,
>and these debugging writes are there precisely to track this]

You should have a look at the Printexc module.  A side effect of using
Printexc.catch is that I/O buffers will be flushed before the program
terminates.

-- Damien




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

* Re: Finalisation in 2.02
  1999-12-12  3:38 skaller
@ 1999-12-13  9:35 ` Jacques Garrigue
  1999-12-15  8:41   ` Patrick Goldbronn - SYSCO
  0 siblings, 1 reply; 5+ messages in thread
From: Jacques Garrigue @ 1999-12-13  9:35 UTC (permalink / raw)
  To: skaller; +Cc: caml-list

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

> The problem is that when I create an object with alloc_final(_,_,0,1),
> the finaliser is not called on termination. Using 1,1 seems to cause
> it to be called almost immediately.

The meaning of the two last parameters is a fraction giving the
maximum number of times allocation may be done before GC is
called. 0/1 means that the GC urgency count is not incremented, so
this may take an indefinite time. 1/1 means do GC on each allocation.

As an example, in LablGtk all widgets allocations are finalized, with
a parameter 1/200. That is, the GC will be called at least every 200
times I build a pointer to a GtkObject, so that I may not have more
than 200 stall pointers. This may need some more tuning, but the
number of pointers you create depends very much on your application.

If you want to try it on mlgtk, I suggest you have a look at how it is
done in LablGtk, since it seems to work ok, and this kind of things
(interaction between normal GC and reference counting GC) may be
bug-prone.

(You may also choose to switch to lablgtk, since it will work on the
next version of ocaml :-)

> Perhaps I should force a full GC collection, just before
> termination? 

I don't think you need to do it. Reference counting is just to
deallocate unused resources in long running programs, it does not
change anything in your interaction with the program.

Regards,

Jacques
------------------------------------------------------
Jacques Garrigue, visiting INRIA from Kyoto University
		          Jacques.Garrigue at inria.fr




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

* Finalisation in 2.02
@ 1999-12-12  3:38 skaller
  1999-12-13  9:35 ` Jacques Garrigue
  0 siblings, 1 reply; 5+ messages in thread
From: skaller @ 1999-12-12  3:38 UTC (permalink / raw)
  To: caml-list

I'm still using ocaml 2.02, and have encountered what looks like a bug,
although perhaps it is my understanding, and perhaps it is fixed
in 2.04, or will be in 3.

The problem is that when I create an object with alloc_final(_,_,0,1),
the finaliser is not called on termination. Using 1,1 seems to cause
it to be called almost immediately. [I seem to also get this
behaviour with output to stdout -- I have to flush the file
after every write, in case an exception terminates the program,
and these debugging writes are there precisely to track this]

I'm modifying mlgtk by boxing GtkObjects, this seems necessary
to allow the collector to call the finaliser which decrements
the reference count -- however, at least the memory of the object
doesn't seem to be released when caml terminates.

Does 0,1 mean 'never bother calling the finaliser,
there is nothing to finalise'? That makes mathematical
sense (but isn't what I expected, since the documentation
advises to use this setting if you aren't sure).

Perhaps I should force a full GC collection, just before
termination? 

BTW: I would like to reinforce comments that ocaml is
easy to interface! In fact, it is easier than Python
or Tcl (I have extensive experience with both).
I don't claim to really understand everything yet --
but I seem to be able to get code working very quickly.

-- 
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] 5+ messages in thread

end of thread, other threads:[~1999-12-23 19:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-23 17:06 Finalisation in 2.02 Damien Doligez
  -- strict thread matches above, loose matches on Subject: below --
1999-12-13 12:50 Damien Doligez
1999-12-12  3:38 skaller
1999-12-13  9:35 ` Jacques Garrigue
1999-12-15  8:41   ` Patrick Goldbronn - SYSCO

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