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 <[email protected]> wrote: > > In message <[email protected]>, > 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/
