turning off garbage collection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

turning off garbage collection

Chris Muller-3
I'm trying to investigate a reproducible Cog crash and beginning to
wonder whether Cog may have some sort of timing issue with the garbage
collector.

Is there an easy way to turn off the garbage collector in the image?

Reply | Threaded
Open this post in threaded view
|

Re: turning off garbage collection

Bert Freudenberg

On 31.07.2012, at 09:17, Chris Muller wrote:

> I'm trying to investigate a reproducible Cog crash and beginning to
> wonder whether Cog may have some sort of timing issue with the garbage
> collector.
>
> Is there an easy way to turn off the garbage collector in the image?

I don't think so, but you could raise the limits so GC occurs less often.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: turning off garbage collection

Chris Muller-3
With standard GC settings the test survived for 30 seconds before VM
crash.  When I upped vmParameter 5 to 100,000,000 the test survived
for 228 seconds.

Is there a way to know when a GC occurs (either kind)?  I've
instrumented several methods to log to a global log file -- I'd like
to try to confirm the crash coincides with a GC..



On Tue, Jul 31, 2012 at 1:01 PM, Bert Freudenberg <[hidden email]> wrote:

>
> On 31.07.2012, at 09:17, Chris Muller wrote:
>
>> I'm trying to investigate a reproducible Cog crash and beginning to
>> wonder whether Cog may have some sort of timing issue with the garbage
>> collector.
>>
>> Is there an easy way to turn off the garbage collector in the image?
>
> I don't think so, but you could raise the limits so GC occurs less often.
>
> - Bert -
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: turning off garbage collection

Eliot Miranda-2


On Tue, Jul 31, 2012 at 12:10 PM, Chris Muller <[hidden email]> wrote:
With standard GC settings the test survived for 30 seconds before VM
crash.  When I upped vmParameter 5 to 100,000,000 the test survived
for 228 seconds.

Is there a way to know when a GC occurs (either kind)?  I've
instrumented several methods to log to a global log file -- I'd like
to try to confirm the crash coincides with a GC..

The API isn't stable but you can turn on tracing of process switches and GCs via

thevm -sendtrace 16 my.image

Run this under gdb then use dumpTraceLog() to print the events.  The problem is that if the crash is in the GC then the problem is probably heap corruption long before the GC (e.g. through an FFI call trampling over the end of an object).  There is enormous timing variation in Squeak right now because of Time initialization when the image waits for up to on second to see when the clock ticks, to sync the second and millisecond clocks.  I have removed this in our Newspeak images at Cadence, replacing it with use of the 64-bit microsecond clock, which does not have a synchronisation problem since both milliseconds and seconds can be derived from the one clock.  But we can't move to this until the standard VM provides 64-bit local microsecond clocks (local and utc) with primitive numbers/names that match cog.



On Tue, Jul 31, 2012 at 1:01 PM, Bert Freudenberg <[hidden email]> wrote:
>
> On 31.07.2012, at 09:17, Chris Muller wrote:
>
>> I'm trying to investigate a reproducible Cog crash and beginning to
>> wonder whether Cog may have some sort of timing issue with the garbage
>> collector.
>>
>> Is there an easy way to turn off the garbage collector in the image?
>
> I don't think so, but you could raise the limits so GC occurs less often.
>
> - Bert -
>
>
>




--
best,
Eliot