Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 54075 invoked from network); 24 Jul 2006 14:04:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Jul 2006 14:04:37 -0000 Received: (qmail 66434 invoked by uid 500); 24 Jul 2006 14:04:33 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 66390 invoked by uid 500); 24 Jul 2006 14:04:33 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 66379 invoked by uid 99); 24 Jul 2006 14:04:33 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Jul 2006 07:04:33 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of weldonwjw@gmail.com designates 64.233.182.189 as permitted sender) Received: from [64.233.182.189] (HELO nf-out-0910.google.com) (64.233.182.189) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Jul 2006 07:04:32 -0700 Received: by nf-out-0910.google.com with SMTP id x4so1535618nfb for ; Mon, 24 Jul 2006 07:04:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qK96R2f4Y4LH9sSneeV6HAhiyb7aGCmt8buVa3z0N4mZ9arcjrwUd9isrBtdnPnxWZ9/73ob+XbVBN5CpvamgBmBpnDoXqYemmEEex6MUa1DLtHaLilaVCovxCydZ6OdRlClLyo7dwoMFuo1F4i1rKsksH4t0XvbitalObhhpF8= Received: by 10.78.165.16 with SMTP id n16mr1512554hue; Mon, 24 Jul 2006 07:04:08 -0700 (PDT) Received: by 10.78.129.14 with HTTP; Mon, 24 Jul 2006 07:04:08 -0700 (PDT) Message-ID: <4dd1f3f00607240704v52e36f08uf7141147801a5055@mail.gmail.com> Date: Mon, 24 Jul 2006 07:04:08 -0700 From: "Weldon Washburn" To: harmony-dev@incubator.apache.org Subject: Re: Stack Overflow Error support issues In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <783bf8b0606221051g557ac491xc55244d9f770457d@mail.gmail.com> <4dd1f3f00606280654n4e9cde5fgf7f4bedd5dd75042@mail.gmail.com> <783bf8b0606280713nf5d5567pe26f60aae933e3d5@mail.gmail.com> <51d555c70606291437x497da2fbr715ae49253b88717@mail.gmail.com> <783bf8b0607210433i52c7074fhcde6c65dc07da677@mail.gmail.com> <51d555c70607211241w2b313d77ob7af984560fd5d56@mail.gmail.com> <783bf8b0607240314v6f1ea511x4217773e0cb185a0@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 7/24/06, Mikhail Fursov wrote: > No, I think that VM can do this check but use lower border: e.g. 1/100 of > initial. > JIT must do this check more accurate: use knowledge of algorithms it uses. > > The requirement to avoid SOE during a compilation can affect any algorithm > in JIT that uses recursion. Jitrino.OPT has a lot of such algorithms: node, > insts, opnd based . So I'm not sure that JIT can construct a heuristic or a > profile to refuse to compile a method in the beginning of the compilation. > The another option is to check available stack size before any recursion > based algorithm and limit the algorithm up to N steps in recursion (N is > recomputed in runtime) . If N steps is not enough algorithm will fail and > JIT will not not perform the optimization or compilation at all. > Quite a lot of changes in JIT though. Any other ideas? I would be hesitant to make a bunch of changes to the jit. 1) it might cause stability problems. 2) It still does not fix the root problem. In specific, it is quite easy in C code to cause gobs of the stack to be grabbed. You can even grab so much stack that you leap over the guard page then mysteriously crash. 3) what is wrong with setting the guard at 256KB or larger for now? Since we are not running lots of threads at this point, we can afford to make each java stack even 4MB big with 1MB guard pages. This will allow us to quickly rule out stack overflow as a cause of JVM crash. Perhaps the max stack and guard page size can be adjustable at command level. Also, I looked at the source code contained in harmony-945. I did not see a regession test or unit test. Would it be possible to add this? > > > > > On 7/24/06, Pavel Afremov wrote: > > > > Hi > > > > On 7/22/06, Mikhail Fursov wrote: > > > > > I think this must be a JIT heuristics because even a small method can > > lead > > > to inlining of whole classlib API :) > > > > > > Are You think this check should be removed from VM and puted into JIT > > only? > > > > BR > > Pavel Afremov. > > > > > > > -- > Mikhail Fursov > > -- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org