harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: [drlvm] Use of SIGUSR2
Date Mon, 02 Mar 2009 15:57:50 GMT
Hello Mark,

> I thought DRLVM used it's own version of the portlib threading API?
Harmony VM has its own threading implementation.

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

I'm sorry. I see a discussion, but to the best of my search
capabilities I cannot provide a pointer to the mentioned result. I
recall the following rationale for renaming: while we have many
machines which use Harmony classlib, only one is shipped as a part of
official Harmony release. The importance of the release implies that
harmony project members share care and warmth about this VM.

Thanks.


On Mon, Mar 2, 2009 at 2:45 AM, Mark Hindess
<mark.hindess@googlemail.com> wrote:
>
> 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
> itself.
>
> 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
> all.
>
>> 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
> error.
>
>> 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
> discussion?
>
>> 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.
>
> Regards,
>  Mark
>
>
>



-- 
С уважением,
Алексей Федотов,
http://people.apache.org/~aaf/

Mime
View raw message