From dev-return-36308-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Sun Mar 01 18:26:43 2009 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 8073 invoked from network); 1 Mar 2009 18:26:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Mar 2009 18:26:43 -0000 Received: (qmail 35017 invoked by uid 500); 1 Mar 2009 18:26:42 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 34981 invoked by uid 500); 1 Mar 2009 18:26:42 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 34970 invoked by uid 99); 1 Mar 2009 18:26:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Mar 2009 10:26:41 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gshimansky@gmail.com designates 72.14.220.159 as permitted sender) Received: from [72.14.220.159] (HELO fg-out-1718.google.com) (72.14.220.159) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Mar 2009 18:26:32 +0000 Received: by fg-out-1718.google.com with SMTP id l27so1018552fgb.36 for ; Sun, 01 Mar 2009 10:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=3Xol91aqs6r6dxvSrCQ4tKmluU4mB9Yb9i9vBJnCPT4=; b=jKOzvw2YDJ2lgSrHgvFh8kjQaPC4mdsKvkf2xIdT/y77wgFLb4JhVgqw0DYwXI/JIT Dp3LGaz4I0Q7bZd/mX9C0tI6eRMc98JYLnmRpIGEZ9ZKFqNpyR4aeZeGtQN08QPvyj3W hfClBx66ly6Jk2eC617VOt89gpaqnIumY5dqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=UF7WFaGud0sgLbouWsQWg6XvwGfknglMu6ZihpKxr3054NkIKn6lOuuzMYSlPa4Dy2 FXBuCmcnLzCIe5aBMfgtqSO6j3yb7DHBsUDtyU3dlJtrWWZq9KjDu9LHPzt6uBnJIxzS 8UuPd6mcaOFP6a4kbQn0NuhMzn4ZoDMDOQ7Rs= Received: by 10.86.70.3 with SMTP id s3mr3110282fga.56.1235931971804; Sun, 01 Mar 2009 10:26:11 -0800 (PST) Received: from desktop (ppp91-77-31-185.pppoe.mtu-net.ru [91.77.31.185]) by mx.google.com with ESMTPS id 4sm8515607fgg.39.2009.03.01.10.26.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Mar 2009 10:26:10 -0800 (PST) Sender: Gregory Shimansky From: Gregory Shimansky To: dev@harmony.apache.org Subject: Re: [drlvm] Use of SIGUSR2 Date: Sun, 1 Mar 2009 21:26:08 +0300 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903012126.08248.gshimansky@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org On 1 March 2009 Mark Hindess wrote: > The latest issue on the "Problems with NIO" thread (message dated Wed, > 25 Feb 2009 23:09:49 +0100) seems to another case of a syscall being > interrupted by an internal SIGUSR2 and reporting an error that needs to > be caught and the signal retried. There are already several cases where > the code "works around" this issue. And *every* occurence of affected > syscalls[0] needs to be wrapped in this logic. > > The IBM VM doesn't do this kind of wrapping and I assume neither does > Sun's since all signals they receive are external and thus raising > the exception is the required behaviour. I can't help thinking that > replacing the use of SIGUSR2 would be an easier option long term - and > better for performance - than wrapping every syscall. Actually if you strace Sun or Jrockit you would see tons of SIGUSR[1|2] (different VMs use different numbers) signals. There is even a special switch -XX:+UseAltSigs which allows Sun's VM to use signals other than SIGUSR for their internal use [1]. I found other pages about signal usages by Sun's and BEA VMs [2][3][4]. > From a selfish classlib perspective, it is wrong to fix these issues in > classlib since wrapping syscalls imposes a performance penalty on all > VMs (such as Jikes and IBM's) even though they do not need this extra > code. It certainly makes the code harder to read, write and maintain. > So it would be nice to "fix" it in DRLVM. > > Can someone explain why DRLVM uses SIGUSR2? And what alternatives are > there? Could we not use signals? Other VMs seem to manage without > them? How? Could we mask the signal when entering native oode? > > Regards, > Mark. > > [0] The DRLVM code does use the SA_RESTART flag so some syscalls are > automatically restarted but many calls are not. On Linux[1], the most > important for us are epoll_wait(2), epoll_pwait(2), poll(2), ppoll(2), > select(2), and pselect(2). For precise details, see "Interruption of > System Calls and Library Functions by Signal Handlers" in signal(7). > > [1] The signal(7) man page also says "The details vary across Unix > systems" which implies that the calls needing wrapping will be different > across different unix systems making porting classlib for DRLVM on > non-Linux systems even more difficult. (Of course, this will only be an > issue if DRLVM ever gets ported to anything else.) [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html [2] http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/signals.html [3] http://edocs.bea.com/jrockit/geninfo/devapps/codeprac.html#wp1005153 [4] http://java.sun.com/j2se/1.5.0/docs/guide/vm/signal-chaining.html -- Gregory