Browse thread
More re GC hanging
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Goswin von Brederlow <goswin-v-b@w...> |
| Subject: | Re: [Caml-list] More re GC hanging |
Paul Steckler <steck@stecksoft.com> writes:
> I haven't yet come up with a solution to the GC hanging problem I
> mentioned the other day.
>
> But here's something that looks funny. I changed the default minor
> heap size, the major
> heap increment, the allocation policy. I also threw in a
> `Gc.major_slice 0' in the code.
> After turning on the Gc verbose option, I see:
>
> New heap increment size: 1000k bytes
> New allocation policy: 1
> New minor heap size: 500k bytes
> <>Starting new major GC cycle
> allocated_words = 9404
> extra_heap_resources = 49000u
> amount of work to do = 249956u
> ordered work = 0 words
> computed work = 44081 words
> Marking 44081 words
> Subphase = 10
> !<>Sweeping 9223372036854775807 words
> Starting new major GC cycle
> Marking 9223372036854775807 words
> Subphase = 10
> Sweeping 9223372036854775807 words
>
> Those are some big mark and sweep numbers at the end!
>
> I'm using the x64 version of Fedora 12. Maybe the 64-bit garbage
> collector has some integer
> overflow problems?
>
> I wasn't seeing those huge numbers in other experiments where the Gc
> hangs, so maybe that's
> not the underlying problem.
>
> -- Paul
I wondered about that as well. I think this is some uninitialized value
in the GC statistics.
MfG
Goswin