Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gc bug? #3374

Closed
vicuna opened this issue Jun 5, 2002 · 2 comments
Closed

gc bug? #3374

vicuna opened this issue Jun 5, 2002 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jun 5, 2002

Original bug ID: 1183
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Winfried Dreckmann
Version: 3.04
OS: Suse Linux 6.4 PowerPC
Submission from: t4o960p112.telia.com (195.252.61.232)

I found that optimized code in some cases takes much longer than byte code, and
has strange gc statistics. The simplest case is as follows:

file "test.ml"

let main () =
let foo =
Array.init 100000 (fun i -> String.make 1 'x')
in
Gc.print_stat stdout;
exit 0;;

main ();;

Compiling with ocamlc and ocamlopt,

ocamlc -o testc test.ml
ocamlopt -o testopt test.ml

I get the following output:

./testc
...
minor_collections: 4
major_collections: 26
...

./testopt
...
minor_collections: 180
major_collections: 100001
...

So in the second case, every single allocation leads to a major
collection. In fact, execution takes much longer. This happens with
Ocaml 3.02 and 3.04. Trying the current CVS version (June 5), I get

./testc
...
minor_collections: 26
major_collections: 4
...

./testopt
...
minor_collections: 100001
major_collections: 21
...

What is going on?

@vicuna
Copy link
Author

vicuna commented Jun 6, 2002

Comment author: administrator

I found that optimized code in some cases takes much longer than
byte code, and has strange gc statistics. The simplest case is as
follows:

Thanks for the interesting test case. There was indeed a bug in the
GC interface for ocamlopt-generated code: namely, the runtime system
sometimes simulates a "minor heap is full" condition in order to
trigger a garbage collection early, and in your particular example
this condition was not reset properly by the garbage collection,
causing the minor heap to appear full for the duration of your
program. This will be fixed shortly.

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jun 6, 2002

Comment author: administrator

Fixed 2002-06-06 by XL

@vicuna vicuna closed this as completed Jun 6, 2002
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant