harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] HARMONY-1582 - invocation API for DRLVM
Date Wed, 27 Sep 2006 20:04:33 GMT
On 9/26/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
>
> On 9/27/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> > (3)
> > One more lock is added - hythread_lib_lock. How is that differ from
> > the hythread_global_lock that we already have? Each extra lock to the
> > system may add more possibilities for deadlocks, as well as can
> > negatively impact the scalability (unless some of the existing locks
> > are split).
> hythread_lib_lock acquires exactly the same lock as
> hythread_global_lock. Probably I miss something but we need to be
> compatible with IBM threading library now. This library has such
> function. That's why I added it. Sounds right?


Well,  this sort of, kind of sounds right but not quite.  Its a little more
subtle than being compatible with IBM threading library.  The first goal is
to identify the parts of IBM threading library that are JVM independent.  It
makes sense for DRLVM to be compatible with the independent parts.   This
should be a nobrainer.

The parts of IBM threading library that assume a specific JVM implementation
will be a problem.  We will need to find a solution that is endorsed by all
the stakeholders (including J9 folks).  The hythread_global_lock falls into
this category.  For starts, I would like to see a concise description from
the portlib owners on what hythread_global_lock protects, which locks have
to be held before grabbing this lock, are there any restrictions on what
system calls can be made while holding this lock (like sleep or wait), etc.

To get a better idea what's in the patch.diff, I printed it out.  Its 120+
pages.  Quite a big patch!  Most of it looks like straight forward JNI
interface glue.  There are some tricky parts.  I would like to know the
design review process for these parts.  Using grep, I found 20 locations
where ...suspend_enable... and ...suspend_disable... have been added.  And
25 locations where enable/disable have been removed.  Failure in this logic
can lead to incorrect reference pointer enumeration.  These are probably the
hardest bugs to find.  Please tell us who has looked at this code in depth.
Are there any known design flaws in it?

I also notice APIs called tmn_suspend_enable(), hythread_suspend_enable()
-- are these simply different names for the same binary executible.  Or
different binaries that do the same thing??


-- 
> Weldon Washburn
> Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message