harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [drlvm] Use of SIGUSR2
Date Sun, 01 Mar 2009 23:45:03 GMT

In message <c30d70960903010950jf76aa2reedf26a295ebda2a@mail.gmail.com>,
Alexei Fedotov writes:
> Mark,
> Thank you for starting a discussion. Could you please share your
> understanding of few questions?
> 1. How serious is a performance penalty caused by wrapping syscalls?

My issue was more to do with the added complexity in the code and the
fact that wrapped/restarted syscalls can never behave in quite the same
way (w.r.t. timing particularly) as unwrapped calls.

As an example of the complexity issue, the calls which need wrapping
vary on different platforms and some calls may or may not need wrapping
depending on their arguments.  On Linux, some calls need wrapping
depending on the kernel version.

It may be that we end up wrapping too many calls (and probably all
invocations regardless of arguments) to cover the possible cases and
assume that EINTR is only resulting from instances where we are supposed
to restart/retry.  So arguably the complexity is in figuring out which
calls must be wrapped rather in the implementation of the wrapping

I think there are probably around 100 syscalls which can return EINTR
and should probably be wrapped.  I hope we don't need to wrap them

> 2. Do I understand correctly that wrapping logic is the same for
> wrapping spurious syscall interrupts?

Almost.  For some calls it literally means retrying with exactly the
same arguments.  For calls with timeouts you need to track the amount
of time that has been consumed and adjust the timeout accordingly.  We
should probably try to figure out if it was the SIGUSR2 signal that
interrupted us and not some other signal that really should result in an

> 3. We agreed earlier to call DRLVM as Harmony VM. Is it to be revised?

We did?  I must have missed that.  Can you provide any pointers to this

> Here are few my answers, all AFAIK.
> 1. BEA VM used signals for suspension, which resembles Harmony VM scheme.
> 2. I believe there are alternatives, for example if OS fully supports
> thread cancellation points.
> 3. If the performance impact is quite low and the wrapping logic is
> pretty simple, the fix might be easier to do in class library.

I'm not convinced it is easier but from Gregory's comments it would
appear that use of signals is common enough among VMs that classlib
probably should learn to live with them.

> 4. I have memorable experience how much does it cost to rewrite thread
> suspension code. Two mighty champions re-implemented threading
> subsystem using portlib threading API, and this resulted in a year of
> painful debugging. Though we may ask some GSoC student who does not
> know fear to try. :-)

I thought DRLVM used it's own version of the portlib threading API?  It
certainly seems to have additional exports compared to the classlib one.


View raw message