On Tue, Jul 31, 2012 at 12:10 PM, Chris Muller asqueaker@gmail.com 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 bert@freudenbergs.de 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 -