harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Tue, 26 Sep 2006 11:04:48 GMT
Sorry for the delay in responding Andrey...

Andrey Chernyshev wrote:
> 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?)

it's a lock monitor

> 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.

for sure, there is more in the threadlib than strictly required by the
classlib native code.

> 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.

I agree, they were bundled to together in harmony's history, but it
makes sense to pull it out now we have active vm development that
requires this function.

> 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).

A combination of unifying the classlib use of the threadlib code, and
pulling the threadlib up to be a peer of the VM and classlib is a good
idea.  We can then massage it to suit harmony as a whole and resolve
those conflicts.

> 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?

Let's go one step at a time, and work towards the common harmony thread
library first.  Once we understand the shared requirements we can figure
out whether to go via APR or straight to the OS.



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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

View raw message