harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [drlvm] Use of SIGUSR2
Date Sun, 01 Mar 2009 18:26:08 GMT
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


View raw message