[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Re: Playing with the VM Limits, crash on many processes

From: Paolo Bonzini
Subject: [Help-smalltalk] Re: Playing with the VM Limits, crash on many processes
Date: Sun, 21 Nov 2010 16:10:46 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6

On 11/21/2010 01:14 PM, Holger Hans Peter Freyther wrote:
On 11/21/2010 11:48 AM, Paolo Bonzini wrote:
On 11/20/2010 06:30 PM, Holger Hans Peter Freyther wrote:
I created the attached torture test to get a feeling of how many processes I
can create and if my planned approach would work. With about 100.000 processes
I ran into a crash inside the GC. Compiling GST without support for the
generational GC seem not to crash.

How much time does it take to crash?  Does it happen even without the printNl.

It crashes without the printNl, it needs the call to delay wait. I can create
the Delay for each process once and it is still crashing, it also needs a lot
of processes to force this crash. It crashes within 30 seconds or such.

Ok, reproduced.  Here is a more deterministic testcase:

Object subclass: Scheduler [
    MutexSem := Semaphore forMutualExclusion.
    TimeoutSem := Semaphore new.

    Scheduler class >> step [ TimeoutSem wait ]
    Scheduler class >> kick [ MutexSem critical: [TimeoutSem signal] ]

Eval [
    [[Scheduler step] repeat] forkAt: Processor userInterruptPriority.
    1 to: 100000 do: [:thread_nr |
        [ | id | id := thread_nr.
            id \\ 1000 == 0 ifTrue: [id printNl].
            20 timesRepeat: [Scheduler kick].
        ] fork.

    Semaphore new wait.

where the Scheduler class is a heavily butchered version of Delay. :)

Interestingly, inlining the two methods in the Eval makes the testcase work, so it's probably something related to contexts.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]