headers
Damien Doligez | 2 Oct 2000 11:23
Picon
Picon
Favicon

Re: Garbage collection in OCaml

>From: "David McClain" <dmcclain <at> azstarnet.com>

>I have a long running analysis program written in compiled OCaml (ocamlopt).
>If I let it run without interference it gradually allocates more and more
>memory until the system swap space is exhausted. At that point the program
>bombs off with an "out of memory" errror - probably generated by the OCaml
>array management routines.

Most likely, a fragmentation problem.  If you're using a lot of arrays
or strings with different sizes, it can happen.

>OTOH, I found by tinkering that placing a Gc.compact() in a periodically
>performed place, I manage to keep the entire system running within about 70
>MBytes. (My machines all have 256 MB RAM or more).

Thus we know for sure it was a fragmentation problem.

>I have found that placing a Gc.full_major() does virtually nothing to
>prevent the exhaustion of memory, although it slows it down ever so
>slightly.

Gc.full_major() is not going to help, that's normal.

>The program was compiled to run with the default GC settings (whatever those
>are). That is to say, I did nothing to configure the GC system at program
>startup.
>
>Is this behavior normal? Must I plant strategic Gc.compact() in my code? I
>would have thought the GC would be more self monitoring.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick M Doane | 2 Oct 2000 15:11

Re: bottom types and threaded exits

On 30 Sep 2000, Stefan Monnier wrote:

