harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Wed, 20 Sep 2006 06:19:45 GMT
If we take a closer look at the classlib's hythread, then we may find
two different layers within it (I'm hoping that the original hythread
authors may correct me):

(1) Lower-level Portability Layer
This is mostly contained in the
modules\luni\src\main\native\include\windows\hymutex.h and
modules\luni\src\main\native\thread\windows\thrdsup.h. It provides a
mapping between a "POSIX-like " threading API and the appropriate OS
functions
This seems like a portability layer for the hythread module which is
expressed with the macros, for example:
#define MUTEX_ENTER(mutex) EnterCriticalSection(&(mutex))

(2) Upper-level (not classlib specific)
This is basically hythread_XXX API. This level incorporates  Java
threading model specifics, like monitors and interruption support.
Plus, support for "JLM" (I guess this is a kind of the debugging API
similar to JVMTI?)

My understanding is that the classlib is using hythread mostly for the
following purposes:
- Synchronization (e.g. monitor_enter/exit, wait/notify)
- Thread local storage access
- Thread creation (needed in hysig module to start signal handling thread)

One may also find the real list of the hythread functionality being
used in the export def for DRLVM's past "hythread emulator" [1].

Thus it seems layer (1) should be enough for the classlib's purposes,
while the layer (2) is mostly needed for JVM itself.

Assuming a JVM needs a specific implementation of layer (2), it might
make sense in the long term to keep only layer (1) as part of
classlib.  For now, the existing layer (2) can stay where it is at and
not disturbed.  It would only be accessed by a JVM that requires it.
All other JVMs would simply ignore layer (2). The real problem that
can potentially lead to the conflicts between different hythreads is
that the classlib currently has the dependencies on VM-specific layer
(2).

How about replacing the existing hythread_XXX calls in the classlib
with the macrodefs from the layer (1)? It would help to resolve the
issue of the dependency between the classlib and VM-specific layer
(2).

Another approach could be to replace hythread_XXX calls with apr_XXX
calls in the classlib, which will eventually have the same effect,
assuming that the APR is linked statically. This will add a dependency
on APR static libraries though, and it probably may make sense to do
this if we choose to use APR as a foundation for the portlib. But for
now, may be just the macros from the hymutex.h/thrdsup.h would work
fine for the classlib?

Thanks,
Andrey.

[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/thread/hythr/hythr.def?revision=432130&view=markup


On 9/19/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> All,
>
> we need to put this issue to bed, as we're tripping over it, it seems.
>
> Any thoughts on how to move forward on this?
>
> geir
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message