Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of alexey.v.varlamov@gmail.com
 designates 64.233.184.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OV1TkHOZd6uQIR5Y/OPIVd7FKAOiWe5+Jot5/P79ETRJKkITqHEpptaiNh6OCQpvfHSWZBUtMQ2AG+gUi/GWLu6qFRYxeETeMdi+zNNuXeia1mM7fCWBmKUf4mKvaAJHLiAGqEYyXdO5Uxpl0Ci7FwhVoLgfIPYNE2aO+Tt4tc0=
Message-ID: <f944d83d0701112205w75fc6e45hf408b91d2ab468dd@mail.gmail.com>
Date: Fri, 12 Jan 2007 12:05:20 +0600
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm] stress.Mix / MegaSpawn threading bug
In-Reply-To: <eo6089$ilv$2@sea.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <97EB9EC8-ECCD-4E9A-A165-F16310C37133@pobox.com>
	 <51d555c70701091014n6f6874ocdb08fdeb383213e@mail.gmail.com>
	 <3A2DFD3D-60F3-477C-838F-E7BAD8F22FBB@pobox.com>
	 <eo2r0f$ktb$1@sea.gmane.org>
	 <6396856A-FA18-4482-896C-2621822EE7E4@pobox.com>
	 <4dd1f3f00701101113s4c520a08uc7a333565955aece@mail.gmail.com>
	 <4229DCE9-63F0-489A-B4FE-32D21B0FDAA4@pobox.com>
	 <51d555c70701101942v4bf01f9cwb83558302a477354@mail.gmail.com>
	 <e29119980701102104y3ecbf747ua323bc6c5e3005ef@mail.gmail.com>
	 <eo6089$ilv$2@sea.gmane.org>

2007/1/12, Salikh Zakirov <Salikh.Zakirov@intel.com>:
>
> >> >> 2)
> >> > >> Why not simply hard code DRLVM to throw an OOME whenever there are
> >> > >> more than
> >> > >> 1K threads running?  I think Rana first suggested this approach.
> >> > >> My guess
> >> > >> is that 1K threads is good enough to run lots of interesting
> >> > >> workloads.  My
> >> > >> guess is that common versions of WinXP and Linux will handle the C
> >> > >> malloc()
> >> > >> load of 1K threads successfully.  If not, how about trying 512
> >> > >> threads?
>
> I've tried a quick-and-dirty patch to limit the number of threads to 500,
> and it indeed fixes crashes on MegaSpawn.
>
> > -1 for hard coding max number of threads.
>
> Alexey's proposal to watch virtual memory availability looks feasible,
> and will let us avoid hardcoding any number.

Yes, but it will not work until exact key points for memory check-up
are specified.
And probably finding all such points is nearly equivalent to fixing
them for error conditions :)

>
> My observation is that limiting number of concurrently running threads
> is by far easier than implementing some sort of custom memory manager
> with reserve areas etc, and will allow us to get over MegaSpawn failures.
>
But, as many already pointed, what is the benefit of rounding
particular corner cases? It does not really help gaining better
reliability etc.
The easiest solution is just to put MegaSpawn in exclude list
forever^H^H^H^H^H^H^H until its' time comes ;)