> A function of type "t1 -> t2" does not necessarily return an object of type t2.
> But if it does return, then the value is of type t2.
> Similarly, a function of type "t1 -> 'a" (if it returns) returns an value
> of type 'a.  Parametricity allows us to infer from that that if t1 does
> not contain 'a as a free type variable, then the function will necessarily
> never return (since it has no way to construct an value of
> type 'a).

This may be too obvious to point out, but that statement isn't always
true. From the Pervasives library:

  val input_value : in_channel -> 'a

clearly returns. I don't quite understood why the return type isn't
a monomorphic type variable though.

Patrick Doane
Permalink | Reply | 2 comments |
headers
Markus Mottl | 2 Oct 2000 18:28
Picon

Re: bottom types and threaded exits

On Mon, 02 Oct 2000, Patrick M Doane wrote:
> This may be too obvious to point out, but that statement isn't always
> true. From the Pervasives library:
> 
>   val input_value : in_channel -> 'a
> 
> clearly returns. I don't quite understood why the return type isn't
> a monomorphic type variable though.

The "input_value"-function is unfortunately not type safe: you can "cast"
whatever data you get from the channel to any kind of type - whether this
is correct or not. There is currently no better way to do it if you want to
reconstruct marshalled data (data that was sent with output_value). You
have to trust that the OCaml-data you get is of the type you expect.

Pierre mentioned that there is work going on in this field (a PhD-thesis)
that should make I/O much safer. Is there any news about this?

Best regards,
Markus Mottl

--

-- 
Markus Mottl, mottl <at> miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
Permalink | Reply | 1 comment |
headers
David McClain | 2 Oct 2000 19:15
Picon
Favicon

Re: Garbage collection in OCaml

Yes, Thanks so much for your helpful suggestions! Your Gc settings were what
I was hoping to find from someone with insight to the behavior of the GC. I
am trying them as we speak!

Cheers!

- DM

-----Original Message-----
From: Damien Doligez <Damien.Doligez <at> inria.fr>
To: caml-list <at> inria.fr <caml-list <at> inria.fr>
Date: Monday, October 02, 2000 4:32 AM
Subject: Re: Garbage collection in OCaml

>>From: "David McClain" <dmcclain <at> azstarnet.com>
>
>>I have a long running analysis program written in compiled OCaml
(ocamlopt).
>>If I let it run without interference it gradually allocates more and more
>>memory until the system swap space is exhausted. At that point the program
>>bombs off with an "out of memory" errror - probably generated by the OCaml
>>array management routines.
>
>Most likely, a fragmentation problem.  If you're using a lot of arrays
>or strings with different sizes, it can happen.
>
>
>>OTOH, I found by tinkering that placing a Gc.compact() in a periodically
>>performed place, I manage to keep the entire system running within about
70
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Assange | 2 Oct 2000 18:38

list of objects


I have a variety of signature schemes for text. I'd like to have
a list of these schemes, so I can do such things as:

        List.map (fun x -> x#make text) schemes

Neither classes or modules are first class objects. However, 
objects are. So, my first thought was to create something along the lines
of 

        let schemes = [new scheme_11; ...; new scheme_n]

Since the objects are functional (at least so far) this seems like an
acceptable approach. 

  class virtual signature =
  object 
  end

  class ['a] plain =
  object (self)
    inherit signature
    method make s = s
    method digest s = Digest.string (self#make s)
    method compare (a:'a) b = a = b
  end

  class ['a] simple =
  object
    inherit ['a] plain
(Continue reading)

Permalink | Reply | 1 comment |
headers
Georges Mariano | 3 Oct 2000 11:09
Picon
Picon

XSL processor in OCaml

Hi everyone,

I'm looking for (Ocaml) code related to XSL style sheet processing...

Any suggestion ?

Cheers
--

-- 
> Georges MARIANO                 tel: (33) 03 20 43 84 06
> INRETS, 20 rue Elisee Reclus    fax: (33) 03 20 43 83 59
> 59650 Villeneuve d'Ascq         mailto:mariano <at> terre.inrets.fr
> FRANCE.                         
> http://www3.inrets.fr/Public/ESTAS/Mariano.Georges/
> http://www3.inrets.fr/B-Bibliography.html         mailto:Bforum <at> estas1.inrets.fr
Permalink | Reply | 0 comments |
headers
Xavier Leroy | 3 Oct 2000 11:53
Picon
Picon
Favicon

Re: list of objects

Your approach looks reasonable.  As for your question:

> let sig_list = [new plain; new simple] 
> On compilation, this produces:
>   The type of this expression, '_a Sigs.plain list,
>   contains type variables that cannot be generalized
> However sending the exact same code to the top level,
> produces:
> val sig_list : '_a Sigs.plain list = [<obj>; <obj>]
> Works just fine! What gives?

The '_a is a non-generalized type variable, i.e. an unknown type that
will be determined later at first use.  (See the FAQ
http://caml.inria.fr/FAQ/FAQ_EXPERT-eng.html for more detailed
explanations.)

For separately-compiled units, the notion of "first use" is unclear,
since the unit can be referenced by several other separately-compiled
units, which could each instantiate the unknown type in different
ways.  So, to keep things simple, the compiler requires that no
non-generalized type variables remain in the types inferred for
definitions of a compilation unit.

Thus, you need to put either a .mli file giving the type you want for
sig_list, or a type constraint on the definition of sig_list:
        let sig_list = ([new plain; new simple] : t Sigs.plain list)
with the type you want for "t".

Hope this helps,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Norman Ramsey | 3 Oct 2000 23:50
Picon

ratio of heap size to live data in Caml GC?

Can anybody tell me what ratio of heap size to live data the OCaml collector
needs to perform well?  The default ratio appears to be 2.4.  I assume
this means the collector is a mark-and-sweep collector?

Norman
Permalink | Reply | 2 comments |
headers
David=?iso-8859-1?q?_Mentr=E9?= | 4 Oct 2000 12:14
Picon
Favicon

Re: ratio of heap size to live data in Caml GC?

Norman Ramsey <nr <at> eecs.harvard.edu> writes:

>  I assume this means the collector is a mark-and-sweep collector?

As far as I have understood, the collector is a combination of a
mark&sweep (at major collection) and of a generation (at minor
collection) collectors.

You'll find a description of this collector, unfortunatly in french, on
this web pages :
 http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/book-ora088.html

I *think* you'll find a close description of the actual GC in the
following paper. As I haven't read thise papers, you are on your own :

Damien Doligez, Xavier Leroy. "A concurrent, generational garbage
collector for a multithreaded implementation of ML". Proceedings POPL
93.
http://pauillac.inria.fr/~xleroy/publi/concurrent-gc.ps.gz

      This paper presents the design and implementation of a ``quasi
      real-time'' garbage collector for Concurrent Caml Light, an
      implementation of ML with threads. This two-generation system
      combines a fast, asynchronous copying collector on the young
      generation with a non-disruptive concurrent marking collector on
      the old generation. This design crucially relies on the ML
      compile-time distinction between mutable and immutable
      objects. (BibTeX reference.)

Hope it helps,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bomshik Kim | 5 Oct 2000 04:08
Picon

(unknown)


Hello.

I do programming with  both ocaml and camltk.
Compiling source code produces binary (with -custom option).

But the binary can't run on another machine which does not have
tcl, tk library.

The error message is like this

   Fatal error: uncaught exception Protocol.TkError
        ("Can't find a usable init.tcl
        in the following directories:
         /usr/local/lib/tcl7.6 ./lib/tcl7.6 ./tcl7.6/library ./library
        This probably means that Tcl wasn't installed properly.
        ")

Someone let me know that "-static" option may solve this problem.
but that also makes another error.

/usr/bin/ld: cannot open -lcurses: no such a file or directory
collect2: ld returned 1 exit status
Error while building custom runtime system
make: *** [system] Error 2

How can I make binary which runs well where tcl, tk are not installed?

I add linking command of Makefile.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane