You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/09/19 14:18:09 UTC
[drlvm][classlib] thread library - let there be one!
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Tim Ellison <t....@gmail.com>.
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)
right
> 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.
Regards,
Tim
--
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Andrey Chernyshev <a....@gmail.com>.
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. <ge...@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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Weldon Washburn <we...@gmail.com>.
On 11/10/06, Alexey Varlamov <al...@gmail.com> wrote:
>
> 2006/11/10, Weldon Washburn <we...@gmail.com>:
> > hmm.... it seems that we need to create "kernel natives", the C version
> > of java kernel classes. The expectation is that the JVM supplier would
> > write their own kernel natives. And the classlib native code would only
> > call kernel natives. Thoughts?
>
> I don't understand this. We already have VMI (for common purposes),
> and even if hythread shed implementation, it preserves functioning as
> interface to threading nevertheless. If this means we should somehow
> restructure portlib module - please add some more reasoning?
Actually Andrey Chernyshev already stated the case in this thread about 8
hours ago. Since its nicely articulated, I won't repeat. Maybe you can ask
questions about Andrey's statement?
I am just now starting to look at threading design of DRLVM. What I see is
a rather large number of threading APIs that are adding confusion. There is
portlib/hythread/hyxxxx, Apache Portable Runtime in addition to windowsxp
and posix/linux. I have heard that VMI is in the mix somewhere. I just
haven't stumbled on it yet.
>
> >
> >
> > On 11/10/06, Andrey Chernyshev <a....@gmail.com> wrote:
> > >
> > > On 10/26/06, Angela Lin <al...@gmail.com> wrote:
> > > > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > > >
> > > > > If an arbitrary commercial JVM decided to use classlib, will it
> need
> > > to be
> > > > > modified to reflect the existing Harmony Classlib threading model?
> > > >
> > > > This is the case no matter how you split the thread library.
> Whatever
> > > > interface you specify for the classlib will need to be supported by
> > > > the VM.
> > > >
> > > > > Also, does this mean VM design is constrained by classlib
> design? And
> > > > > classlib design is constrained by J9 design?
> > > >
> > > > The classlib and the VM have certain dependencies on each other.
> This
> > > > is not a J9-specific issue.
> > > >
> > > > I would aim for a thread API that is generic enough to support
> > > > multiple implementations.
> > >
> > > I think it may be hard (if possible at all) to create high-level
> > > threading library which would make just every VM happy. For instance,
> > > DRLVM has a complex synchronization scheme with garbage collector
> > > which is built into the threading library (for example, each time
> > > thread goes into wait state, it must instruct the GC that the thread
> > > can be garbage collected). There also could be VM-specific
> > > optimizations for monitors which are tied to the object layout used in
> > > a particular VM.
> > >
> > > Finally, there might be pure-Java written VM's which may choose to
> > > implement threading library almost entirely in Java (may be on top of
> > > j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
> > > may be sort of fork operations from the native code. How could we have
> > > a threading library which will work equally for all VM's?
> > >
> > > I agree that bypassing layer (2) by the classlib can be undesirable
> > > because of loosing track for thread/lock states. So it seems that:
> > > - both VM and classlib need to use single thread library, and at the
> > > same level (or, saying that differently, Java code and native code
> > > from classlib should use same threading lib);
> > > - threading lib is likely be VM-specific (consider DRLVM as an
> example)
> > >
> > > If we agree with the above, doesn't it just mean that the hythr must
> > > be declared as a part of VM? Classlib may probably continue to keep a
> > > "stub" library for the compilation purposes. But there must be the
> > > possibility for other VM's to easily replace it with it's own version.
> > > I guess we do something similar with the luni-kernel-stubs.jar.
> > >
> > > >
> > > > Mature VMs that switch to the Harmony classlib would probably
> > > > implement a portability layer between the existing VM's thread model
> > > > and the Harmony thread API.
> > >
> > > I guess mature VM's would likely to have their own very carefully
> > > written and optimized threading libraries, integrated with GC, JIT
> > > e.t.c. It will be easier for them to provide a suitable interface for
> > > classlib rather than rewrite VM on top of hythread, no matter how
> > > perfect is it.
> > >
> > >
> > > >
> > > > Has anyone considered how ThreadMXBean would be supported by the
> > > > proposed classlib thread API subset?
> > >
> > > May be ThreadMXBean is just a good candidate for the kernel class set?
> > > At least the spec says "interface for the thread system of the Java
> > > virtual machine". I guess other MXBeans are also interfaces to some of
> > > VM services.
> > >
> > >
> > > Thanks,
> > > Andrey.
> > >
> > >
> > > >
> > > > > On 10/24/06, Angela Lin <al...@gmail.com> wrote:
> > > > > >
> > > > > > Consider the group of monitor-related functionality: enter/exit,
> > > > > > wait/notify, and interrupt. The implementations of these
> functions
> > > are
> > > > > > closely related in the J9-derived hythread, particularly for
> 3-tier
> > > > > > locking. We need to coordinate when we lock the thread mutex,
> when
> > > we
> > > > > > lock the monitor mutex, how we use spinlocks, etc. It would be
> > > > > > unnatural to split out enter/exit from this group.
> > > > >
> > > > >
> > > > > >
> > > > > > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > > > > > On 10/23/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > What is the goal here?
> > > > > > > >
> > > > > > > > 1. If the goal is to create a single thread library that can
> be
> > > used
> > > > > > > > by multiple VM and classlib implementations, then the
> unified
> > > thread
> > > > > > > > lib should contain everything needed to support a VM
> > > implementation.
> > > > > > > >
> > > > > > > > 2. If the goal is to simply define the interface between the
> > > classlib
> > > > > > > > and the VM, then the 3rd option may be acceptable. This
> option
> > > seems
> > > > > > > > to imply splitting up functionality that requires deep
> knowledge
> > > of
> > > > > > > > the threading implementation, which I don't like. Each VM
> > > > > > > > implementation would need to implement both the VM and
> classlib
> > > sides
> > > > > > > > of the API.
> > > > > > >
> > > > > > > Is this really the situation? If Classlib only needs
> > > monenter/exit, TLS
> > > > > > and
> > > > > > > thread_create(), the "deep knowledge" required is probably
> only
> > > > > > > monitorenter/exit which seems like a managable situation.
> > > > > > >
> > > > > > >
> > > > > > > Regards,
> > > > > > > > Angela
> > > > > > > >
> > > > > > > > On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > > > > Angela, all,
> > > > > > > > >
> > > > > > > > > I see you point and agree.
> > > > > > > > > But if we move hythread lib to the VM we will require all
> VMs
> > > fully
> > > > > > > > support it.
> > > > > > > > > Is it necessary dependency?
> > > > > > > > >
> > > > > > > > > So Here is the third way I see.
> > > > > > > > > Leave the minimum implementation of hythread in the
> classlib,
> > > with
> > > > > > the
> > > > > > > > > set of functions any VM should provide for classlib.
> > > > > > > > > This will simplifies adopting classlib to new VM and
> allows
> > > to
> > > > > > have
> > > > > > > > > solid threading model.
> > > > > > > > > So any VM could have its own super set of threading
> functions.
> > > > > > > > >
> > > > > > > > > Note: Classlib uses only monitor, TLS, and thread_create()
> > > from
> > > > > > > > hythread.
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Artem
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > > > > > Artem et al,
> > > > > > > > > >
> > > > > > > > > > Sorry for jumping in late here.
> > > > > > > > > >
> > > > > > > > > > I maintain the J9VM thread lib.
> > > > > > > > > >
> > > > > > > > > > Option 1 worries me because it implies that the classlib
> > > could use
> > > > > > a
> > > > > > > > > > different threading model from the VM. This is bad
> because
> > > they
> > > > > > both
> > > > > > > > > > operate on the same threads.
> > > > > > > > > >
> > > > > > > > > > For example: Layer (2) of hythread might include
> internal
> > > thread
> > > > > > state
> > > > > > > > > > tracking, which is needed to support inspecting the
> thread
> > > state.
> > > > > > > > > > Using layer (1) directly would bypass the thread state
> > > tracking.
> > > > > > > > > >
> > > > > > > > > > Angela
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Weldon Washburn
> > > > > Intel Middleware Products Division
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Andrey Chernyshev
> > > Intel Enterprise Solutions Software Division
> > >
> >
> >
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
> >
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by Andrey Chernyshev <a....@gmail.com>.
On 11/10/06, Weldon Washburn <we...@gmail.com> wrote:
> hmm.... it seems that we need to create "kernel natives", the C version
> of java kernel classes. The expectation is that the JVM supplier would
> write their own kernel natives. And the classlib native code would only
> call kernel natives. Thoughts?
This would be an interesting design choice, but not how it works right now.
The problem with this approach could be that, each VM, while
preserving the standard Java interface for kernel class libraries
(which is governed by J2SE spec), may choose to have a different
interface for kernel natives. Relationship between the kernel Java
classes and native VM code may be very different. (As a corner case,
consider VM that has a little or no native code for kernel classes).
Therefore, it might be difficult to standardize such "native"
interface to kernel's classes native code.
Classlib, in addition to the kernel classes set, is currently using
VMI interface to access some of native VM services (such as getting
the portlib). The problem could be that, classlib (for ex, see
zipsup.c in achieve module) is using hythread services bypassing that
interface.
Hythread is currently used directly by the classlib, portlib and VM
code. If we think this has to be the high level threading library
(which would export exactly the same sync objects as the ones used for
Java monitors) provided by VM, then may be it makes sense to export
hythread to the classlib's code using VMI interface just like we do
this for the HyPortLibrary (see
luni/src/main/native/include/shared/vmi.h)?
Thanks,
Andrey.
>
>
>
>
> On 11/10/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >
> > On 10/26/06, Angela Lin <al...@gmail.com> wrote:
> > > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > >
> > > > If an arbitrary commercial JVM decided to use classlib, will it need
> > to be
> > > > modified to reflect the existing Harmony Classlib threading model?
> > >
> > > This is the case no matter how you split the thread library. Whatever
> > > interface you specify for the classlib will need to be supported by
> > > the VM.
> > >
> > > > Also, does this mean VM design is constrained by classlib design? And
> > > > classlib design is constrained by J9 design?
> > >
> > > The classlib and the VM have certain dependencies on each other. This
> > > is not a J9-specific issue.
> > >
> > > I would aim for a thread API that is generic enough to support
> > > multiple implementations.
> >
> > I think it may be hard (if possible at all) to create high-level
> > threading library which would make just every VM happy. For instance,
> > DRLVM has a complex synchronization scheme with garbage collector
> > which is built into the threading library (for example, each time
> > thread goes into wait state, it must instruct the GC that the thread
> > can be garbage collected). There also could be VM-specific
> > optimizations for monitors which are tied to the object layout used in
> > a particular VM.
> >
> > Finally, there might be pure-Java written VM's which may choose to
> > implement threading library almost entirely in Java (may be on top of
> > j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
> > may be sort of fork operations from the native code. How could we have
> > a threading library which will work equally for all VM's?
> >
> > I agree that bypassing layer (2) by the classlib can be undesirable
> > because of loosing track for thread/lock states. So it seems that:
> > - both VM and classlib need to use single thread library, and at the
> > same level (or, saying that differently, Java code and native code
> > from classlib should use same threading lib);
> > - threading lib is likely be VM-specific (consider DRLVM as an example)
> >
> > If we agree with the above, doesn't it just mean that the hythr must
> > be declared as a part of VM? Classlib may probably continue to keep a
> > "stub" library for the compilation purposes. But there must be the
> > possibility for other VM's to easily replace it with it's own version.
> > I guess we do something similar with the luni-kernel-stubs.jar.
> >
> > >
> > > Mature VMs that switch to the Harmony classlib would probably
> > > implement a portability layer between the existing VM's thread model
> > > and the Harmony thread API.
> >
> > I guess mature VM's would likely to have their own very carefully
> > written and optimized threading libraries, integrated with GC, JIT
> > e.t.c. It will be easier for them to provide a suitable interface for
> > classlib rather than rewrite VM on top of hythread, no matter how
> > perfect is it.
> >
> >
> > >
> > > Has anyone considered how ThreadMXBean would be supported by the
> > > proposed classlib thread API subset?
> >
> > May be ThreadMXBean is just a good candidate for the kernel class set?
> > At least the spec says "interface for the thread system of the Java
> > virtual machine". I guess other MXBeans are also interfaces to some of
> > VM services.
> >
> >
> > Thanks,
> > Andrey.
> >
> >
> > >
> > > > On 10/24/06, Angela Lin <al...@gmail.com> wrote:
> > > > >
> > > > > Consider the group of monitor-related functionality: enter/exit,
> > > > > wait/notify, and interrupt. The implementations of these functions
> > are
> > > > > closely related in the J9-derived hythread, particularly for 3-tier
> > > > > locking. We need to coordinate when we lock the thread mutex, when
> > we
> > > > > lock the monitor mutex, how we use spinlocks, etc. It would be
> > > > > unnatural to split out enter/exit from this group.
> > > >
> > > >
> > > > >
> > > > > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > > > > On 10/23/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > >
> > > > > > > What is the goal here?
> > > > > > >
> > > > > > > 1. If the goal is to create a single thread library that can be
> > used
> > > > > > > by multiple VM and classlib implementations, then the unified
> > thread
> > > > > > > lib should contain everything needed to support a VM
> > implementation.
> > > > > > >
> > > > > > > 2. If the goal is to simply define the interface between the
> > classlib
> > > > > > > and the VM, then the 3rd option may be acceptable. This option
> > seems
> > > > > > > to imply splitting up functionality that requires deep knowledge
> > of
> > > > > > > the threading implementation, which I don't like. Each VM
> > > > > > > implementation would need to implement both the VM and classlib
> > sides
> > > > > > > of the API.
> > > > > >
> > > > > > Is this really the situation? If Classlib only needs
> > monenter/exit, TLS
> > > > > and
> > > > > > thread_create(), the "deep knowledge" required is probably only
> > > > > > monitorenter/exit which seems like a managable situation.
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > > Angela
> > > > > > >
> > > > > > > On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > > > Angela, all,
> > > > > > > >
> > > > > > > > I see you point and agree.
> > > > > > > > But if we move hythread lib to the VM we will require all VMs
> > fully
> > > > > > > support it.
> > > > > > > > Is it necessary dependency?
> > > > > > > >
> > > > > > > > So Here is the third way I see.
> > > > > > > > Leave the minimum implementation of hythread in the classlib,
> > with
> > > > > the
> > > > > > > > set of functions any VM should provide for classlib.
> > > > > > > > This will simplifies adopting classlib to new VM and allows
> > to
> > > > > have
> > > > > > > > solid threading model.
> > > > > > > > So any VM could have its own super set of threading functions.
> > > > > > > >
> > > > > > > > Note: Classlib uses only monitor, TLS, and thread_create()
> > from
> > > > > > > hythread.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Artem
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > > > > Artem et al,
> > > > > > > > >
> > > > > > > > > Sorry for jumping in late here.
> > > > > > > > >
> > > > > > > > > I maintain the J9VM thread lib.
> > > > > > > > >
> > > > > > > > > Option 1 worries me because it implies that the classlib
> > could use
> > > > > a
> > > > > > > > > different threading model from the VM. This is bad because
> > they
> > > > > both
> > > > > > > > > operate on the same threads.
> > > > > > > > >
> > > > > > > > > For example: Layer (2) of hythread might include internal
> > thread
> > > > > state
> > > > > > > > > tracking, which is needed to support inspecting the thread
> > state.
> > > > > > > > > Using layer (1) directly would bypass the thread state
> > tracking.
> > > > > > > > >
> > > > > > > > > Angela
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Weldon Washburn
> > > > Intel Middleware Products Division
> > > >
> > > >
> > >
> >
> >
> > --
> > Andrey Chernyshev
> > Intel Enterprise Solutions Software Division
> >
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
--
Andrey Chernyshev
Intel Enterprise Solutions Software Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by Alexey Varlamov <al...@gmail.com>.
2006/11/10, Weldon Washburn <we...@gmail.com>:
> hmm.... it seems that we need to create "kernel natives", the C version
> of java kernel classes. The expectation is that the JVM supplier would
> write their own kernel natives. And the classlib native code would only
> call kernel natives. Thoughts?
I don't understand this. We already have VMI (for common purposes),
and even if hythread shed implementation, it preserves functioning as
interface to threading nevertheless. If this means we should somehow
restructure portlib module - please add some more reasoning?
>
>
>
> On 11/10/06, Andrey Chernyshev <a....@gmail.com> wrote:
> >
> > On 10/26/06, Angela Lin <al...@gmail.com> wrote:
> > > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > >
> > > > If an arbitrary commercial JVM decided to use classlib, will it need
> > to be
> > > > modified to reflect the existing Harmony Classlib threading model?
> > >
> > > This is the case no matter how you split the thread library. Whatever
> > > interface you specify for the classlib will need to be supported by
> > > the VM.
> > >
> > > > Also, does this mean VM design is constrained by classlib design? And
> > > > classlib design is constrained by J9 design?
> > >
> > > The classlib and the VM have certain dependencies on each other. This
> > > is not a J9-specific issue.
> > >
> > > I would aim for a thread API that is generic enough to support
> > > multiple implementations.
> >
> > I think it may be hard (if possible at all) to create high-level
> > threading library which would make just every VM happy. For instance,
> > DRLVM has a complex synchronization scheme with garbage collector
> > which is built into the threading library (for example, each time
> > thread goes into wait state, it must instruct the GC that the thread
> > can be garbage collected). There also could be VM-specific
> > optimizations for monitors which are tied to the object layout used in
> > a particular VM.
> >
> > Finally, there might be pure-Java written VM's which may choose to
> > implement threading library almost entirely in Java (may be on top of
> > j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
> > may be sort of fork operations from the native code. How could we have
> > a threading library which will work equally for all VM's?
> >
> > I agree that bypassing layer (2) by the classlib can be undesirable
> > because of loosing track for thread/lock states. So it seems that:
> > - both VM and classlib need to use single thread library, and at the
> > same level (or, saying that differently, Java code and native code
> > from classlib should use same threading lib);
> > - threading lib is likely be VM-specific (consider DRLVM as an example)
> >
> > If we agree with the above, doesn't it just mean that the hythr must
> > be declared as a part of VM? Classlib may probably continue to keep a
> > "stub" library for the compilation purposes. But there must be the
> > possibility for other VM's to easily replace it with it's own version.
> > I guess we do something similar with the luni-kernel-stubs.jar.
> >
> > >
> > > Mature VMs that switch to the Harmony classlib would probably
> > > implement a portability layer between the existing VM's thread model
> > > and the Harmony thread API.
> >
> > I guess mature VM's would likely to have their own very carefully
> > written and optimized threading libraries, integrated with GC, JIT
> > e.t.c. It will be easier for them to provide a suitable interface for
> > classlib rather than rewrite VM on top of hythread, no matter how
> > perfect is it.
> >
> >
> > >
> > > Has anyone considered how ThreadMXBean would be supported by the
> > > proposed classlib thread API subset?
> >
> > May be ThreadMXBean is just a good candidate for the kernel class set?
> > At least the spec says "interface for the thread system of the Java
> > virtual machine". I guess other MXBeans are also interfaces to some of
> > VM services.
> >
> >
> > Thanks,
> > Andrey.
> >
> >
> > >
> > > > On 10/24/06, Angela Lin <al...@gmail.com> wrote:
> > > > >
> > > > > Consider the group of monitor-related functionality: enter/exit,
> > > > > wait/notify, and interrupt. The implementations of these functions
> > are
> > > > > closely related in the J9-derived hythread, particularly for 3-tier
> > > > > locking. We need to coordinate when we lock the thread mutex, when
> > we
> > > > > lock the monitor mutex, how we use spinlocks, etc. It would be
> > > > > unnatural to split out enter/exit from this group.
> > > >
> > > >
> > > > >
> > > > > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > > > > On 10/23/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > >
> > > > > > > What is the goal here?
> > > > > > >
> > > > > > > 1. If the goal is to create a single thread library that can be
> > used
> > > > > > > by multiple VM and classlib implementations, then the unified
> > thread
> > > > > > > lib should contain everything needed to support a VM
> > implementation.
> > > > > > >
> > > > > > > 2. If the goal is to simply define the interface between the
> > classlib
> > > > > > > and the VM, then the 3rd option may be acceptable. This option
> > seems
> > > > > > > to imply splitting up functionality that requires deep knowledge
> > of
> > > > > > > the threading implementation, which I don't like. Each VM
> > > > > > > implementation would need to implement both the VM and classlib
> > sides
> > > > > > > of the API.
> > > > > >
> > > > > > Is this really the situation? If Classlib only needs
> > monenter/exit, TLS
> > > > > and
> > > > > > thread_create(), the "deep knowledge" required is probably only
> > > > > > monitorenter/exit which seems like a managable situation.
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > > Angela
> > > > > > >
> > > > > > > On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > > > Angela, all,
> > > > > > > >
> > > > > > > > I see you point and agree.
> > > > > > > > But if we move hythread lib to the VM we will require all VMs
> > fully
> > > > > > > support it.
> > > > > > > > Is it necessary dependency?
> > > > > > > >
> > > > > > > > So Here is the third way I see.
> > > > > > > > Leave the minimum implementation of hythread in the classlib,
> > with
> > > > > the
> > > > > > > > set of functions any VM should provide for classlib.
> > > > > > > > This will simplifies adopting classlib to new VM and allows
> > to
> > > > > have
> > > > > > > > solid threading model.
> > > > > > > > So any VM could have its own super set of threading functions.
> > > > > > > >
> > > > > > > > Note: Classlib uses only monitor, TLS, and thread_create()
> > from
> > > > > > > hythread.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Artem
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > > > > Artem et al,
> > > > > > > > >
> > > > > > > > > Sorry for jumping in late here.
> > > > > > > > >
> > > > > > > > > I maintain the J9VM thread lib.
> > > > > > > > >
> > > > > > > > > Option 1 worries me because it implies that the classlib
> > could use
> > > > > a
> > > > > > > > > different threading model from the VM. This is bad because
> > they
> > > > > both
> > > > > > > > > operate on the same threads.
> > > > > > > > >
> > > > > > > > > For example: Layer (2) of hythread might include internal
> > thread
> > > > > state
> > > > > > > > > tracking, which is needed to support inspecting the thread
> > state.
> > > > > > > > > Using layer (1) directly would bypass the thread state
> > tracking.
> > > > > > > > >
> > > > > > > > > Angela
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Weldon Washburn
> > > > Intel Middleware Products Division
> > > >
> > > >
> > >
> >
> >
> > --
> > Andrey Chernyshev
> > Intel Enterprise Solutions Software Division
> >
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
Re: [drlvm][classlib] thread library - let there be one!
Posted by Weldon Washburn <we...@gmail.com>.
hmm.... it seems that we need to create "kernel natives", the C version
of java kernel classes. The expectation is that the JVM supplier would
write their own kernel natives. And the classlib native code would only
call kernel natives. Thoughts?
On 11/10/06, Andrey Chernyshev <a....@gmail.com> wrote:
>
> On 10/26/06, Angela Lin <al...@gmail.com> wrote:
> > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > >
> > > If an arbitrary commercial JVM decided to use classlib, will it need
> to be
> > > modified to reflect the existing Harmony Classlib threading model?
> >
> > This is the case no matter how you split the thread library. Whatever
> > interface you specify for the classlib will need to be supported by
> > the VM.
> >
> > > Also, does this mean VM design is constrained by classlib design? And
> > > classlib design is constrained by J9 design?
> >
> > The classlib and the VM have certain dependencies on each other. This
> > is not a J9-specific issue.
> >
> > I would aim for a thread API that is generic enough to support
> > multiple implementations.
>
> I think it may be hard (if possible at all) to create high-level
> threading library which would make just every VM happy. For instance,
> DRLVM has a complex synchronization scheme with garbage collector
> which is built into the threading library (for example, each time
> thread goes into wait state, it must instruct the GC that the thread
> can be garbage collected). There also could be VM-specific
> optimizations for monitors which are tied to the object layout used in
> a particular VM.
>
> Finally, there might be pure-Java written VM's which may choose to
> implement threading library almost entirely in Java (may be on top of
> j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
> may be sort of fork operations from the native code. How could we have
> a threading library which will work equally for all VM's?
>
> I agree that bypassing layer (2) by the classlib can be undesirable
> because of loosing track for thread/lock states. So it seems that:
> - both VM and classlib need to use single thread library, and at the
> same level (or, saying that differently, Java code and native code
> from classlib should use same threading lib);
> - threading lib is likely be VM-specific (consider DRLVM as an example)
>
> If we agree with the above, doesn't it just mean that the hythr must
> be declared as a part of VM? Classlib may probably continue to keep a
> "stub" library for the compilation purposes. But there must be the
> possibility for other VM's to easily replace it with it's own version.
> I guess we do something similar with the luni-kernel-stubs.jar.
>
> >
> > Mature VMs that switch to the Harmony classlib would probably
> > implement a portability layer between the existing VM's thread model
> > and the Harmony thread API.
>
> I guess mature VM's would likely to have their own very carefully
> written and optimized threading libraries, integrated with GC, JIT
> e.t.c. It will be easier for them to provide a suitable interface for
> classlib rather than rewrite VM on top of hythread, no matter how
> perfect is it.
>
>
> >
> > Has anyone considered how ThreadMXBean would be supported by the
> > proposed classlib thread API subset?
>
> May be ThreadMXBean is just a good candidate for the kernel class set?
> At least the spec says "interface for the thread system of the Java
> virtual machine". I guess other MXBeans are also interfaces to some of
> VM services.
>
>
> Thanks,
> Andrey.
>
>
> >
> > > On 10/24/06, Angela Lin <al...@gmail.com> wrote:
> > > >
> > > > Consider the group of monitor-related functionality: enter/exit,
> > > > wait/notify, and interrupt. The implementations of these functions
> are
> > > > closely related in the J9-derived hythread, particularly for 3-tier
> > > > locking. We need to coordinate when we lock the thread mutex, when
> we
> > > > lock the monitor mutex, how we use spinlocks, etc. It would be
> > > > unnatural to split out enter/exit from this group.
> > >
> > >
> > > >
> > > > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > > > On 10/23/06, Angela Lin <al...@gmail.com> wrote:
> > > > > >
> > > > > > What is the goal here?
> > > > > >
> > > > > > 1. If the goal is to create a single thread library that can be
> used
> > > > > > by multiple VM and classlib implementations, then the unified
> thread
> > > > > > lib should contain everything needed to support a VM
> implementation.
> > > > > >
> > > > > > 2. If the goal is to simply define the interface between the
> classlib
> > > > > > and the VM, then the 3rd option may be acceptable. This option
> seems
> > > > > > to imply splitting up functionality that requires deep knowledge
> of
> > > > > > the threading implementation, which I don't like. Each VM
> > > > > > implementation would need to implement both the VM and classlib
> sides
> > > > > > of the API.
> > > > >
> > > > > Is this really the situation? If Classlib only needs
> monenter/exit, TLS
> > > > and
> > > > > thread_create(), the "deep knowledge" required is probably only
> > > > > monitorenter/exit which seems like a managable situation.
> > > > >
> > > > >
> > > > > Regards,
> > > > > > Angela
> > > > > >
> > > > > > On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > > Angela, all,
> > > > > > >
> > > > > > > I see you point and agree.
> > > > > > > But if we move hythread lib to the VM we will require all VMs
> fully
> > > > > > support it.
> > > > > > > Is it necessary dependency?
> > > > > > >
> > > > > > > So Here is the third way I see.
> > > > > > > Leave the minimum implementation of hythread in the classlib,
> with
> > > > the
> > > > > > > set of functions any VM should provide for classlib.
> > > > > > > This will simplifies adopting classlib to new VM and allows
> to
> > > > have
> > > > > > > solid threading model.
> > > > > > > So any VM could have its own super set of threading functions.
> > > > > > >
> > > > > > > Note: Classlib uses only monitor, TLS, and thread_create()
> from
> > > > > > hythread.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Artem
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > > > Artem et al,
> > > > > > > >
> > > > > > > > Sorry for jumping in late here.
> > > > > > > >
> > > > > > > > I maintain the J9VM thread lib.
> > > > > > > >
> > > > > > > > Option 1 worries me because it implies that the classlib
> could use
> > > > a
> > > > > > > > different threading model from the VM. This is bad because
> they
> > > > both
> > > > > > > > operate on the same threads.
> > > > > > > >
> > > > > > > > For example: Layer (2) of hythread might include internal
> thread
> > > > state
> > > > > > > > tracking, which is needed to support inspecting the thread
> state.
> > > > > > > > Using layer (1) directly would bypass the thread state
> tracking.
> > > > > > > >
> > > > > > > > Angela
> > > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Weldon Washburn
> > > Intel Middleware Products Division
> > >
> > >
> >
>
>
> --
> Andrey Chernyshev
> Intel Enterprise Solutions Software Division
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by Andrey Chernyshev <a....@gmail.com>.
On 10/26/06, Angela Lin <al...@gmail.com> wrote:
> On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > If an arbitrary commercial JVM decided to use classlib, will it need to be
> > modified to reflect the existing Harmony Classlib threading model?
>
> This is the case no matter how you split the thread library. Whatever
> interface you specify for the classlib will need to be supported by
> the VM.
>
> > Also, does this mean VM design is constrained by classlib design? And
> > classlib design is constrained by J9 design?
>
> The classlib and the VM have certain dependencies on each other. This
> is not a J9-specific issue.
>
> I would aim for a thread API that is generic enough to support
> multiple implementations.
I think it may be hard (if possible at all) to create high-level
threading library which would make just every VM happy. For instance,
DRLVM has a complex synchronization scheme with garbage collector
which is built into the threading library (for example, each time
thread goes into wait state, it must instruct the GC that the thread
can be garbage collected). There also could be VM-specific
optimizations for monitors which are tied to the object layout used in
a particular VM.
Finally, there might be pure-Java written VM's which may choose to
implement threading library almost entirely in Java (may be on top of
j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
may be sort of fork operations from the native code. How could we have
a threading library which will work equally for all VM's?
I agree that bypassing layer (2) by the classlib can be undesirable
because of loosing track for thread/lock states. So it seems that:
- both VM and classlib need to use single thread library, and at the
same level (or, saying that differently, Java code and native code
from classlib should use same threading lib);
- threading lib is likely be VM-specific (consider DRLVM as an example)
If we agree with the above, doesn't it just mean that the hythr must
be declared as a part of VM? Classlib may probably continue to keep a
"stub" library for the compilation purposes. But there must be the
possibility for other VM's to easily replace it with it's own version.
I guess we do something similar with the luni-kernel-stubs.jar.
>
> Mature VMs that switch to the Harmony classlib would probably
> implement a portability layer between the existing VM's thread model
> and the Harmony thread API.
I guess mature VM's would likely to have their own very carefully
written and optimized threading libraries, integrated with GC, JIT
e.t.c. It will be easier for them to provide a suitable interface for
classlib rather than rewrite VM on top of hythread, no matter how
perfect is it.
>
> Has anyone considered how ThreadMXBean would be supported by the
> proposed classlib thread API subset?
May be ThreadMXBean is just a good candidate for the kernel class set?
At least the spec says "interface for the thread system of the Java
virtual machine". I guess other MXBeans are also interfaces to some of
VM services.
Thanks,
Andrey.
>
> > On 10/24/06, Angela Lin <al...@gmail.com> wrote:
> > >
> > > Consider the group of monitor-related functionality: enter/exit,
> > > wait/notify, and interrupt. The implementations of these functions are
> > > closely related in the J9-derived hythread, particularly for 3-tier
> > > locking. We need to coordinate when we lock the thread mutex, when we
> > > lock the monitor mutex, how we use spinlocks, etc. It would be
> > > unnatural to split out enter/exit from this group.
> >
> >
> > >
> > > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > > On 10/23/06, Angela Lin <al...@gmail.com> wrote:
> > > > >
> > > > > What is the goal here?
> > > > >
> > > > > 1. If the goal is to create a single thread library that can be used
> > > > > by multiple VM and classlib implementations, then the unified thread
> > > > > lib should contain everything needed to support a VM implementation.
> > > > >
> > > > > 2. If the goal is to simply define the interface between the classlib
> > > > > and the VM, then the 3rd option may be acceptable. This option seems
> > > > > to imply splitting up functionality that requires deep knowledge of
> > > > > the threading implementation, which I don't like. Each VM
> > > > > implementation would need to implement both the VM and classlib sides
> > > > > of the API.
> > > >
> > > > Is this really the situation? If Classlib only needs monenter/exit, TLS
> > > and
> > > > thread_create(), the "deep knowledge" required is probably only
> > > > monitorenter/exit which seems like a managable situation.
> > > >
> > > >
> > > > Regards,
> > > > > Angela
> > > > >
> > > > > On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > > Angela, all,
> > > > > >
> > > > > > I see you point and agree.
> > > > > > But if we move hythread lib to the VM we will require all VMs fully
> > > > > support it.
> > > > > > Is it necessary dependency?
> > > > > >
> > > > > > So Here is the third way I see.
> > > > > > Leave the minimum implementation of hythread in the classlib, with
> > > the
> > > > > > set of functions any VM should provide for classlib.
> > > > > > This will simplifies adopting classlib to new VM and allows to
> > > have
> > > > > > solid threading model.
> > > > > > So any VM could have its own super set of threading functions.
> > > > > >
> > > > > > Note: Classlib uses only monitor, TLS, and thread_create() from
> > > > > hythread.
> > > > > >
> > > > > > Thanks
> > > > > > Artem
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > > Artem et al,
> > > > > > >
> > > > > > > Sorry for jumping in late here.
> > > > > > >
> > > > > > > I maintain the J9VM thread lib.
> > > > > > >
> > > > > > > Option 1 worries me because it implies that the classlib could use
> > > a
> > > > > > > different threading model from the VM. This is bad because they
> > > both
> > > > > > > operate on the same threads.
> > > > > > >
> > > > > > > For example: Layer (2) of hythread might include internal thread
> > > state
> > > > > > > tracking, which is needed to support inspecting the thread state.
> > > > > > > Using layer (1) directly would bypass the thread state tracking.
> > > > > > >
> > > > > > > Angela
> > > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Weldon Washburn
> > Intel Middleware Products Division
> >
> >
>
--
Andrey Chernyshev
Intel Enterprise Solutions Software Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by Angela Lin <al...@gmail.com>.
On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
>
> If an arbitrary commercial JVM decided to use classlib, will it need to be
> modified to reflect the existing Harmony Classlib threading model?
This is the case no matter how you split the thread library. Whatever
interface you specify for the classlib will need to be supported by
the VM.
> Also, does this mean VM design is constrained by classlib design? And
> classlib design is constrained by J9 design?
The classlib and the VM have certain dependencies on each other. This
is not a J9-specific issue.
I would aim for a thread API that is generic enough to support
multiple implementations.
Mature VMs that switch to the Harmony classlib would probably
implement a portability layer between the existing VM's thread model
and the Harmony thread API.
Has anyone considered how ThreadMXBean would be supported by the
proposed classlib thread API subset?
> On 10/24/06, Angela Lin <al...@gmail.com> wrote:
> >
> > Consider the group of monitor-related functionality: enter/exit,
> > wait/notify, and interrupt. The implementations of these functions are
> > closely related in the J9-derived hythread, particularly for 3-tier
> > locking. We need to coordinate when we lock the thread mutex, when we
> > lock the monitor mutex, how we use spinlocks, etc. It would be
> > unnatural to split out enter/exit from this group.
>
>
> >
> > On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > > On 10/23/06, Angela Lin <al...@gmail.com> wrote:
> > > >
> > > > What is the goal here?
> > > >
> > > > 1. If the goal is to create a single thread library that can be used
> > > > by multiple VM and classlib implementations, then the unified thread
> > > > lib should contain everything needed to support a VM implementation.
> > > >
> > > > 2. If the goal is to simply define the interface between the classlib
> > > > and the VM, then the 3rd option may be acceptable. This option seems
> > > > to imply splitting up functionality that requires deep knowledge of
> > > > the threading implementation, which I don't like. Each VM
> > > > implementation would need to implement both the VM and classlib sides
> > > > of the API.
> > >
> > > Is this really the situation? If Classlib only needs monenter/exit, TLS
> > and
> > > thread_create(), the "deep knowledge" required is probably only
> > > monitorenter/exit which seems like a managable situation.
> > >
> > >
> > > Regards,
> > > > Angela
> > > >
> > > > On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > > Angela, all,
> > > > >
> > > > > I see you point and agree.
> > > > > But if we move hythread lib to the VM we will require all VMs fully
> > > > support it.
> > > > > Is it necessary dependency?
> > > > >
> > > > > So Here is the third way I see.
> > > > > Leave the minimum implementation of hythread in the classlib, with
> > the
> > > > > set of functions any VM should provide for classlib.
> > > > > This will simplifies adopting classlib to new VM and allows to
> > have
> > > > > solid threading model.
> > > > > So any VM could have its own super set of threading functions.
> > > > >
> > > > > Note: Classlib uses only monitor, TLS, and thread_create() from
> > > > hythread.
> > > > >
> > > > > Thanks
> > > > > Artem
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > > > > Artem et al,
> > > > > >
> > > > > > Sorry for jumping in late here.
> > > > > >
> > > > > > I maintain the J9VM thread lib.
> > > > > >
> > > > > > Option 1 worries me because it implies that the classlib could use
> > a
> > > > > > different threading model from the VM. This is bad because they
> > both
> > > > > > operate on the same threads.
> > > > > >
> > > > > > For example: Layer (2) of hythread might include internal thread
> > state
> > > > > > tracking, which is needed to support inspecting the thread state.
> > > > > > Using layer (1) directly would bypass the thread state tracking.
> > > > > >
> > > > > > Angela
> > > > > >
> > > >
> > >
> > >
> >
>
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>
Re: [drlvm][classlib] thread library - let there be one!
Posted by Weldon Washburn <we...@gmail.com>.
On 10/24/06, Angela Lin <al...@gmail.com> wrote:
>
> Consider the group of monitor-related functionality: enter/exit,
> wait/notify, and interrupt. The implementations of these functions are
> closely related in the J9-derived hythread, particularly for 3-tier
> locking. We need to coordinate when we lock the thread mutex, when we
> lock the monitor mutex, how we use spinlocks, etc. It would be
> unnatural to split out enter/exit from this group.
If an arbitrary commercial JVM decided to use classlib, will it need to be
modified to reflect the existing Harmony Classlib threading model?
Also, does this mean VM design is constrained by classlib design? And
classlib design is constrained by J9 design?
Angela
>
> On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> > On 10/23/06, Angela Lin <al...@gmail.com> wrote:
> > >
> > > What is the goal here?
> > >
> > > 1. If the goal is to create a single thread library that can be used
> > > by multiple VM and classlib implementations, then the unified thread
> > > lib should contain everything needed to support a VM implementation.
> > >
> > > 2. If the goal is to simply define the interface between the classlib
> > > and the VM, then the 3rd option may be acceptable. This option seems
> > > to imply splitting up functionality that requires deep knowledge of
> > > the threading implementation, which I don't like. Each VM
> > > implementation would need to implement both the VM and classlib sides
> > > of the API.
> >
> > Is this really the situation? If Classlib only needs monenter/exit, TLS
> and
> > thread_create(), the "deep knowledge" required is probably only
> > monitorenter/exit which seems like a managable situation.
> >
> >
> > Regards,
> > > Angela
> > >
> > > On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > > > Angela, all,
> > > >
> > > > I see you point and agree.
> > > > But if we move hythread lib to the VM we will require all VMs fully
> > > support it.
> > > > Is it necessary dependency?
> > > >
> > > > So Here is the third way I see.
> > > > Leave the minimum implementation of hythread in the classlib, with
> the
> > > > set of functions any VM should provide for classlib.
> > > > This will simplifies adopting classlib to new VM and allows to
> have
> > > > solid threading model.
> > > > So any VM could have its own super set of threading functions.
> > > >
> > > > Note: Classlib uses only monitor, TLS, and thread_create() from
> > > hythread.
> > > >
> > > > Thanks
> > > > Artem
> > > >
> > > >
> > > >
> > > >
> > > > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > > > Artem et al,
> > > > >
> > > > > Sorry for jumping in late here.
> > > > >
> > > > > I maintain the J9VM thread lib.
> > > > >
> > > > > Option 1 worries me because it implies that the classlib could use
> a
> > > > > different threading model from the VM. This is bad because they
> both
> > > > > operate on the same threads.
> > > > >
> > > > > For example: Layer (2) of hythread might include internal thread
> state
> > > > > tracking, which is needed to support inspecting the thread state.
> > > > > Using layer (1) directly would bypass the thread state tracking.
> > > > >
> > > > > Angela
> > > > >
> > >
> >
> >
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by Angela Lin <al...@gmail.com>.
Consider the group of monitor-related functionality: enter/exit,
wait/notify, and interrupt. The implementations of these functions are
closely related in the J9-derived hythread, particularly for 3-tier
locking. We need to coordinate when we lock the thread mutex, when we
lock the monitor mutex, how we use spinlocks, etc. It would be
unnatural to split out enter/exit from this group.
Angela
On 10/24/06, Weldon Washburn <we...@gmail.com> wrote:
> On 10/23/06, Angela Lin <al...@gmail.com> wrote:
> >
> > What is the goal here?
> >
> > 1. If the goal is to create a single thread library that can be used
> > by multiple VM and classlib implementations, then the unified thread
> > lib should contain everything needed to support a VM implementation.
> >
> > 2. If the goal is to simply define the interface between the classlib
> > and the VM, then the 3rd option may be acceptable. This option seems
> > to imply splitting up functionality that requires deep knowledge of
> > the threading implementation, which I don't like. Each VM
> > implementation would need to implement both the VM and classlib sides
> > of the API.
>
> Is this really the situation? If Classlib only needs monenter/exit, TLS and
> thread_create(), the "deep knowledge" required is probably only
> monitorenter/exit which seems like a managable situation.
>
>
> Regards,
> > Angela
> >
> > On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > > Angela, all,
> > >
> > > I see you point and agree.
> > > But if we move hythread lib to the VM we will require all VMs fully
> > support it.
> > > Is it necessary dependency?
> > >
> > > So Here is the third way I see.
> > > Leave the minimum implementation of hythread in the classlib, with the
> > > set of functions any VM should provide for classlib.
> > > This will simplifies adopting classlib to new VM and allows to have
> > > solid threading model.
> > > So any VM could have its own super set of threading functions.
> > >
> > > Note: Classlib uses only monitor, TLS, and thread_create() from
> > hythread.
> > >
> > > Thanks
> > > Artem
> > >
> > >
> > >
> > >
> > > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > > Artem et al,
> > > >
> > > > Sorry for jumping in late here.
> > > >
> > > > I maintain the J9VM thread lib.
> > > >
> > > > Option 1 worries me because it implies that the classlib could use a
> > > > different threading model from the VM. This is bad because they both
> > > > operate on the same threads.
> > > >
> > > > For example: Layer (2) of hythread might include internal thread state
> > > > tracking, which is needed to support inspecting the thread state.
> > > > Using layer (1) directly would bypass the thread state tracking.
> > > >
> > > > Angela
> > > >
> >
>
>
Re: [drlvm][classlib] thread library - let there be one!
Posted by Weldon Washburn <we...@gmail.com>.
On 10/23/06, Angela Lin <al...@gmail.com> wrote:
>
> What is the goal here?
>
> 1. If the goal is to create a single thread library that can be used
> by multiple VM and classlib implementations, then the unified thread
> lib should contain everything needed to support a VM implementation.
>
> 2. If the goal is to simply define the interface between the classlib
> and the VM, then the 3rd option may be acceptable. This option seems
> to imply splitting up functionality that requires deep knowledge of
> the threading implementation, which I don't like. Each VM
> implementation would need to implement both the VM and classlib sides
> of the API.
Is this really the situation? If Classlib only needs monenter/exit, TLS and
thread_create(), the "deep knowledge" required is probably only
monitorenter/exit which seems like a managable situation.
Regards,
> Angela
>
> On 10/19/06, Artem Aliev <ar...@gmail.com> wrote:
> > Angela, all,
> >
> > I see you point and agree.
> > But if we move hythread lib to the VM we will require all VMs fully
> support it.
> > Is it necessary dependency?
> >
> > So Here is the third way I see.
> > Leave the minimum implementation of hythread in the classlib, with the
> > set of functions any VM should provide for classlib.
> > This will simplifies adopting classlib to new VM and allows to have
> > solid threading model.
> > So any VM could have its own super set of threading functions.
> >
> > Note: Classlib uses only monitor, TLS, and thread_create() from
> hythread.
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> > On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> > > Artem et al,
> > >
> > > Sorry for jumping in late here.
> > >
> > > I maintain the J9VM thread lib.
> > >
> > > Option 1 worries me because it implies that the classlib could use a
> > > different threading model from the VM. This is bad because they both
> > > operate on the same threads.
> > >
> > > For example: Layer (2) of hythread might include internal thread state
> > > tracking, which is needed to support inspecting the thread state.
> > > Using layer (1) directly would bypass the thread state tracking.
> > >
> > > Angela
> > >
>
Re: [drlvm][classlib] thread library - let there be one!
Posted by Artem Aliev <ar...@gmail.com>.
Angela, all,
I see you point and agree.
But if we move hythread lib to the VM we will require all VMs fully support it.
Is it necessary dependency?
So Here is the third way I see.
Leave the minimum implementation of hythread in the classlib, with the
set of functions any VM should provide for classlib.
This will simplifies adopting classlib to new VM and allows to have
solid threading model.
So any VM could have its own super set of threading functions.
Note: Classlib uses only monitor, TLS, and thread_create() from hythread.
Thanks
Artem
On 10/18/06, Angela Lin <al...@gmail.com> wrote:
> Artem et al,
>
> Sorry for jumping in late here.
>
> I maintain the J9VM thread lib.
>
> Option 1 worries me because it implies that the classlib could use a
> different threading model from the VM. This is bad because they both
> operate on the same threads.
>
> For example: Layer (2) of hythread might include internal thread state
> tracking, which is needed to support inspecting the thread state.
> Using layer (1) directly would bypass the thread state tracking.
>
> Angela
>
>
> On 10/16/06, Artem Aliev <ar...@gmail.com> wrote:
> > Tim,
> >
> > Reading through discussion, I find two option for the second step.
> > Let's discuss them.
> >
> > 1.
> > > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> > > upper layer (hythead_xxx)
> > > - migrate classlib code to the bottom layer (1) of hythread
> > Then move the rest of hythread to VM.
> >
> > In this case we will move all VM releated functionality out of a classlib.
> > The classlib will use tls, mutex and thread_create from *.h files.
> > VM will be free to implement threading in any way.
> >
> > 2. Move hythread out from the drlvm to a portlib.
> > In this case classlib will contains a lot of only VM releated code.
> > So we will meet the same problems with an new VM. But we will have
> > common place for all synchronization primitives and could control
> > them.
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> >
> > On 10/16/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >
> > >
> > > Tim Ellison wrote:
> > > > First step (moving out of luni) looks good to me.
> > > >
> > > > I'd like some more discussion around the second step (picking up drlvm
> > > > version) before you do a wholesale replacement.
> > >
> > > Yes please. Lets do small, reversible steps.
> > >
> > > geir
> > >
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > > Weldon Washburn wrote:
> > > >> Artem,
> > > >> Thanks. I will take a look.
> > > >>
> > > >>
> > > >> On 10/12/06, Artem Aliev <ar...@gmail.com> wrote:
> > > >>> Guys,
> > > >>>
> > > >>>
> > > >>>> 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > > >>>> and move hyprt, hysig and hythread code into it. Update build to work
> > > >>>> with new directory.
> > > >>>>
> > > >>>>> [Andrey]- pull out hythread from classlib, make it a shared
> > > >>> component
> > > >>> The first step is done in JIRA HARMONY-1843.
> > > >>>
> > > >>> I move common, pool, port, thread, sig from luni to new component
> > > >>> portlib.
> > > >>> The first idea was to move only port, thread, sig, but they depend on
> > > >>> common and pool libs. It looks natural to do not produce cyclic
> > > >>> dependencies among components, so I move these two also to portlib.
> > > >>>
> > > >>> Unfortunately, this does not fully solve two stage luni building
> > > >>> process (build-native-core and build-native-secondary), but this is
> > > >>> another problem.
> > > >>>
> > > >>> So If we are still committed on these reorganization, please review
> > > >>> and apply the patch.
> > > >>>
> > > >>> A move_to_portlib.sh script create portlib directory structure and
> > > >>> move appropriate files from luni to portlib (by svn move).
> > > >>> A portlib_files.patch update build to works with new structure.
> > > >>>
> > > >>> Thanks
> > > >>> Artem
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > >>>> Guys,
> > > >>>>
> > > >>>> Let me try to make this changes.
> > > >>>>
> > > >>>> Here is my understanding of the steps I need to do.
> > > >>>>
> > > >>>> 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > > >>>> and move hyprt, hysig and hythread code into it. Update build to work
> > > >>>> with new directory.
> > > >>>>
> > > >>>>> [Andrey]- pull out hythread from classlib, make it a shared
> > > >>> component
> > > >>>> 2. Move DRLVM hythread to classlib and update drlvm build for it. So
> > > >>>> both classlib and drlvm will work on the drlvm hythread.
> > > >>>>
> > > >>>>> - split hythread, refine the bottom layer (thrdsup.h and mutex.h)
> > > >>> and
> > > >>>>> upper layer (hythead_xxx)
> > > >>>>> - migrate classlib code to the bottom layer (1) of hythread
> > > >>>> I do not think it is necessary because the hythread will be shared
> > > >>> library.
> > > >>>> This make sense only in case we move only layer(1) into the shared
> > > >>> directory.
> > > >>>> 3. merge hythreads into one library getting bast code from both
> > > >>> sources.
> > > >>>>> migrate DRLVM's thread manager to (1) from APR
> > > >>>> Will be done on this stage.
> > > >>>>
> > > >>>> 4. merge classlib and drlvm signal handling code.
> > > >>>>
> > > >>>> 5. merge port libs code.
> > > >>>>
> > > >>>> 6. ????
> > > >>>>
> > > >>>> Thanks
> > > >>>> Artem
> > > >>>>
> > > >>>> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >>>>> On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> > > >>>>>
> > > >>>>>> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >>>>>>> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> > > >>>>>>>
> > > >>>>>>>> +1 on the below.
> > > >>>>>>>>
> > > >>>>>>>> I am assuming Andrey and his team will do this work. (Andrey,
> > > >>> when
> > > >>>>>>>> will you
> > > >>>>>>>> start?)
> > > >>>>>>> We have to start first by pulling hythread out, but where? After
> > > >>>>>>> thinking about it for 5 more seconds, putting it on the top level
> > > >>>>>>>
> > > >>>>>>> enhanced/<something>
> > > >>>>>>>
> > > >>>>>>> is IMO a bad idea. There's nothing worse than going to a
> > > >>> project's
> > > >>>>>>> SVN and finding tons of confusing things.
> > > >>>>>> I agree making "thread" a standalone component at the level of
> > > >>>>>> enhanced/<something> probably isn't worth doing. What may make a
> > > >>> sense
> > > >>>>>> is to consider thread a part of the portlib and make the portlib a
> > > >>>>>> separate component at that level. Portlib is the only piece
> > > >>> which is
> > > >>>>>> shared between VM and classlib, this could justify it's appearance
> > > >>> at
> > > >>>>>> the high level.
> > > >>>>>>
> > > >>>>>>> Is there any downside to keeping it somewhere under
> > > >>> /classlib/trunk
> > > >>>>>> My only guess would be the inability to build VM independently from
> > > >>>>>> the classlib.
> > > >>>>> Sure, you'll still need either to build the /portlib or the /classlib
> > > >>>>>
> > > >>>>>>> and simply make it a module by itself?
> > > >>>>>> If we can not have a portlib as a high level component (like
> > > >>> classlib
> > > >>>>>> or drlvm), then at least having it as a separate module within
> > > >>>>>> classlib would be nice.
> > > >>>>> This is one of those things where doing the small step (do it in
> > > >>>>> classlib) and then consider the large step (do it as a peer) seems to
> > > >>>>> be reasonable, but i don't feel too strongly...
> > > >>>>>
> > > >>>>> geir
> > > >>>>>
> > > >>>>>> Thanks,
> > > >>>>>> Andrey.
> > > >>>>>>
> > > >>>>>>>> Hopefully we can clean up how drlvm handles the classlib portlib
> > > >>>>>>>> function
> > > >>>>>>>> table at the same time. Currently two versions of this table
> > > >>> are
> > > >>>>>>>> created
> > > >>>>>>>> during startup. "Portlib function table - let there be one!"
> > > >>>>>>>> Seriously,
> > > >>>>>>>> this is incredibly difficult code to maintain.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> > > >>>>>>>>> Yes, exactly.
> > > >>>>>>>>>
> > > >>>>>>>>> Regards,
> > > >>>>>>>>> Tim
> > > >>>>>>>>>
> > > >>>>>>>>> Andrey Chernyshev wrote:
> > > >>>>>>>>>> On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >>>>>>>>>>> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> Weldon, I agree with your comments and observations below.
> > > >>>>>>>>> Let's
> > > >>>>>>>>> take
> > > >>>>>>>>>>>> baby steps to get fully unified. I'm sure we all want to
> > > >>>>>>>>> keep things
> > > >>>>>>>>>>>> working throughout.
> > > >>>>>>>>>>> So what's the first stop? Move hythread as-is out of
> > > >>> classlib
> > > >>>>>>>>> to a
> > > >>>>>>>>>>> peer in the tree?
> > > >>>>>>>>>> I can suggest the following steps:
> > > >>>>>>>>>> - pull out hythread from classlib, make it a shared
> > > >>> component
> > > >>>>>>>>>> - split hythread, refine the bottom layer (thrdsup.h and
> > > >>>>>>>>> mutex.h) and
> > > >>>>>>>>>> upper layer (hythead_xxx)
> > > >>>>>>>>>> - migrate classlib code to the bottom layer (1) of hythread
> > > >>>>>>>>>> - migrate DRLVM's thread manager to (1) from APR
> > > >>>>>>>>>> Each step can be done without breaking the whole code stack.
> > > >>>>>>>>>> As a result, we'll have a bottom part of hythread which will
> > > >>> be
> > > >>>>>>>>> shared
> > > >>>>>>>>>> between the classlib and DRLVM.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Some additional steps could be:
> > > >>>>>>>>>> - pull the rest of the portlib out of the classlib, make
> > > >>> it a
> > > >>>>>>>>> shared
> > > >>>>>>>>>> component as well
> > > >>>>>>>>>> - migrate DRLVM to portlib
> > > >>>>>>>>>>
> > > >>>>>>>>>> Thanks,
> > > >>>>>>>>>> Andrey.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> geir
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> Regards,
> > > >>>>>>>>>>>> Tim
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Weldon Washburn wrote:
> > > >>>>>>>>>>>>> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> > > >>>>>>>>>>>>>> Artem Aliev wrote:
> > > >>>>>>>>>>>>>>> Gier,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> The hythread is just most visible example. There are
> > > >>> also
> > > >>>>>>>>> signal
> > > >>>>>>>>>>>>>>> handling problem. classlib hysig lib setup signal
> > > >>> handlers
> > > >>>>>>>>> and
> > > >>>>>>>>> then
> > > >>>>>>>>>>>>>>> drlvm overrides them by its owns. There are code
> > > >>>>>>>>> duplication in
> > > >>>>>>>>>>>>>>> classlib hyprt.dll drlvm port.lib:
> > > >>>>>>>>>>>>>>> classlib/trunk/modules/luni/src/main/native/port vm/
> > > >>>>>>> port/src
> > > >>>>>>>>>>>>>>> These three pair of components contains significant
> > > >>> part
> > > >>>>>>>>> of the
> > > >>>>>>>>>>>>>>> system dependent code for both VM and CLASSLIB. I
> > > >>> think,
> > > >>>>>>>>> all this
> > > >>>>>>>>>>>>>>> code naturally defines portlib component that could be
> > > >>>>>>> shared
> > > >>>>>>>>>>>>>>> between
> > > >>>>>>>>>>>>>>> classlib and VMs. So, as a first step, we could move
> > > >>>>>>> all this
> > > >>>>>>>>>>>>>>> code in
> > > >>>>>>>>>>>>>>> to the one place, name portlib to have three
> > > >>> directories
> > > >>>>>>>>> classlib,
> > > >>>>>>>>>>>>>>> drlvm, portlib.
> > > >>>>>>>>>>>>>> I think it is quite reasonable to call out the portlib
> > > >>> and
> > > >>>>>>>>> threadlib
> > > >>>>>>>>>>>>>> separate (in the repository) to the VM and classlib. As
> > > >>>>>>> you
> > > >>>>>>>>>>>>>> point out,
> > > >>>>>>>>>>>>>> then VM and classlib can share the code -- though it
> > > >>>>>>> will not
> > > >>>>>>>>>>>>>> become a
> > > >>>>>>>>>>>>>> requirement for VMs that run the harmony code to be
> > > >>> using
> > > >>>>>>>>> those
> > > >>>>>>>>>>>>>> libraries for their own implementation.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Tim,
> > > >>>>>>>>>>>>> One of the things to worry about is system-wide lock
> > > >>>>>>>>> protocol. We
> > > >>>>>>>>>>>>> will
> > > >>>>>>>>>>>>> need
> > > >>>>>>>>>>>>> to think through what locks portlib, threadlib and JVM
> > > >>> are
> > > >>>>>>>>> holding
> > > >>>>>>>>>>>>> and if
> > > >>>>>>>>>>>>> there are any deadlock possibilities.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Another issue is the implementation of signal chaining.
> > > >>>>>>> There
> > > >>>>>>>>>>>>> seems to be
> > > >>>>>>>>>>>>> code in hysignal.c that implement "-Xrs". I guess the
> > > >>> idea
> > > >>>>>>>>> is that
> > > >>>>>>>>> a
> > > >>>>>>>>>>>>> Harmony JVM would somehow not link this code and use its
> > > >>> own
> > > >>>>>>>>>>>>> implementation. The bottom line is that we probably need
> > > >>> to
> > > >>>>>>>>>>>>> carefully pick
> > > >>>>>>>>>>>>> through what is currently in classlib threads/signals and
> > > >>>>>>>>> rearrange
> > > >>>>>>>>>>>>> stuff so
> > > >>>>>>>>>>>>> that it reduces the confusion. We need to make this part
> > > >>> of
> > > >>>>>>>>> the
> > > >>>>>>>>>>>>> system
> > > >>>>>>>>>>>>> much
> > > >>>>>>>>>>>>> easier to work on.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Do you have recommendations on next steps? Does it make
> > > >>>>>>>>> sense to
> > > >>>>>>>>>>>>> start
> > > >>>>>>>>>>>>> moving stuff into the directories described above. Or is
> > > >>>>>>> more
> > > >>>>>>>>>>>>> discussion
> > > >>>>>>>>>>>>> needed.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> As the second step, the pairs of libraries should be
> > > >>> merged
> > > >>>>>>>>> and the
> > > >>>>>>>>>>>>>>> classlib and drlvm refactoried to have only 3 lib
> > > >>> instead
> > > >>>>>>>>> of 6.
> > > >>>>>>>>>>>>>> Yep, this would be part of the consolidation into new
> > > >>>>>>>>> Harmony top-
> > > >>>>>>>>>>>>>> level
> > > >>>>>>>>>>>>>> components. It makes sense that we share the same impl
> > > >>>>>>> in the
> > > >>>>>>>>>>>>>> project.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> The 3rd step is to replace most of the functions with
> > > >>> APR
> > > >>>>>>>>> ones and
> > > >>>>>>>>>>>>>>> move the rest of the code to the APR.
> > > >>>>>>>>>>>>>> I think it is quite well documented on this list that
> > > >>> this
> > > >>>>>>>>> should
> > > >>>>>>>>>>>>>> not be
> > > >>>>>>>>>>>>>> a goal.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I agree we don't need to move classlib to APR provided
> > > >>> that:
> > > >>>>>>>>>>>>> 1)
> > > >>>>>>>>>>>>> There is an easy to understand distinct seperation of the
> > > >>>>>>>>> different
> > > >>>>>>>>>>>>> threading/signals packages. In specific, we need to know
> > > >>>>>>> which
> > > >>>>>>>>>>>>> threading
> > > >>>>>>>>>>>>> package is being called by DRLVM without ambiguity.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 2)
> > > >>>>>>>>>>>>> There is clear understanding of how JVM and classlib
> > > >>>>>>> threading/
> > > >>>>>>>>>>>>> signals
> > > >>>>>>>>>>>>> interoperate.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Regards,
> > > >>>>>>>>>>>>>> Tim
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Thoughts?
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Thanks
> > > >>>>>>>>>>>>>>> Artem
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>> -------------------------------------------------------------------
> > > >>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> --
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> 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
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>> ---------------------------------------------------------------------
> > > >>>>>>>>>>> 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
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>>
> > > >>>>>>>>> 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
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> Weldon Washburn
> > > >>>>>>>> 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
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> 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
> > > >>>>>
> > > >>>>> ---------------------------------------------------------------------
> > > >>>>> 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
> > > >>>>>
> > > >>> ---------------------------------------------------------------------
> > > >>> 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
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Angela Lin <al...@gmail.com>.
Artem et al,
Sorry for jumping in late here.
I maintain the J9VM thread lib.
Option 1 worries me because it implies that the classlib could use a
different threading model from the VM. This is bad because they both
operate on the same threads.
For example: Layer (2) of hythread might include internal thread state
tracking, which is needed to support inspecting the thread state.
Using layer (1) directly would bypass the thread state tracking.
Angela
On 10/16/06, Artem Aliev <ar...@gmail.com> wrote:
> Tim,
>
> Reading through discussion, I find two option for the second step.
> Let's discuss them.
>
> 1.
> > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> > upper layer (hythead_xxx)
> > - migrate classlib code to the bottom layer (1) of hythread
> Then move the rest of hythread to VM.
>
> In this case we will move all VM releated functionality out of a classlib.
> The classlib will use tls, mutex and thread_create from *.h files.
> VM will be free to implement threading in any way.
>
> 2. Move hythread out from the drlvm to a portlib.
> In this case classlib will contains a lot of only VM releated code.
> So we will meet the same problems with an new VM. But we will have
> common place for all synchronization primitives and could control
> them.
>
> Thanks
> Artem
>
>
>
>
>
> On 10/16/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> >
> > Tim Ellison wrote:
> > > First step (moving out of luni) looks good to me.
> > >
> > > I'd like some more discussion around the second step (picking up drlvm
> > > version) before you do a wholesale replacement.
> >
> > Yes please. Lets do small, reversible steps.
> >
> > geir
> >
> > >
> > > Regards,
> > > Tim
> > >
> > > Weldon Washburn wrote:
> > >> Artem,
> > >> Thanks. I will take a look.
> > >>
> > >>
> > >> On 10/12/06, Artem Aliev <ar...@gmail.com> wrote:
> > >>> Guys,
> > >>>
> > >>>
> > >>>> 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > >>>> and move hyprt, hysig and hythread code into it. Update build to work
> > >>>> with new directory.
> > >>>>
> > >>>>> [Andrey]- pull out hythread from classlib, make it a shared
> > >>> component
> > >>> The first step is done in JIRA HARMONY-1843.
> > >>>
> > >>> I move common, pool, port, thread, sig from luni to new component
> > >>> portlib.
> > >>> The first idea was to move only port, thread, sig, but they depend on
> > >>> common and pool libs. It looks natural to do not produce cyclic
> > >>> dependencies among components, so I move these two also to portlib.
> > >>>
> > >>> Unfortunately, this does not fully solve two stage luni building
> > >>> process (build-native-core and build-native-secondary), but this is
> > >>> another problem.
> > >>>
> > >>> So If we are still committed on these reorganization, please review
> > >>> and apply the patch.
> > >>>
> > >>> A move_to_portlib.sh script create portlib directory structure and
> > >>> move appropriate files from luni to portlib (by svn move).
> > >>> A portlib_files.patch update build to works with new structure.
> > >>>
> > >>> Thanks
> > >>> Artem
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > >>>> Guys,
> > >>>>
> > >>>> Let me try to make this changes.
> > >>>>
> > >>>> Here is my understanding of the steps I need to do.
> > >>>>
> > >>>> 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > >>>> and move hyprt, hysig and hythread code into it. Update build to work
> > >>>> with new directory.
> > >>>>
> > >>>>> [Andrey]- pull out hythread from classlib, make it a shared
> > >>> component
> > >>>> 2. Move DRLVM hythread to classlib and update drlvm build for it. So
> > >>>> both classlib and drlvm will work on the drlvm hythread.
> > >>>>
> > >>>>> - split hythread, refine the bottom layer (thrdsup.h and mutex.h)
> > >>> and
> > >>>>> upper layer (hythead_xxx)
> > >>>>> - migrate classlib code to the bottom layer (1) of hythread
> > >>>> I do not think it is necessary because the hythread will be shared
> > >>> library.
> > >>>> This make sense only in case we move only layer(1) into the shared
> > >>> directory.
> > >>>> 3. merge hythreads into one library getting bast code from both
> > >>> sources.
> > >>>>> migrate DRLVM's thread manager to (1) from APR
> > >>>> Will be done on this stage.
> > >>>>
> > >>>> 4. merge classlib and drlvm signal handling code.
> > >>>>
> > >>>> 5. merge port libs code.
> > >>>>
> > >>>> 6. ????
> > >>>>
> > >>>> Thanks
> > >>>> Artem
> > >>>>
> > >>>> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>>>> On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> > >>>>>
> > >>>>>> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>>>>>> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> > >>>>>>>
> > >>>>>>>> +1 on the below.
> > >>>>>>>>
> > >>>>>>>> I am assuming Andrey and his team will do this work. (Andrey,
> > >>> when
> > >>>>>>>> will you
> > >>>>>>>> start?)
> > >>>>>>> We have to start first by pulling hythread out, but where? After
> > >>>>>>> thinking about it for 5 more seconds, putting it on the top level
> > >>>>>>>
> > >>>>>>> enhanced/<something>
> > >>>>>>>
> > >>>>>>> is IMO a bad idea. There's nothing worse than going to a
> > >>> project's
> > >>>>>>> SVN and finding tons of confusing things.
> > >>>>>> I agree making "thread" a standalone component at the level of
> > >>>>>> enhanced/<something> probably isn't worth doing. What may make a
> > >>> sense
> > >>>>>> is to consider thread a part of the portlib and make the portlib a
> > >>>>>> separate component at that level. Portlib is the only piece
> > >>> which is
> > >>>>>> shared between VM and classlib, this could justify it's appearance
> > >>> at
> > >>>>>> the high level.
> > >>>>>>
> > >>>>>>> Is there any downside to keeping it somewhere under
> > >>> /classlib/trunk
> > >>>>>> My only guess would be the inability to build VM independently from
> > >>>>>> the classlib.
> > >>>>> Sure, you'll still need either to build the /portlib or the /classlib
> > >>>>>
> > >>>>>>> and simply make it a module by itself?
> > >>>>>> If we can not have a portlib as a high level component (like
> > >>> classlib
> > >>>>>> or drlvm), then at least having it as a separate module within
> > >>>>>> classlib would be nice.
> > >>>>> This is one of those things where doing the small step (do it in
> > >>>>> classlib) and then consider the large step (do it as a peer) seems to
> > >>>>> be reasonable, but i don't feel too strongly...
> > >>>>>
> > >>>>> geir
> > >>>>>
> > >>>>>> Thanks,
> > >>>>>> Andrey.
> > >>>>>>
> > >>>>>>>> Hopefully we can clean up how drlvm handles the classlib portlib
> > >>>>>>>> function
> > >>>>>>>> table at the same time. Currently two versions of this table
> > >>> are
> > >>>>>>>> created
> > >>>>>>>> during startup. "Portlib function table - let there be one!"
> > >>>>>>>> Seriously,
> > >>>>>>>> this is incredibly difficult code to maintain.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> > >>>>>>>>> Yes, exactly.
> > >>>>>>>>>
> > >>>>>>>>> Regards,
> > >>>>>>>>> Tim
> > >>>>>>>>>
> > >>>>>>>>> Andrey Chernyshev wrote:
> > >>>>>>>>>> On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>>>>>>>>>> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Weldon, I agree with your comments and observations below.
> > >>>>>>>>> Let's
> > >>>>>>>>> take
> > >>>>>>>>>>>> baby steps to get fully unified. I'm sure we all want to
> > >>>>>>>>> keep things
> > >>>>>>>>>>>> working throughout.
> > >>>>>>>>>>> So what's the first stop? Move hythread as-is out of
> > >>> classlib
> > >>>>>>>>> to a
> > >>>>>>>>>>> peer in the tree?
> > >>>>>>>>>> I can suggest the following steps:
> > >>>>>>>>>> - pull out hythread from classlib, make it a shared
> > >>> component
> > >>>>>>>>>> - split hythread, refine the bottom layer (thrdsup.h and
> > >>>>>>>>> mutex.h) and
> > >>>>>>>>>> upper layer (hythead_xxx)
> > >>>>>>>>>> - migrate classlib code to the bottom layer (1) of hythread
> > >>>>>>>>>> - migrate DRLVM's thread manager to (1) from APR
> > >>>>>>>>>> Each step can be done without breaking the whole code stack.
> > >>>>>>>>>> As a result, we'll have a bottom part of hythread which will
> > >>> be
> > >>>>>>>>> shared
> > >>>>>>>>>> between the classlib and DRLVM.
> > >>>>>>>>>>
> > >>>>>>>>>> Some additional steps could be:
> > >>>>>>>>>> - pull the rest of the portlib out of the classlib, make
> > >>> it a
> > >>>>>>>>> shared
> > >>>>>>>>>> component as well
> > >>>>>>>>>> - migrate DRLVM to portlib
> > >>>>>>>>>>
> > >>>>>>>>>> Thanks,
> > >>>>>>>>>> Andrey.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> geir
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Regards,
> > >>>>>>>>>>>> Tim
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Weldon Washburn wrote:
> > >>>>>>>>>>>>> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> > >>>>>>>>>>>>>> Artem Aliev wrote:
> > >>>>>>>>>>>>>>> Gier,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> The hythread is just most visible example. There are
> > >>> also
> > >>>>>>>>> signal
> > >>>>>>>>>>>>>>> handling problem. classlib hysig lib setup signal
> > >>> handlers
> > >>>>>>>>> and
> > >>>>>>>>> then
> > >>>>>>>>>>>>>>> drlvm overrides them by its owns. There are code
> > >>>>>>>>> duplication in
> > >>>>>>>>>>>>>>> classlib hyprt.dll drlvm port.lib:
> > >>>>>>>>>>>>>>> classlib/trunk/modules/luni/src/main/native/port vm/
> > >>>>>>> port/src
> > >>>>>>>>>>>>>>> These three pair of components contains significant
> > >>> part
> > >>>>>>>>> of the
> > >>>>>>>>>>>>>>> system dependent code for both VM and CLASSLIB. I
> > >>> think,
> > >>>>>>>>> all this
> > >>>>>>>>>>>>>>> code naturally defines portlib component that could be
> > >>>>>>> shared
> > >>>>>>>>>>>>>>> between
> > >>>>>>>>>>>>>>> classlib and VMs. So, as a first step, we could move
> > >>>>>>> all this
> > >>>>>>>>>>>>>>> code in
> > >>>>>>>>>>>>>>> to the one place, name portlib to have three
> > >>> directories
> > >>>>>>>>> classlib,
> > >>>>>>>>>>>>>>> drlvm, portlib.
> > >>>>>>>>>>>>>> I think it is quite reasonable to call out the portlib
> > >>> and
> > >>>>>>>>> threadlib
> > >>>>>>>>>>>>>> separate (in the repository) to the VM and classlib. As
> > >>>>>>> you
> > >>>>>>>>>>>>>> point out,
> > >>>>>>>>>>>>>> then VM and classlib can share the code -- though it
> > >>>>>>> will not
> > >>>>>>>>>>>>>> become a
> > >>>>>>>>>>>>>> requirement for VMs that run the harmony code to be
> > >>> using
> > >>>>>>>>> those
> > >>>>>>>>>>>>>> libraries for their own implementation.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Tim,
> > >>>>>>>>>>>>> One of the things to worry about is system-wide lock
> > >>>>>>>>> protocol. We
> > >>>>>>>>>>>>> will
> > >>>>>>>>>>>>> need
> > >>>>>>>>>>>>> to think through what locks portlib, threadlib and JVM
> > >>> are
> > >>>>>>>>> holding
> > >>>>>>>>>>>>> and if
> > >>>>>>>>>>>>> there are any deadlock possibilities.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Another issue is the implementation of signal chaining.
> > >>>>>>> There
> > >>>>>>>>>>>>> seems to be
> > >>>>>>>>>>>>> code in hysignal.c that implement "-Xrs". I guess the
> > >>> idea
> > >>>>>>>>> is that
> > >>>>>>>>> a
> > >>>>>>>>>>>>> Harmony JVM would somehow not link this code and use its
> > >>> own
> > >>>>>>>>>>>>> implementation. The bottom line is that we probably need
> > >>> to
> > >>>>>>>>>>>>> carefully pick
> > >>>>>>>>>>>>> through what is currently in classlib threads/signals and
> > >>>>>>>>> rearrange
> > >>>>>>>>>>>>> stuff so
> > >>>>>>>>>>>>> that it reduces the confusion. We need to make this part
> > >>> of
> > >>>>>>>>> the
> > >>>>>>>>>>>>> system
> > >>>>>>>>>>>>> much
> > >>>>>>>>>>>>> easier to work on.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Do you have recommendations on next steps? Does it make
> > >>>>>>>>> sense to
> > >>>>>>>>>>>>> start
> > >>>>>>>>>>>>> moving stuff into the directories described above. Or is
> > >>>>>>> more
> > >>>>>>>>>>>>> discussion
> > >>>>>>>>>>>>> needed.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> As the second step, the pairs of libraries should be
> > >>> merged
> > >>>>>>>>> and the
> > >>>>>>>>>>>>>>> classlib and drlvm refactoried to have only 3 lib
> > >>> instead
> > >>>>>>>>> of 6.
> > >>>>>>>>>>>>>> Yep, this would be part of the consolidation into new
> > >>>>>>>>> Harmony top-
> > >>>>>>>>>>>>>> level
> > >>>>>>>>>>>>>> components. It makes sense that we share the same impl
> > >>>>>>> in the
> > >>>>>>>>>>>>>> project.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> The 3rd step is to replace most of the functions with
> > >>> APR
> > >>>>>>>>> ones and
> > >>>>>>>>>>>>>>> move the rest of the code to the APR.
> > >>>>>>>>>>>>>> I think it is quite well documented on this list that
> > >>> this
> > >>>>>>>>> should
> > >>>>>>>>>>>>>> not be
> > >>>>>>>>>>>>>> a goal.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I agree we don't need to move classlib to APR provided
> > >>> that:
> > >>>>>>>>>>>>> 1)
> > >>>>>>>>>>>>> There is an easy to understand distinct seperation of the
> > >>>>>>>>> different
> > >>>>>>>>>>>>> threading/signals packages. In specific, we need to know
> > >>>>>>> which
> > >>>>>>>>>>>>> threading
> > >>>>>>>>>>>>> package is being called by DRLVM without ambiguity.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 2)
> > >>>>>>>>>>>>> There is clear understanding of how JVM and classlib
> > >>>>>>> threading/
> > >>>>>>>>>>>>> signals
> > >>>>>>>>>>>>> interoperate.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Regards,
> > >>>>>>>>>>>>>> Tim
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Thoughts?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Thanks
> > >>>>>>>>>>>>>>> Artem
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>> -------------------------------------------------------------------
> > >>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> 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
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>> ---------------------------------------------------------------------
> > >>>>>>>>>>> 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
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>>
> > >>>>>>>>> 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
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Weldon Washburn
> > >>>>>>>> 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
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> 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
> > >>>>>
> > >>>>> ---------------------------------------------------------------------
> > >>>>> 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
> > >>>>>
> > >>> ---------------------------------------------------------------------
> > >>> 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
> > >>>
> > >>>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Artem Aliev <ar...@gmail.com>.
Tim,
Reading through discussion, I find two option for the second step.
Let's discuss them.
1.
> - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> upper layer (hythead_xxx)
> - migrate classlib code to the bottom layer (1) of hythread
Then move the rest of hythread to VM.
In this case we will move all VM releated functionality out of a classlib.
The classlib will use tls, mutex and thread_create from *.h files.
VM will be free to implement threading in any way.
2. Move hythread out from the drlvm to a portlib.
In this case classlib will contains a lot of only VM releated code.
So we will meet the same problems with an new VM. But we will have
common place for all synchronization primitives and could control
them.
Thanks
Artem
On 10/16/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Tim Ellison wrote:
> > First step (moving out of luni) looks good to me.
> >
> > I'd like some more discussion around the second step (picking up drlvm
> > version) before you do a wholesale replacement.
>
> Yes please. Lets do small, reversible steps.
>
> geir
>
> >
> > Regards,
> > Tim
> >
> > Weldon Washburn wrote:
> >> Artem,
> >> Thanks. I will take a look.
> >>
> >>
> >> On 10/12/06, Artem Aliev <ar...@gmail.com> wrote:
> >>> Guys,
> >>>
> >>>
> >>>> 1. Make classlib/modules/portlib directory (or portlib in the root?)
> >>>> and move hyprt, hysig and hythread code into it. Update build to work
> >>>> with new directory.
> >>>>
> >>>>> [Andrey]- pull out hythread from classlib, make it a shared
> >>> component
> >>> The first step is done in JIRA HARMONY-1843.
> >>>
> >>> I move common, pool, port, thread, sig from luni to new component
> >>> portlib.
> >>> The first idea was to move only port, thread, sig, but they depend on
> >>> common and pool libs. It looks natural to do not produce cyclic
> >>> dependencies among components, so I move these two also to portlib.
> >>>
> >>> Unfortunately, this does not fully solve two stage luni building
> >>> process (build-native-core and build-native-secondary), but this is
> >>> another problem.
> >>>
> >>> So If we are still committed on these reorganization, please review
> >>> and apply the patch.
> >>>
> >>> A move_to_portlib.sh script create portlib directory structure and
> >>> move appropriate files from luni to portlib (by svn move).
> >>> A portlib_files.patch update build to works with new structure.
> >>>
> >>> Thanks
> >>> Artem
> >>>
> >>>
> >>>
> >>>
> >>> On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> >>>> Guys,
> >>>>
> >>>> Let me try to make this changes.
> >>>>
> >>>> Here is my understanding of the steps I need to do.
> >>>>
> >>>> 1. Make classlib/modules/portlib directory (or portlib in the root?)
> >>>> and move hyprt, hysig and hythread code into it. Update build to work
> >>>> with new directory.
> >>>>
> >>>>> [Andrey]- pull out hythread from classlib, make it a shared
> >>> component
> >>>> 2. Move DRLVM hythread to classlib and update drlvm build for it. So
> >>>> both classlib and drlvm will work on the drlvm hythread.
> >>>>
> >>>>> - split hythread, refine the bottom layer (thrdsup.h and mutex.h)
> >>> and
> >>>>> upper layer (hythead_xxx)
> >>>>> - migrate classlib code to the bottom layer (1) of hythread
> >>>> I do not think it is necessary because the hythread will be shared
> >>> library.
> >>>> This make sense only in case we move only layer(1) into the shared
> >>> directory.
> >>>> 3. merge hythreads into one library getting bast code from both
> >>> sources.
> >>>>> migrate DRLVM's thread manager to (1) from APR
> >>>> Will be done on this stage.
> >>>>
> >>>> 4. merge classlib and drlvm signal handling code.
> >>>>
> >>>> 5. merge port libs code.
> >>>>
> >>>> 6. ????
> >>>>
> >>>> Thanks
> >>>> Artem
> >>>>
> >>>> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>>>> On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> >>>>>
> >>>>>> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>>>>>> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> >>>>>>>
> >>>>>>>> +1 on the below.
> >>>>>>>>
> >>>>>>>> I am assuming Andrey and his team will do this work. (Andrey,
> >>> when
> >>>>>>>> will you
> >>>>>>>> start?)
> >>>>>>> We have to start first by pulling hythread out, but where? After
> >>>>>>> thinking about it for 5 more seconds, putting it on the top level
> >>>>>>>
> >>>>>>> enhanced/<something>
> >>>>>>>
> >>>>>>> is IMO a bad idea. There's nothing worse than going to a
> >>> project's
> >>>>>>> SVN and finding tons of confusing things.
> >>>>>> I agree making "thread" a standalone component at the level of
> >>>>>> enhanced/<something> probably isn't worth doing. What may make a
> >>> sense
> >>>>>> is to consider thread a part of the portlib and make the portlib a
> >>>>>> separate component at that level. Portlib is the only piece
> >>> which is
> >>>>>> shared between VM and classlib, this could justify it's appearance
> >>> at
> >>>>>> the high level.
> >>>>>>
> >>>>>>> Is there any downside to keeping it somewhere under
> >>> /classlib/trunk
> >>>>>> My only guess would be the inability to build VM independently from
> >>>>>> the classlib.
> >>>>> Sure, you'll still need either to build the /portlib or the /classlib
> >>>>>
> >>>>>>> and simply make it a module by itself?
> >>>>>> If we can not have a portlib as a high level component (like
> >>> classlib
> >>>>>> or drlvm), then at least having it as a separate module within
> >>>>>> classlib would be nice.
> >>>>> This is one of those things where doing the small step (do it in
> >>>>> classlib) and then consider the large step (do it as a peer) seems to
> >>>>> be reasonable, but i don't feel too strongly...
> >>>>>
> >>>>> geir
> >>>>>
> >>>>>> Thanks,
> >>>>>> Andrey.
> >>>>>>
> >>>>>>>> Hopefully we can clean up how drlvm handles the classlib portlib
> >>>>>>>> function
> >>>>>>>> table at the same time. Currently two versions of this table
> >>> are
> >>>>>>>> created
> >>>>>>>> during startup. "Portlib function table - let there be one!"
> >>>>>>>> Seriously,
> >>>>>>>> this is incredibly difficult code to maintain.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> >>>>>>>>> Yes, exactly.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Tim
> >>>>>>>>>
> >>>>>>>>> Andrey Chernyshev wrote:
> >>>>>>>>>> On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>>>>>>>>>> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Weldon, I agree with your comments and observations below.
> >>>>>>>>> Let's
> >>>>>>>>> take
> >>>>>>>>>>>> baby steps to get fully unified. I'm sure we all want to
> >>>>>>>>> keep things
> >>>>>>>>>>>> working throughout.
> >>>>>>>>>>> So what's the first stop? Move hythread as-is out of
> >>> classlib
> >>>>>>>>> to a
> >>>>>>>>>>> peer in the tree?
> >>>>>>>>>> I can suggest the following steps:
> >>>>>>>>>> - pull out hythread from classlib, make it a shared
> >>> component
> >>>>>>>>>> - split hythread, refine the bottom layer (thrdsup.h and
> >>>>>>>>> mutex.h) and
> >>>>>>>>>> upper layer (hythead_xxx)
> >>>>>>>>>> - migrate classlib code to the bottom layer (1) of hythread
> >>>>>>>>>> - migrate DRLVM's thread manager to (1) from APR
> >>>>>>>>>> Each step can be done without breaking the whole code stack.
> >>>>>>>>>> As a result, we'll have a bottom part of hythread which will
> >>> be
> >>>>>>>>> shared
> >>>>>>>>>> between the classlib and DRLVM.
> >>>>>>>>>>
> >>>>>>>>>> Some additional steps could be:
> >>>>>>>>>> - pull the rest of the portlib out of the classlib, make
> >>> it a
> >>>>>>>>> shared
> >>>>>>>>>> component as well
> >>>>>>>>>> - migrate DRLVM to portlib
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Andrey.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> geir
> >>>>>>>>>>>
> >>>>>>>>>>>> Regards,
> >>>>>>>>>>>> Tim
> >>>>>>>>>>>>
> >>>>>>>>>>>> Weldon Washburn wrote:
> >>>>>>>>>>>>> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> >>>>>>>>>>>>>> Artem Aliev wrote:
> >>>>>>>>>>>>>>> Gier,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The hythread is just most visible example. There are
> >>> also
> >>>>>>>>> signal
> >>>>>>>>>>>>>>> handling problem. classlib hysig lib setup signal
> >>> handlers
> >>>>>>>>> and
> >>>>>>>>> then
> >>>>>>>>>>>>>>> drlvm overrides them by its owns. There are code
> >>>>>>>>> duplication in
> >>>>>>>>>>>>>>> classlib hyprt.dll drlvm port.lib:
> >>>>>>>>>>>>>>> classlib/trunk/modules/luni/src/main/native/port vm/
> >>>>>>> port/src
> >>>>>>>>>>>>>>> These three pair of components contains significant
> >>> part
> >>>>>>>>> of the
> >>>>>>>>>>>>>>> system dependent code for both VM and CLASSLIB. I
> >>> think,
> >>>>>>>>> all this
> >>>>>>>>>>>>>>> code naturally defines portlib component that could be
> >>>>>>> shared
> >>>>>>>>>>>>>>> between
> >>>>>>>>>>>>>>> classlib and VMs. So, as a first step, we could move
> >>>>>>> all this
> >>>>>>>>>>>>>>> code in
> >>>>>>>>>>>>>>> to the one place, name portlib to have three
> >>> directories
> >>>>>>>>> classlib,
> >>>>>>>>>>>>>>> drlvm, portlib.
> >>>>>>>>>>>>>> I think it is quite reasonable to call out the portlib
> >>> and
> >>>>>>>>> threadlib
> >>>>>>>>>>>>>> separate (in the repository) to the VM and classlib. As
> >>>>>>> you
> >>>>>>>>>>>>>> point out,
> >>>>>>>>>>>>>> then VM and classlib can share the code -- though it
> >>>>>>> will not
> >>>>>>>>>>>>>> become a
> >>>>>>>>>>>>>> requirement for VMs that run the harmony code to be
> >>> using
> >>>>>>>>> those
> >>>>>>>>>>>>>> libraries for their own implementation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Tim,
> >>>>>>>>>>>>> One of the things to worry about is system-wide lock
> >>>>>>>>> protocol. We
> >>>>>>>>>>>>> will
> >>>>>>>>>>>>> need
> >>>>>>>>>>>>> to think through what locks portlib, threadlib and JVM
> >>> are
> >>>>>>>>> holding
> >>>>>>>>>>>>> and if
> >>>>>>>>>>>>> there are any deadlock possibilities.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Another issue is the implementation of signal chaining.
> >>>>>>> There
> >>>>>>>>>>>>> seems to be
> >>>>>>>>>>>>> code in hysignal.c that implement "-Xrs". I guess the
> >>> idea
> >>>>>>>>> is that
> >>>>>>>>> a
> >>>>>>>>>>>>> Harmony JVM would somehow not link this code and use its
> >>> own
> >>>>>>>>>>>>> implementation. The bottom line is that we probably need
> >>> to
> >>>>>>>>>>>>> carefully pick
> >>>>>>>>>>>>> through what is currently in classlib threads/signals and
> >>>>>>>>> rearrange
> >>>>>>>>>>>>> stuff so
> >>>>>>>>>>>>> that it reduces the confusion. We need to make this part
> >>> of
> >>>>>>>>> the
> >>>>>>>>>>>>> system
> >>>>>>>>>>>>> much
> >>>>>>>>>>>>> easier to work on.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Do you have recommendations on next steps? Does it make
> >>>>>>>>> sense to
> >>>>>>>>>>>>> start
> >>>>>>>>>>>>> moving stuff into the directories described above. Or is
> >>>>>>> more
> >>>>>>>>>>>>> discussion
> >>>>>>>>>>>>> needed.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> As the second step, the pairs of libraries should be
> >>> merged
> >>>>>>>>> and the
> >>>>>>>>>>>>>>> classlib and drlvm refactoried to have only 3 lib
> >>> instead
> >>>>>>>>> of 6.
> >>>>>>>>>>>>>> Yep, this would be part of the consolidation into new
> >>>>>>>>> Harmony top-
> >>>>>>>>>>>>>> level
> >>>>>>>>>>>>>> components. It makes sense that we share the same impl
> >>>>>>> in the
> >>>>>>>>>>>>>> project.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The 3rd step is to replace most of the functions with
> >>> APR
> >>>>>>>>> ones and
> >>>>>>>>>>>>>>> move the rest of the code to the APR.
> >>>>>>>>>>>>>> I think it is quite well documented on this list that
> >>> this
> >>>>>>>>> should
> >>>>>>>>>>>>>> not be
> >>>>>>>>>>>>>> a goal.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I agree we don't need to move classlib to APR provided
> >>> that:
> >>>>>>>>>>>>> 1)
> >>>>>>>>>>>>> There is an easy to understand distinct seperation of the
> >>>>>>>>> different
> >>>>>>>>>>>>> threading/signals packages. In specific, we need to know
> >>>>>>> which
> >>>>>>>>>>>>> threading
> >>>>>>>>>>>>> package is being called by DRLVM without ambiguity.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2)
> >>>>>>>>>>>>> There is clear understanding of how JVM and classlib
> >>>>>>> threading/
> >>>>>>>>>>>>> signals
> >>>>>>>>>>>>> interoperate.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>> Tim
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thoughts?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>> Artem
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>> -------------------------------------------------------------------
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>>
> >>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Weldon Washburn
> >>>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> 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
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> 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
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> First step (moving out of luni) looks good to me.
>
> I'd like some more discussion around the second step (picking up drlvm
> version) before you do a wholesale replacement.
Yes please. Lets do small, reversible steps.
geir
>
> Regards,
> Tim
>
> Weldon Washburn wrote:
>> Artem,
>> Thanks. I will take a look.
>>
>>
>> On 10/12/06, Artem Aliev <ar...@gmail.com> wrote:
>>> Guys,
>>>
>>>
>>>> 1. Make classlib/modules/portlib directory (or portlib in the root?)
>>>> and move hyprt, hysig and hythread code into it. Update build to work
>>>> with new directory.
>>>>
>>>>> [Andrey]- pull out hythread from classlib, make it a shared
>>> component
>>> The first step is done in JIRA HARMONY-1843.
>>>
>>> I move common, pool, port, thread, sig from luni to new component
>>> portlib.
>>> The first idea was to move only port, thread, sig, but they depend on
>>> common and pool libs. It looks natural to do not produce cyclic
>>> dependencies among components, so I move these two also to portlib.
>>>
>>> Unfortunately, this does not fully solve two stage luni building
>>> process (build-native-core and build-native-secondary), but this is
>>> another problem.
>>>
>>> So If we are still committed on these reorganization, please review
>>> and apply the patch.
>>>
>>> A move_to_portlib.sh script create portlib directory structure and
>>> move appropriate files from luni to portlib (by svn move).
>>> A portlib_files.patch update build to works with new structure.
>>>
>>> Thanks
>>> Artem
>>>
>>>
>>>
>>>
>>> On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
>>>> Guys,
>>>>
>>>> Let me try to make this changes.
>>>>
>>>> Here is my understanding of the steps I need to do.
>>>>
>>>> 1. Make classlib/modules/portlib directory (or portlib in the root?)
>>>> and move hyprt, hysig and hythread code into it. Update build to work
>>>> with new directory.
>>>>
>>>>> [Andrey]- pull out hythread from classlib, make it a shared
>>> component
>>>> 2. Move DRLVM hythread to classlib and update drlvm build for it. So
>>>> both classlib and drlvm will work on the drlvm hythread.
>>>>
>>>>> - split hythread, refine the bottom layer (thrdsup.h and mutex.h)
>>> and
>>>>> upper layer (hythead_xxx)
>>>>> - migrate classlib code to the bottom layer (1) of hythread
>>>> I do not think it is necessary because the hythread will be shared
>>> library.
>>>> This make sense only in case we move only layer(1) into the shared
>>> directory.
>>>> 3. merge hythreads into one library getting bast code from both
>>> sources.
>>>>> migrate DRLVM's thread manager to (1) from APR
>>>> Will be done on this stage.
>>>>
>>>> 4. merge classlib and drlvm signal handling code.
>>>>
>>>> 5. merge port libs code.
>>>>
>>>> 6. ????
>>>>
>>>> Thanks
>>>> Artem
>>>>
>>>> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>>>> On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
>>>>>
>>>>>> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>>>>>> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
>>>>>>>
>>>>>>>> +1 on the below.
>>>>>>>>
>>>>>>>> I am assuming Andrey and his team will do this work. (Andrey,
>>> when
>>>>>>>> will you
>>>>>>>> start?)
>>>>>>> We have to start first by pulling hythread out, but where? After
>>>>>>> thinking about it for 5 more seconds, putting it on the top level
>>>>>>>
>>>>>>> enhanced/<something>
>>>>>>>
>>>>>>> is IMO a bad idea. There's nothing worse than going to a
>>> project's
>>>>>>> SVN and finding tons of confusing things.
>>>>>> I agree making "thread" a standalone component at the level of
>>>>>> enhanced/<something> probably isn't worth doing. What may make a
>>> sense
>>>>>> is to consider thread a part of the portlib and make the portlib a
>>>>>> separate component at that level. Portlib is the only piece
>>> which is
>>>>>> shared between VM and classlib, this could justify it's appearance
>>> at
>>>>>> the high level.
>>>>>>
>>>>>>> Is there any downside to keeping it somewhere under
>>> /classlib/trunk
>>>>>> My only guess would be the inability to build VM independently from
>>>>>> the classlib.
>>>>> Sure, you'll still need either to build the /portlib or the /classlib
>>>>>
>>>>>>> and simply make it a module by itself?
>>>>>> If we can not have a portlib as a high level component (like
>>> classlib
>>>>>> or drlvm), then at least having it as a separate module within
>>>>>> classlib would be nice.
>>>>> This is one of those things where doing the small step (do it in
>>>>> classlib) and then consider the large step (do it as a peer) seems to
>>>>> be reasonable, but i don't feel too strongly...
>>>>>
>>>>> geir
>>>>>
>>>>>> Thanks,
>>>>>> Andrey.
>>>>>>
>>>>>>>> Hopefully we can clean up how drlvm handles the classlib portlib
>>>>>>>> function
>>>>>>>> table at the same time. Currently two versions of this table
>>> are
>>>>>>>> created
>>>>>>>> during startup. "Portlib function table - let there be one!"
>>>>>>>> Seriously,
>>>>>>>> this is incredibly difficult code to maintain.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
>>>>>>>>> Yes, exactly.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Tim
>>>>>>>>>
>>>>>>>>> Andrey Chernyshev wrote:
>>>>>>>>>> On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>>>>>>>>>> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Weldon, I agree with your comments and observations below.
>>>>>>>>> Let's
>>>>>>>>> take
>>>>>>>>>>>> baby steps to get fully unified. I'm sure we all want to
>>>>>>>>> keep things
>>>>>>>>>>>> working throughout.
>>>>>>>>>>> So what's the first stop? Move hythread as-is out of
>>> classlib
>>>>>>>>> to a
>>>>>>>>>>> peer in the tree?
>>>>>>>>>> I can suggest the following steps:
>>>>>>>>>> - pull out hythread from classlib, make it a shared
>>> component
>>>>>>>>>> - split hythread, refine the bottom layer (thrdsup.h and
>>>>>>>>> mutex.h) and
>>>>>>>>>> upper layer (hythead_xxx)
>>>>>>>>>> - migrate classlib code to the bottom layer (1) of hythread
>>>>>>>>>> - migrate DRLVM's thread manager to (1) from APR
>>>>>>>>>> Each step can be done without breaking the whole code stack.
>>>>>>>>>> As a result, we'll have a bottom part of hythread which will
>>> be
>>>>>>>>> shared
>>>>>>>>>> between the classlib and DRLVM.
>>>>>>>>>>
>>>>>>>>>> Some additional steps could be:
>>>>>>>>>> - pull the rest of the portlib out of the classlib, make
>>> it a
>>>>>>>>> shared
>>>>>>>>>> component as well
>>>>>>>>>> - migrate DRLVM to portlib
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Andrey.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> geir
>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Tim
>>>>>>>>>>>>
>>>>>>>>>>>> Weldon Washburn wrote:
>>>>>>>>>>>>> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>>>>>>>>>>>>>> Artem Aliev wrote:
>>>>>>>>>>>>>>> Gier,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The hythread is just most visible example. There are
>>> also
>>>>>>>>> signal
>>>>>>>>>>>>>>> handling problem. classlib hysig lib setup signal
>>> handlers
>>>>>>>>> and
>>>>>>>>> then
>>>>>>>>>>>>>>> drlvm overrides them by its owns. There are code
>>>>>>>>> duplication in
>>>>>>>>>>>>>>> classlib hyprt.dll drlvm port.lib:
>>>>>>>>>>>>>>> classlib/trunk/modules/luni/src/main/native/port vm/
>>>>>>> port/src
>>>>>>>>>>>>>>> These three pair of components contains significant
>>> part
>>>>>>>>> of the
>>>>>>>>>>>>>>> system dependent code for both VM and CLASSLIB. I
>>> think,
>>>>>>>>> all this
>>>>>>>>>>>>>>> code naturally defines portlib component that could be
>>>>>>> shared
>>>>>>>>>>>>>>> between
>>>>>>>>>>>>>>> classlib and VMs. So, as a first step, we could move
>>>>>>> all this
>>>>>>>>>>>>>>> code in
>>>>>>>>>>>>>>> to the one place, name portlib to have three
>>> directories
>>>>>>>>> classlib,
>>>>>>>>>>>>>>> drlvm, portlib.
>>>>>>>>>>>>>> I think it is quite reasonable to call out the portlib
>>> and
>>>>>>>>> threadlib
>>>>>>>>>>>>>> separate (in the repository) to the VM and classlib. As
>>>>>>> you
>>>>>>>>>>>>>> point out,
>>>>>>>>>>>>>> then VM and classlib can share the code -- though it
>>>>>>> will not
>>>>>>>>>>>>>> become a
>>>>>>>>>>>>>> requirement for VMs that run the harmony code to be
>>> using
>>>>>>>>> those
>>>>>>>>>>>>>> libraries for their own implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tim,
>>>>>>>>>>>>> One of the things to worry about is system-wide lock
>>>>>>>>> protocol. We
>>>>>>>>>>>>> will
>>>>>>>>>>>>> need
>>>>>>>>>>>>> to think through what locks portlib, threadlib and JVM
>>> are
>>>>>>>>> holding
>>>>>>>>>>>>> and if
>>>>>>>>>>>>> there are any deadlock possibilities.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another issue is the implementation of signal chaining.
>>>>>>> There
>>>>>>>>>>>>> seems to be
>>>>>>>>>>>>> code in hysignal.c that implement "-Xrs". I guess the
>>> idea
>>>>>>>>> is that
>>>>>>>>> a
>>>>>>>>>>>>> Harmony JVM would somehow not link this code and use its
>>> own
>>>>>>>>>>>>> implementation. The bottom line is that we probably need
>>> to
>>>>>>>>>>>>> carefully pick
>>>>>>>>>>>>> through what is currently in classlib threads/signals and
>>>>>>>>> rearrange
>>>>>>>>>>>>> stuff so
>>>>>>>>>>>>> that it reduces the confusion. We need to make this part
>>> of
>>>>>>>>> the
>>>>>>>>>>>>> system
>>>>>>>>>>>>> much
>>>>>>>>>>>>> easier to work on.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you have recommendations on next steps? Does it make
>>>>>>>>> sense to
>>>>>>>>>>>>> start
>>>>>>>>>>>>> moving stuff into the directories described above. Or is
>>>>>>> more
>>>>>>>>>>>>> discussion
>>>>>>>>>>>>> needed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> As the second step, the pairs of libraries should be
>>> merged
>>>>>>>>> and the
>>>>>>>>>>>>>>> classlib and drlvm refactoried to have only 3 lib
>>> instead
>>>>>>>>> of 6.
>>>>>>>>>>>>>> Yep, this would be part of the consolidation into new
>>>>>>>>> Harmony top-
>>>>>>>>>>>>>> level
>>>>>>>>>>>>>> components. It makes sense that we share the same impl
>>>>>>> in the
>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The 3rd step is to replace most of the functions with
>>> APR
>>>>>>>>> ones and
>>>>>>>>>>>>>>> move the rest of the code to the APR.
>>>>>>>>>>>>>> I think it is quite well documented on this list that
>>> this
>>>>>>>>> should
>>>>>>>>>>>>>> not be
>>>>>>>>>>>>>> a goal.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree we don't need to move classlib to APR provided
>>> that:
>>>>>>>>>>>>> 1)
>>>>>>>>>>>>> There is an easy to understand distinct seperation of the
>>>>>>>>> different
>>>>>>>>>>>>> threading/signals packages. In specific, we need to know
>>>>>>> which
>>>>>>>>>>>>> threading
>>>>>>>>>>>>> package is being called by DRLVM without ambiguity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2)
>>>>>>>>>>>>> There is clear understanding of how JVM and classlib
>>>>>>> threading/
>>>>>>>>>>>>> signals
>>>>>>>>>>>>> interoperate.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Tim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Artem
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>> -------------------------------------------------------------------
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Weldon Washburn
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Tim Ellison <t....@gmail.com>.
First step (moving out of luni) looks good to me.
I'd like some more discussion around the second step (picking up drlvm
version) before you do a wholesale replacement.
Regards,
Tim
Weldon Washburn wrote:
> Artem,
> Thanks. I will take a look.
>
>
> On 10/12/06, Artem Aliev <ar...@gmail.com> wrote:
>>
>> Guys,
>>
>>
>> > 1. Make classlib/modules/portlib directory (or portlib in the root?)
>> > and move hyprt, hysig and hythread code into it. Update build to work
>> > with new directory.
>> >
>> > > [Andrey]- pull out hythread from classlib, make it a shared
>> component
>> >
>>
>> The first step is done in JIRA HARMONY-1843.
>>
>> I move common, pool, port, thread, sig from luni to new component
>> portlib.
>> The first idea was to move only port, thread, sig, but they depend on
>> common and pool libs. It looks natural to do not produce cyclic
>> dependencies among components, so I move these two also to portlib.
>>
>> Unfortunately, this does not fully solve two stage luni building
>> process (build-native-core and build-native-secondary), but this is
>> another problem.
>>
>> So If we are still committed on these reorganization, please review
>> and apply the patch.
>>
>> A move_to_portlib.sh script create portlib directory structure and
>> move appropriate files from luni to portlib (by svn move).
>> A portlib_files.patch update build to works with new structure.
>>
>> Thanks
>> Artem
>>
>>
>>
>>
>> On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
>> > Guys,
>> >
>> > Let me try to make this changes.
>> >
>> > Here is my understanding of the steps I need to do.
>> >
>> > 1. Make classlib/modules/portlib directory (or portlib in the root?)
>> > and move hyprt, hysig and hythread code into it. Update build to work
>> > with new directory.
>> >
>> > > [Andrey]- pull out hythread from classlib, make it a shared
>> component
>> >
>> > 2. Move DRLVM hythread to classlib and update drlvm build for it. So
>> > both classlib and drlvm will work on the drlvm hythread.
>> >
>> > > - split hythread, refine the bottom layer (thrdsup.h and mutex.h)
>> and
>> > > upper layer (hythead_xxx)
>> > > - migrate classlib code to the bottom layer (1) of hythread
>> > I do not think it is necessary because the hythread will be shared
>> library.
>> > This make sense only in case we move only layer(1) into the shared
>> directory.
>> >
>> > 3. merge hythreads into one library getting bast code from both
>> sources.
>> > > migrate DRLVM's thread manager to (1) from APR
>> > Will be done on this stage.
>> >
>> > 4. merge classlib and drlvm signal handling code.
>> >
>> > 5. merge port libs code.
>> >
>> > 6. ????
>> >
>> > Thanks
>> > Artem
>> >
>> > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > >
>> > > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
>> > >
>> > > > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > > >>
>> > > >> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
>> > > >>
>> > > >> > +1 on the below.
>> > > >> >
>> > > >> > I am assuming Andrey and his team will do this work. (Andrey,
>> when
>> > > >> > will you
>> > > >> > start?)
>> > > >>
>> > > >> We have to start first by pulling hythread out, but where? After
>> > > >> thinking about it for 5 more seconds, putting it on the top level
>> > > >>
>> > > >> enhanced/<something>
>> > > >>
>> > > >> is IMO a bad idea. There's nothing worse than going to a
>> project's
>> > > >> SVN and finding tons of confusing things.
>> > > >
>> > > > I agree making "thread" a standalone component at the level of
>> > > > enhanced/<something> probably isn't worth doing. What may make a
>> sense
>> > > > is to consider thread a part of the portlib and make the portlib a
>> > > > separate component at that level. Portlib is the only piece
>> which is
>> > > > shared between VM and classlib, this could justify it's appearance
>> at
>> > > > the high level.
>> > > >
>> > > >>
>> > > >> Is there any downside to keeping it somewhere under
>> /classlib/trunk
>> > > >
>> > > > My only guess would be the inability to build VM independently from
>> > > > the classlib.
>> > >
>> > > Sure, you'll still need either to build the /portlib or the /classlib
>> > >
>> > > >
>> > > >> and simply make it a module by itself?
>> > > >
>> > > > If we can not have a portlib as a high level component (like
>> classlib
>> > > > or drlvm), then at least having it as a separate module within
>> > > > classlib would be nice.
>> > >
>> > > This is one of those things where doing the small step (do it in
>> > > classlib) and then consider the large step (do it as a peer) seems to
>> > > be reasonable, but i don't feel too strongly...
>> > >
>> > > geir
>> > >
>> > > >
>> > > > Thanks,
>> > > > Andrey.
>> > > >
>> > > >>
>> > > >> >
>> > > >> > Hopefully we can clean up how drlvm handles the classlib portlib
>> > > >> > function
>> > > >> > table at the same time. Currently two versions of this table
>> are
>> > > >> > created
>> > > >> > during startup. "Portlib function table - let there be one!"
>> > > >> > Seriously,
>> > > >> > this is incredibly difficult code to maintain.
>> > > >> >
>> > > >> >
>> > > >> > On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
>> > > >> >>
>> > > >> >> Yes, exactly.
>> > > >> >>
>> > > >> >> Regards,
>> > > >> >> Tim
>> > > >> >>
>> > > >> >> Andrey Chernyshev wrote:
>> > > >> >> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > > >> >> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
>> > > >> >> >>
>> > > >> >> >> > Weldon, I agree with your comments and observations below.
>> > > >> >> Let's
>> > > >> >> take
>> > > >> >> >> > baby steps to get fully unified. I'm sure we all want to
>> > > >> >> keep things
>> > > >> >> >> > working throughout.
>> > > >> >> >>
>> > > >> >> >> So what's the first stop? Move hythread as-is out of
>> classlib
>> > > >> >> to a
>> > > >> >> >> peer in the tree?
>> > > >> >> >
>> > > >> >> > I can suggest the following steps:
>> > > >> >> > - pull out hythread from classlib, make it a shared
>> component
>> > > >> >> > - split hythread, refine the bottom layer (thrdsup.h and
>> > > >> >> mutex.h) and
>> > > >> >> > upper layer (hythead_xxx)
>> > > >> >> > - migrate classlib code to the bottom layer (1) of hythread
>> > > >> >> > - migrate DRLVM's thread manager to (1) from APR
>> > > >> >> > Each step can be done without breaking the whole code stack.
>> > > >> >> > As a result, we'll have a bottom part of hythread which will
>> be
>> > > >> >> shared
>> > > >> >> > between the classlib and DRLVM.
>> > > >> >> >
>> > > >> >> > Some additional steps could be:
>> > > >> >> > - pull the rest of the portlib out of the classlib, make
>> it a
>> > > >> >> shared
>> > > >> >> > component as well
>> > > >> >> > - migrate DRLVM to portlib
>> > > >> >> >
>> > > >> >> > Thanks,
>> > > >> >> > Andrey.
>> > > >> >> >
>> > > >> >> >
>> > > >> >> >>
>> > > >> >> >> geir
>> > > >> >> >>
>> > > >> >> >> >
>> > > >> >> >> > Regards,
>> > > >> >> >> > Tim
>> > > >> >> >> >
>> > > >> >> >> > Weldon Washburn wrote:
>> > > >> >> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>> > > >> >> >> >>>
>> > > >> >> >> >>> Artem Aliev wrote:
>> > > >> >> >> >>>> Gier,
>> > > >> >> >> >>>>
>> > > >> >> >> >>>> The hythread is just most visible example. There are
>> also
>> > > >> >> signal
>> > > >> >> >> >>>> handling problem. classlib hysig lib setup signal
>> handlers
>> > > >> >> and
>> > > >> >> then
>> > > >> >> >> >>>> drlvm overrides them by its owns. There are code
>> > > >> >> duplication in
>> > > >> >> >> >>>> classlib hyprt.dll drlvm port.lib:
>> > > >> >> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/
>> > > >> port/src
>> > > >> >> >> >>>>
>> > > >> >> >> >>>> These three pair of components contains significant
>> part
>> > > >> >> of the
>> > > >> >> >> >>>> system dependent code for both VM and CLASSLIB. I
>> think,
>> > > >> >> all this
>> > > >> >> >> >>>> code naturally defines portlib component that could be
>> > > >> shared
>> > > >> >> >> >>>> between
>> > > >> >> >> >>>> classlib and VMs. So, as a first step, we could move
>> > > >> all this
>> > > >> >> >> >>>> code in
>> > > >> >> >> >>>> to the one place, name portlib to have three
>> directories
>> > > >> >> classlib,
>> > > >> >> >> >>>> drlvm, portlib.
>> > > >> >> >> >>>
>> > > >> >> >> >>> I think it is quite reasonable to call out the portlib
>> and
>> > > >> >> threadlib
>> > > >> >> >> >>> separate (in the repository) to the VM and classlib. As
>> > > >> you
>> > > >> >> >> >>> point out,
>> > > >> >> >> >>> then VM and classlib can share the code -- though it
>> > > >> will not
>> > > >> >> >> >>> become a
>> > > >> >> >> >>> requirement for VMs that run the harmony code to be
>> using
>> > > >> >> those
>> > > >> >> >> >>> libraries for their own implementation.
>> > > >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >> >> Tim,
>> > > >> >> >> >> One of the things to worry about is system-wide lock
>> > > >> >> protocol. We
>> > > >> >> >> >> will
>> > > >> >> >> >> need
>> > > >> >> >> >> to think through what locks portlib, threadlib and JVM
>> are
>> > > >> >> holding
>> > > >> >> >> >> and if
>> > > >> >> >> >> there are any deadlock possibilities.
>> > > >> >> >> >>
>> > > >> >> >> >> Another issue is the implementation of signal chaining.
>> > > >> There
>> > > >> >> >> >> seems to be
>> > > >> >> >> >> code in hysignal.c that implement "-Xrs". I guess the
>> idea
>> > > >> >> is that
>> > > >> >> a
>> > > >> >> >> >> Harmony JVM would somehow not link this code and use its
>> own
>> > > >> >> >> >> implementation. The bottom line is that we probably need
>> to
>> > > >> >> >> >> carefully pick
>> > > >> >> >> >> through what is currently in classlib threads/signals and
>> > > >> >> rearrange
>> > > >> >> >> >> stuff so
>> > > >> >> >> >> that it reduces the confusion. We need to make this part
>> of
>> > > >> >> the
>> > > >> >> >> >> system
>> > > >> >> >> >> much
>> > > >> >> >> >> easier to work on.
>> > > >> >> >> >>
>> > > >> >> >> >> Do you have recommendations on next steps? Does it make
>> > > >> >> sense to
>> > > >> >> >> >> start
>> > > >> >> >> >> moving stuff into the directories described above. Or is
>> > > >> more
>> > > >> >> >> >> discussion
>> > > >> >> >> >> needed.
>> > > >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >> >>> As the second step, the pairs of libraries should be
>> merged
>> > > >> >> and the
>> > > >> >> >> >>>> classlib and drlvm refactoried to have only 3 lib
>> instead
>> > > >> >> of 6.
>> > > >> >> >> >>>
>> > > >> >> >> >>> Yep, this would be part of the consolidation into new
>> > > >> >> Harmony top-
>> > > >> >> >> >>> level
>> > > >> >> >> >>> components. It makes sense that we share the same impl
>> > > >> in the
>> > > >> >> >> >>> project.
>> > > >> >> >> >>>
>> > > >> >> >> >>>> The 3rd step is to replace most of the functions with
>> APR
>> > > >> >> ones and
>> > > >> >> >> >>>> move the rest of the code to the APR.
>> > > >> >> >> >>>
>> > > >> >> >> >>> I think it is quite well documented on this list that
>> this
>> > > >> >> should
>> > > >> >> >> >>> not be
>> > > >> >> >> >>> a goal.
>> > > >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >> >> I agree we don't need to move classlib to APR provided
>> that:
>> > > >> >> >> >>
>> > > >> >> >> >> 1)
>> > > >> >> >> >> There is an easy to understand distinct seperation of the
>> > > >> >> different
>> > > >> >> >> >> threading/signals packages. In specific, we need to know
>> > > >> which
>> > > >> >> >> >> threading
>> > > >> >> >> >> package is being called by DRLVM without ambiguity.
>> > > >> >> >> >>
>> > > >> >> >> >> 2)
>> > > >> >> >> >> There is clear understanding of how JVM and classlib
>> > > >> threading/
>> > > >> >> >> >> signals
>> > > >> >> >> >> interoperate.
>> > > >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >> >> Regards,
>> > > >> >> >> >>> Tim
>> > > >> >> >> >>>
>> > > >> >> >> >>>> Thoughts?
>> > > >> >> >> >>>>
>> > > >> >> >> >>>> Thanks
>> > > >> >> >> >>>> Artem
>> > > >> >> >> >>>>
>> > > >> >> >> >>>>
>> > > >> >> >> >>>>
>> > > >> >> >> >>>>
>> > > >> >> >> >>>>
>> > > >> >> >> >>>>
>> > > >> >> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
>> > > >> >> >> >>>>>
>> > > >> >> >> >>>>>
>> > > >> >> >> >>>>
>> > > >> >> >> >>>>
>> > > >> >>
>> > > >>
>> -------------------------------------------------------------------
>> > > >> >> >> >>>> --
>> > > >> >> >> >>>> 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
>> > > >> >> >> >>>>
>> > > >> >> >> >>>>
>> > > >> >> >> >>>
>> > > >> >> >> >>> --
>> > > >> >> >> >>>
>> > > >> >> >> >>> 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
>> > > >> >> >> >>>
>> > > >> >> >> >>>
>> > > >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >> >
>> > > >> >> >> > --
>> > > >> >> >> >
>> > > >> >> >> > 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
>> > > >> >> >> >
>> > > >> >> >>
>> > > >> >> >>
>> > > >> >> >>
>> > > >> >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> >> >> 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
>> > > >> >> >>
>> > > >> >> >>
>> > > >> >> >
>> > > >> >> >
>> > > >> >>
>> > > >> >> --
>> > > >> >>
>> > > >> >> 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
>> > > >> >>
>> > > >> >>
>> > > >> >
>> > > >> >
>> > > >> > --
>> > > >> > Weldon Washburn
>> > > >> > 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
>> > > >>
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > 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
>> > > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > 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
>> > >
>> > >
>> >
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>
--
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Mark Hindess <ma...@googlemail.com>.
Artem,
Thanks for this patch. Works for me on Linux.
Moving common and pool as well seems reasonable.
I'll make a minor modification once Weldon has committed it. (Just to
combine the copy-native-includes-windows and copy-native-includes-linux
actions into a second copy in the copy-native-includes target by using
the ${hy.os} variable as the last component in the path.)
Regards,
Mark.
On 15 October 2006 at 11:53, "Weldon Washburn" <we...@gmail.com> wrote:
>
> Artem,
> Thanks. I will take a look.
>
>
> On 10/12/06, Artem Aliev <ar...@gmail.com> wrote:
> >
> > Guys,
> >
> >
> > > 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > > and move hyprt, hysig and hythread code into it. Update build to work
> > > with new directory.
> > >
> > > > [Andrey]- pull out hythread from classlib, make it a shared component
> > >
> >
> > The first step is done in JIRA HARMONY-1843.
> >
> > I move common, pool, port, thread, sig from luni to new component portlib.
> > The first idea was to move only port, thread, sig, but they depend on
> > common and pool libs. It looks natural to do not produce cyclic
> > dependencies among components, so I move these two also to portlib.
> >
> > Unfortunately, this does not fully solve two stage luni building
> > process (build-native-core and build-native-secondary), but this is
> > another problem.
> >
> > So If we are still committed on these reorganization, please review
> > and apply the patch.
> >
> > A move_to_portlib.sh script create portlib directory structure and
> > move appropriate files from luni to portlib (by svn move).
> > A portlib_files.patch update build to works with new structure.
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> > On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > > Guys,
> > >
> > > Let me try to make this changes.
> > >
> > > Here is my understanding of the steps I need to do.
> > >
> > > 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > > and move hyprt, hysig and hythread code into it. Update build to work
> > > with new directory.
> > >
> > > > [Andrey]- pull out hythread from classlib, make it a shared component
> > >
> > > 2. Move DRLVM hythread to classlib and update drlvm build for it. So
> > > both classlib and drlvm will work on the drlvm hythread.
> > >
> > > > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> > > > upper layer (hythead_xxx)
> > > > - migrate classlib code to the bottom layer (1) of hythread
> > > I do not think it is necessary because the hythread will be shared
> > library.
> > > This make sense only in case we move only layer(1) into the shared
> > directory.
> > >
> > > 3. merge hythreads into one library getting bast code from both sources.
> > > > migrate DRLVM's thread manager to (1) from APR
> > > Will be done on this stage.
> > >
> > > 4. merge classlib and drlvm signal handling code.
> > >
> > > 5. merge port libs code.
> > >
> > > 6. ????
> > >
> > > Thanks
> > > Artem
> > >
> > > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >
> > > > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> > > >
> > > > > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > >>
> > > > >> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> > > > >>
> > > > >> > +1 on the below.
> > > > >> >
> > > > >> > I am assuming Andrey and his team will do this work. (Andrey,
> > when
> > > > >> > will you
> > > > >> > start?)
> > > > >>
> > > > >> We have to start first by pulling hythread out, but where? After
> > > > >> thinking about it for 5 more seconds, putting it on the top level
> > > > >>
> > > > >> enhanced/<something>
> > > > >>
> > > > >> is IMO a bad idea. There's nothing worse than going to a project's
> > > > >> SVN and finding tons of confusing things.
> > > > >
> > > > > I agree making "thread" a standalone component at the level of
> > > > > enhanced/<something> probably isn't worth doing. What may make a
> > sense
> > > > > is to consider thread a part of the portlib and make the portlib a
> > > > > separate component at that level. Portlib is the only piece which is
> > > > > shared between VM and classlib, this could justify it's appearance
> > at
> > > > > the high level.
> > > > >
> > > > >>
> > > > >> Is there any downside to keeping it somewhere under /classlib/trunk
> > > > >
> > > > > My only guess would be the inability to build VM independently from
> > > > > the classlib.
> > > >
> > > > Sure, you'll still need either to build the /portlib or the /classlib
> > > >
> > > > >
> > > > >> and simply make it a module by itself?
> > > > >
> > > > > If we can not have a portlib as a high level component (like
> > classlib
> > > > > or drlvm), then at least having it as a separate module within
> > > > > classlib would be nice.
> > > >
> > > > This is one of those things where doing the small step (do it in
> > > > classlib) and then consider the large step (do it as a peer) seems to
> > > > be reasonable, but i don't feel too strongly...
> > > >
> > > > geir
> > > >
> > > > >
> > > > > Thanks,
> > > > > Andrey.
> > > > >
> > > > >>
> > > > >> >
> > > > >> > Hopefully we can clean up how drlvm handles the classlib portlib
> > > > >> > function
> > > > >> > table at the same time. Currently two versions of this table are
> > > > >> > created
> > > > >> > during startup. "Portlib function table - let there be one!"
> > > > >> > Seriously,
> > > > >> > this is incredibly difficult code to maintain.
> > > > >> >
> > > > >> >
> > > > >> > On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> > > > >> >>
> > > > >> >> Yes, exactly.
> > > > >> >>
> > > > >> >> Regards,
> > > > >> >> Tim
> > > > >> >>
> > > > >> >> Andrey Chernyshev wrote:
> > > > >> >> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > > >> >> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> > > > >> >> >>
> > > > >> >> >> > Weldon, I agree with your comments and observations below.
> > > > >> >> Let's
> > > > >> >> take
> > > > >> >> >> > baby steps to get fully unified. I'm sure we all want to
> > > > >> >> keep things
> > > > >> >> >> > working throughout.
> > > > >> >> >>
> > > > >> >> >> So what's the first stop? Move hythread as-is out of
> > classlib
> > > > >> >> to a
> > > > >> >> >> peer in the tree?
> > > > >> >> >
> > > > >> >> > I can suggest the following steps:
> > > > >> >> > - pull out hythread from classlib, make it a shared component
> > > > >> >> > - split hythread, refine the bottom layer (thrdsup.h and
> > > > >> >> mutex.h) and
> > > > >> >> > upper layer (hythead_xxx)
> > > > >> >> > - migrate classlib code to the bottom layer (1) of hythread
> > > > >> >> > - migrate DRLVM's thread manager to (1) from APR
> > > > >> >> > Each step can be done without breaking the whole code stack.
> > > > >> >> > As a result, we'll have a bottom part of hythread which will
> > be
> > > > >> >> shared
> > > > >> >> > between the classlib and DRLVM.
> > > > >> >> >
> > > > >> >> > Some additional steps could be:
> > > > >> >> > - pull the rest of the portlib out of the classlib, make it a
> > > > >> >> shared
> > > > >> >> > component as well
> > > > >> >> > - migrate DRLVM to portlib
> > > > >> >> >
> > > > >> >> > Thanks,
> > > > >> >> > Andrey.
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >>
> > > > >> >> >> geir
> > > > >> >> >>
> > > > >> >> >> >
> > > > >> >> >> > Regards,
> > > > >> >> >> > Tim
> > > > >> >> >> >
> > > > >> >> >> > Weldon Washburn wrote:
> > > > >> >> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> > > > >> >> >> >>>
> > > > >> >> >> >>> Artem Aliev wrote:
> > > > >> >> >> >>>> Gier,
> > > > >> >> >> >>>>
> > > > >> >> >> >>>> The hythread is just most visible example. There are
> > also
> > > > >> >> signal
> > > > >> >> >> >>>> handling problem. classlib hysig lib setup signal
> > handlers
> > > > >> >> and
> > > > >> >> then
> > > > >> >> >> >>>> drlvm overrides them by its owns. There are code
> > > > >> >> duplication in
> > > > >> >> >> >>>> classlib hyprt.dll drlvm port.lib:
> > > > >> >> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/
> > > > >> port/src
> > > > >> >> >> >>>>
> > > > >> >> >> >>>> These three pair of components contains significant part
> > > > >> >> of the
> > > > >> >> >> >>>> system dependent code for both VM and CLASSLIB. I think,
> > > > >> >> all this
> > > > >> >> >> >>>> code naturally defines portlib component that could be
> > > > >> shared
> > > > >> >> >> >>>> between
> > > > >> >> >> >>>> classlib and VMs. So, as a first step, we could move
> > > > >> all this
> > > > >> >> >> >>>> code in
> > > > >> >> >> >>>> to the one place, name portlib to have three directories
> > > > >> >> classlib,
> > > > >> >> >> >>>> drlvm, portlib.
> > > > >> >> >> >>>
> > > > >> >> >> >>> I think it is quite reasonable to call out the portlib
> > and
> > > > >> >> threadlib
> > > > >> >> >> >>> separate (in the repository) to the VM and classlib. As
> > > > >> you
> > > > >> >> >> >>> point out,
> > > > >> >> >> >>> then VM and classlib can share the code -- though it
> > > > >> will not
> > > > >> >> >> >>> become a
> > > > >> >> >> >>> requirement for VMs that run the harmony code to be using
> > > > >> >> those
> > > > >> >> >> >>> libraries for their own implementation.
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >> Tim,
> > > > >> >> >> >> One of the things to worry about is system-wide lock
> > > > >> >> protocol. We
> > > > >> >> >> >> will
> > > > >> >> >> >> need
> > > > >> >> >> >> to think through what locks portlib, threadlib and JVM are
> > > > >> >> holding
> > > > >> >> >> >> and if
> > > > >> >> >> >> there are any deadlock possibilities.
> > > > >> >> >> >>
> > > > >> >> >> >> Another issue is the implementation of signal chaining.
> > > > >> There
> > > > >> >> >> >> seems to be
> > > > >> >> >> >> code in hysignal.c that implement "-Xrs". I guess the
> > idea
> > > > >> >> is that
> > > > >> >> a
> > > > >> >> >> >> Harmony JVM would somehow not link this code and use its
> > own
> > > > >> >> >> >> implementation. The bottom line is that we probably need
> > to
> > > > >> >> >> >> carefully pick
> > > > >> >> >> >> through what is currently in classlib threads/signals and
> > > > >> >> rearrange
> > > > >> >> >> >> stuff so
> > > > >> >> >> >> that it reduces the confusion. We need to make this part
> > of
> > > > >> >> the
> > > > >> >> >> >> system
> > > > >> >> >> >> much
> > > > >> >> >> >> easier to work on.
> > > > >> >> >> >>
> > > > >> >> >> >> Do you have recommendations on next steps? Does it make
> > > > >> >> sense to
> > > > >> >> >> >> start
> > > > >> >> >> >> moving stuff into the directories described above. Or is
> > > > >> more
> > > > >> >> >> >> discussion
> > > > >> >> >> >> needed.
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >>> As the second step, the pairs of libraries should be
> > merged
> > > > >> >> and the
> > > > >> >> >> >>>> classlib and drlvm refactoried to have only 3 lib
> > instead
> > > > >> >> of 6.
> > > > >> >> >> >>>
> > > > >> >> >> >>> Yep, this would be part of the consolidation into new
> > > > >> >> Harmony top-
> > > > >> >> >> >>> level
> > > > >> >> >> >>> components. It makes sense that we share the same impl
> > > > >> in the
> > > > >> >> >> >>> project.
> > > > >> >> >> >>>
> > > > >> >> >> >>>> The 3rd step is to replace most of the functions with
> > APR
> > > > >> >> ones and
> > > > >> >> >> >>>> move the rest of the code to the APR.
> > > > >> >> >> >>>
> > > > >> >> >> >>> I think it is quite well documented on this list that
> > this
> > > > >> >> should
> > > > >> >> >> >>> not be
> > > > >> >> >> >>> a goal.
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >> I agree we don't need to move classlib to APR provided
> > that:
> > > > >> >> >> >>
> > > > >> >> >> >> 1)
> > > > >> >> >> >> There is an easy to understand distinct seperation of the
> > > > >> >> different
> > > > >> >> >> >> threading/signals packages. In specific, we need to know
> > > > >> which
> > > > >> >> >> >> threading
> > > > >> >> >> >> package is being called by DRLVM without ambiguity.
> > > > >> >> >> >>
> > > > >> >> >> >> 2)
> > > > >> >> >> >> There is clear understanding of how JVM and classlib
> > > > >> threading/
> > > > >> >> >> >> signals
> > > > >> >> >> >> interoperate.
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >> Regards,
> > > > >> >> >> >>> Tim
> > > > >> >> >> >>>
> > > > >> >> >> >>>> Thoughts?
> > > > >> >> >> >>>>
> > > > >> >> >> >>>> Thanks
> > > > >> >> >> >>>> Artem
> > > > >> >> >> >>>>
> > > > >> >> >> >>>>
> > > > >> >> >> >>>>
> > > > >> >> >> >>>>
> > > > >> >> >> >>>>
> > > > >> >> >> >>>>
> > > > >> >> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> > > > >> >> >> >>>>>
> > > > >> >> >> >>>>>
> > > > >> >> >> >>>>
> > > > >> >> >> >>>>
> > > > >> >>
> > > > >> -------------------------------------------------------------------
> > > > >> >> >> >>>> --
> > > > >> >> >> >>>> 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
> > > > >> >> >> >>>>
> > > > >> >> >> >>>>
> > > > >> >> >> >>>
> > > > >> >> >> >>> --
> > > > >> >> >> >>>
> > > > >> >> >> >>> 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
> > > > >> >> >> >>>
> > > > >> >> >> >>>
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >
> > > > >> >> >> > --
> > > > >> >> >> >
> > > > >> >> >> > 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
> > > > >> >> >> >
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> >> >> 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
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >
> > > > >> >> >
> > > > >> >>
> > > > >> >> --
> > > > >> >>
> > > > >> >> 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
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Weldon Washburn
> > > > >> > 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
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > 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
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
> ------=_Part_35454_4540277.1160938382328--
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Weldon Washburn <we...@gmail.com>.
Artem,
Thanks. I will take a look.
On 10/12/06, Artem Aliev <ar...@gmail.com> wrote:
>
> Guys,
>
>
> > 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > and move hyprt, hysig and hythread code into it. Update build to work
> > with new directory.
> >
> > > [Andrey]- pull out hythread from classlib, make it a shared component
> >
>
> The first step is done in JIRA HARMONY-1843.
>
> I move common, pool, port, thread, sig from luni to new component portlib.
> The first idea was to move only port, thread, sig, but they depend on
> common and pool libs. It looks natural to do not produce cyclic
> dependencies among components, so I move these two also to portlib.
>
> Unfortunately, this does not fully solve two stage luni building
> process (build-native-core and build-native-secondary), but this is
> another problem.
>
> So If we are still committed on these reorganization, please review
> and apply the patch.
>
> A move_to_portlib.sh script create portlib directory structure and
> move appropriate files from luni to portlib (by svn move).
> A portlib_files.patch update build to works with new structure.
>
> Thanks
> Artem
>
>
>
>
> On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> > Guys,
> >
> > Let me try to make this changes.
> >
> > Here is my understanding of the steps I need to do.
> >
> > 1. Make classlib/modules/portlib directory (or portlib in the root?)
> > and move hyprt, hysig and hythread code into it. Update build to work
> > with new directory.
> >
> > > [Andrey]- pull out hythread from classlib, make it a shared component
> >
> > 2. Move DRLVM hythread to classlib and update drlvm build for it. So
> > both classlib and drlvm will work on the drlvm hythread.
> >
> > > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> > > upper layer (hythead_xxx)
> > > - migrate classlib code to the bottom layer (1) of hythread
> > I do not think it is necessary because the hythread will be shared
> library.
> > This make sense only in case we move only layer(1) into the shared
> directory.
> >
> > 3. merge hythreads into one library getting bast code from both sources.
> > > migrate DRLVM's thread manager to (1) from APR
> > Will be done on this stage.
> >
> > 4. merge classlib and drlvm signal handling code.
> >
> > 5. merge port libs code.
> >
> > 6. ????
> >
> > Thanks
> > Artem
> >
> > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >
> > > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> > >
> > > > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >>
> > > >> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> > > >>
> > > >> > +1 on the below.
> > > >> >
> > > >> > I am assuming Andrey and his team will do this work. (Andrey,
> when
> > > >> > will you
> > > >> > start?)
> > > >>
> > > >> We have to start first by pulling hythread out, but where? After
> > > >> thinking about it for 5 more seconds, putting it on the top level
> > > >>
> > > >> enhanced/<something>
> > > >>
> > > >> is IMO a bad idea. There's nothing worse than going to a project's
> > > >> SVN and finding tons of confusing things.
> > > >
> > > > I agree making "thread" a standalone component at the level of
> > > > enhanced/<something> probably isn't worth doing. What may make a
> sense
> > > > is to consider thread a part of the portlib and make the portlib a
> > > > separate component at that level. Portlib is the only piece which is
> > > > shared between VM and classlib, this could justify it's appearance
> at
> > > > the high level.
> > > >
> > > >>
> > > >> Is there any downside to keeping it somewhere under /classlib/trunk
> > > >
> > > > My only guess would be the inability to build VM independently from
> > > > the classlib.
> > >
> > > Sure, you'll still need either to build the /portlib or the /classlib
> > >
> > > >
> > > >> and simply make it a module by itself?
> > > >
> > > > If we can not have a portlib as a high level component (like
> classlib
> > > > or drlvm), then at least having it as a separate module within
> > > > classlib would be nice.
> > >
> > > This is one of those things where doing the small step (do it in
> > > classlib) and then consider the large step (do it as a peer) seems to
> > > be reasonable, but i don't feel too strongly...
> > >
> > > geir
> > >
> > > >
> > > > Thanks,
> > > > Andrey.
> > > >
> > > >>
> > > >> >
> > > >> > Hopefully we can clean up how drlvm handles the classlib portlib
> > > >> > function
> > > >> > table at the same time. Currently two versions of this table are
> > > >> > created
> > > >> > during startup. "Portlib function table - let there be one!"
> > > >> > Seriously,
> > > >> > this is incredibly difficult code to maintain.
> > > >> >
> > > >> >
> > > >> > On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> > > >> >>
> > > >> >> Yes, exactly.
> > > >> >>
> > > >> >> Regards,
> > > >> >> Tim
> > > >> >>
> > > >> >> Andrey Chernyshev wrote:
> > > >> >> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > >> >> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> > > >> >> >>
> > > >> >> >> > Weldon, I agree with your comments and observations below.
> > > >> >> Let's
> > > >> >> take
> > > >> >> >> > baby steps to get fully unified. I'm sure we all want to
> > > >> >> keep things
> > > >> >> >> > working throughout.
> > > >> >> >>
> > > >> >> >> So what's the first stop? Move hythread as-is out of
> classlib
> > > >> >> to a
> > > >> >> >> peer in the tree?
> > > >> >> >
> > > >> >> > I can suggest the following steps:
> > > >> >> > - pull out hythread from classlib, make it a shared component
> > > >> >> > - split hythread, refine the bottom layer (thrdsup.h and
> > > >> >> mutex.h) and
> > > >> >> > upper layer (hythead_xxx)
> > > >> >> > - migrate classlib code to the bottom layer (1) of hythread
> > > >> >> > - migrate DRLVM's thread manager to (1) from APR
> > > >> >> > Each step can be done without breaking the whole code stack.
> > > >> >> > As a result, we'll have a bottom part of hythread which will
> be
> > > >> >> shared
> > > >> >> > between the classlib and DRLVM.
> > > >> >> >
> > > >> >> > Some additional steps could be:
> > > >> >> > - pull the rest of the portlib out of the classlib, make it a
> > > >> >> shared
> > > >> >> > component as well
> > > >> >> > - migrate DRLVM to portlib
> > > >> >> >
> > > >> >> > Thanks,
> > > >> >> > Andrey.
> > > >> >> >
> > > >> >> >
> > > >> >> >>
> > > >> >> >> geir
> > > >> >> >>
> > > >> >> >> >
> > > >> >> >> > Regards,
> > > >> >> >> > Tim
> > > >> >> >> >
> > > >> >> >> > Weldon Washburn wrote:
> > > >> >> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> > > >> >> >> >>>
> > > >> >> >> >>> Artem Aliev wrote:
> > > >> >> >> >>>> Gier,
> > > >> >> >> >>>>
> > > >> >> >> >>>> The hythread is just most visible example. There are
> also
> > > >> >> signal
> > > >> >> >> >>>> handling problem. classlib hysig lib setup signal
> handlers
> > > >> >> and
> > > >> >> then
> > > >> >> >> >>>> drlvm overrides them by its owns. There are code
> > > >> >> duplication in
> > > >> >> >> >>>> classlib hyprt.dll drlvm port.lib:
> > > >> >> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/
> > > >> port/src
> > > >> >> >> >>>>
> > > >> >> >> >>>> These three pair of components contains significant part
> > > >> >> of the
> > > >> >> >> >>>> system dependent code for both VM and CLASSLIB. I think,
> > > >> >> all this
> > > >> >> >> >>>> code naturally defines portlib component that could be
> > > >> shared
> > > >> >> >> >>>> between
> > > >> >> >> >>>> classlib and VMs. So, as a first step, we could move
> > > >> all this
> > > >> >> >> >>>> code in
> > > >> >> >> >>>> to the one place, name portlib to have three directories
> > > >> >> classlib,
> > > >> >> >> >>>> drlvm, portlib.
> > > >> >> >> >>>
> > > >> >> >> >>> I think it is quite reasonable to call out the portlib
> and
> > > >> >> threadlib
> > > >> >> >> >>> separate (in the repository) to the VM and classlib. As
> > > >> you
> > > >> >> >> >>> point out,
> > > >> >> >> >>> then VM and classlib can share the code -- though it
> > > >> will not
> > > >> >> >> >>> become a
> > > >> >> >> >>> requirement for VMs that run the harmony code to be using
> > > >> >> those
> > > >> >> >> >>> libraries for their own implementation.
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >> Tim,
> > > >> >> >> >> One of the things to worry about is system-wide lock
> > > >> >> protocol. We
> > > >> >> >> >> will
> > > >> >> >> >> need
> > > >> >> >> >> to think through what locks portlib, threadlib and JVM are
> > > >> >> holding
> > > >> >> >> >> and if
> > > >> >> >> >> there are any deadlock possibilities.
> > > >> >> >> >>
> > > >> >> >> >> Another issue is the implementation of signal chaining.
> > > >> There
> > > >> >> >> >> seems to be
> > > >> >> >> >> code in hysignal.c that implement "-Xrs". I guess the
> idea
> > > >> >> is that
> > > >> >> a
> > > >> >> >> >> Harmony JVM would somehow not link this code and use its
> own
> > > >> >> >> >> implementation. The bottom line is that we probably need
> to
> > > >> >> >> >> carefully pick
> > > >> >> >> >> through what is currently in classlib threads/signals and
> > > >> >> rearrange
> > > >> >> >> >> stuff so
> > > >> >> >> >> that it reduces the confusion. We need to make this part
> of
> > > >> >> the
> > > >> >> >> >> system
> > > >> >> >> >> much
> > > >> >> >> >> easier to work on.
> > > >> >> >> >>
> > > >> >> >> >> Do you have recommendations on next steps? Does it make
> > > >> >> sense to
> > > >> >> >> >> start
> > > >> >> >> >> moving stuff into the directories described above. Or is
> > > >> more
> > > >> >> >> >> discussion
> > > >> >> >> >> needed.
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >>> As the second step, the pairs of libraries should be
> merged
> > > >> >> and the
> > > >> >> >> >>>> classlib and drlvm refactoried to have only 3 lib
> instead
> > > >> >> of 6.
> > > >> >> >> >>>
> > > >> >> >> >>> Yep, this would be part of the consolidation into new
> > > >> >> Harmony top-
> > > >> >> >> >>> level
> > > >> >> >> >>> components. It makes sense that we share the same impl
> > > >> in the
> > > >> >> >> >>> project.
> > > >> >> >> >>>
> > > >> >> >> >>>> The 3rd step is to replace most of the functions with
> APR
> > > >> >> ones and
> > > >> >> >> >>>> move the rest of the code to the APR.
> > > >> >> >> >>>
> > > >> >> >> >>> I think it is quite well documented on this list that
> this
> > > >> >> should
> > > >> >> >> >>> not be
> > > >> >> >> >>> a goal.
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >> I agree we don't need to move classlib to APR provided
> that:
> > > >> >> >> >>
> > > >> >> >> >> 1)
> > > >> >> >> >> There is an easy to understand distinct seperation of the
> > > >> >> different
> > > >> >> >> >> threading/signals packages. In specific, we need to know
> > > >> which
> > > >> >> >> >> threading
> > > >> >> >> >> package is being called by DRLVM without ambiguity.
> > > >> >> >> >>
> > > >> >> >> >> 2)
> > > >> >> >> >> There is clear understanding of how JVM and classlib
> > > >> threading/
> > > >> >> >> >> signals
> > > >> >> >> >> interoperate.
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >> Regards,
> > > >> >> >> >>> Tim
> > > >> >> >> >>>
> > > >> >> >> >>>> Thoughts?
> > > >> >> >> >>>>
> > > >> >> >> >>>> Thanks
> > > >> >> >> >>>> Artem
> > > >> >> >> >>>>
> > > >> >> >> >>>>
> > > >> >> >> >>>>
> > > >> >> >> >>>>
> > > >> >> >> >>>>
> > > >> >> >> >>>>
> > > >> >> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> > > >> >> >> >>>>>
> > > >> >> >> >>>>>
> > > >> >> >> >>>>
> > > >> >> >> >>>>
> > > >> >>
> > > >> -------------------------------------------------------------------
> > > >> >> >> >>>> --
> > > >> >> >> >>>> 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
> > > >> >> >> >>>>
> > > >> >> >> >>>>
> > > >> >> >> >>>
> > > >> >> >> >>> --
> > > >> >> >> >>>
> > > >> >> >> >>> 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
> > > >> >> >> >>>
> > > >> >> >> >>>
> > > >> >> >> >>
> > > >> >> >> >>
> > > >> >> >> >
> > > >> >> >> > --
> > > >> >> >> >
> > > >> >> >> > 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
> > > >> >> >> >
> > > >> >> >>
> > > >> >> >>
> > > >> >> >>
> > > >> >>
> > > >>
> ---------------------------------------------------------------------
> > > >> >> >> 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
> > > >> >> >>
> > > >> >> >>
> > > >> >> >
> > > >> >> >
> > > >> >>
> > > >> >> --
> > > >> >>
> > > >> >> 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
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Weldon Washburn
> > > >> > 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
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > 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
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by Artem Aliev <ar...@gmail.com>.
Guys,
> 1. Make classlib/modules/portlib directory (or portlib in the root?)
> and move hyprt, hysig and hythread code into it. Update build to work
> with new directory.
>
> > [Andrey]- pull out hythread from classlib, make it a shared component
>
The first step is done in JIRA HARMONY-1843.
I move common, pool, port, thread, sig from luni to new component portlib.
The first idea was to move only port, thread, sig, but they depend on
common and pool libs. It looks natural to do not produce cyclic
dependencies among components, so I move these two also to portlib.
Unfortunately, this does not fully solve two stage luni building
process (build-native-core and build-native-secondary), but this is
another problem.
So If we are still committed on these reorganization, please review
and apply the patch.
A move_to_portlib.sh script create portlib directory structure and
move appropriate files from luni to portlib (by svn move).
A portlib_files.patch update build to works with new structure.
Thanks
Artem
On 9/29/06, Artem Aliev <ar...@gmail.com> wrote:
> Guys,
>
> Let me try to make this changes.
>
> Here is my understanding of the steps I need to do.
>
> 1. Make classlib/modules/portlib directory (or portlib in the root?)
> and move hyprt, hysig and hythread code into it. Update build to work
> with new directory.
>
> > [Andrey]- pull out hythread from classlib, make it a shared component
>
> 2. Move DRLVM hythread to classlib and update drlvm build for it. So
> both classlib and drlvm will work on the drlvm hythread.
>
> > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> > upper layer (hythead_xxx)
> > - migrate classlib code to the bottom layer (1) of hythread
> I do not think it is necessary because the hythread will be shared library.
> This make sense only in case we move only layer(1) into the shared directory.
>
> 3. merge hythreads into one library getting bast code from both sources.
> > migrate DRLVM's thread manager to (1) from APR
> Will be done on this stage.
>
> 4. merge classlib and drlvm signal handling code.
>
> 5. merge port libs code.
>
> 6. ????
>
> Thanks
> Artem
>
> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> > On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> >
> > > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >>
> > >> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> > >>
> > >> > +1 on the below.
> > >> >
> > >> > I am assuming Andrey and his team will do this work. (Andrey, when
> > >> > will you
> > >> > start?)
> > >>
> > >> We have to start first by pulling hythread out, but where? After
> > >> thinking about it for 5 more seconds, putting it on the top level
> > >>
> > >> enhanced/<something>
> > >>
> > >> is IMO a bad idea. There's nothing worse than going to a project's
> > >> SVN and finding tons of confusing things.
> > >
> > > I agree making "thread" a standalone component at the level of
> > > enhanced/<something> probably isn't worth doing. What may make a sense
> > > is to consider thread a part of the portlib and make the portlib a
> > > separate component at that level. Portlib is the only piece which is
> > > shared between VM and classlib, this could justify it's appearance at
> > > the high level.
> > >
> > >>
> > >> Is there any downside to keeping it somewhere under /classlib/trunk
> > >
> > > My only guess would be the inability to build VM independently from
> > > the classlib.
> >
> > Sure, you'll still need either to build the /portlib or the /classlib
> >
> > >
> > >> and simply make it a module by itself?
> > >
> > > If we can not have a portlib as a high level component (like classlib
> > > or drlvm), then at least having it as a separate module within
> > > classlib would be nice.
> >
> > This is one of those things where doing the small step (do it in
> > classlib) and then consider the large step (do it as a peer) seems to
> > be reasonable, but i don't feel too strongly...
> >
> > geir
> >
> > >
> > > Thanks,
> > > Andrey.
> > >
> > >>
> > >> >
> > >> > Hopefully we can clean up how drlvm handles the classlib portlib
> > >> > function
> > >> > table at the same time. Currently two versions of this table are
> > >> > created
> > >> > during startup. "Portlib function table - let there be one!"
> > >> > Seriously,
> > >> > this is incredibly difficult code to maintain.
> > >> >
> > >> >
> > >> > On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> > >> >>
> > >> >> Yes, exactly.
> > >> >>
> > >> >> Regards,
> > >> >> Tim
> > >> >>
> > >> >> Andrey Chernyshev wrote:
> > >> >> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> >> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> > >> >> >>
> > >> >> >> > Weldon, I agree with your comments and observations below.
> > >> >> Let's
> > >> >> take
> > >> >> >> > baby steps to get fully unified. I'm sure we all want to
> > >> >> keep things
> > >> >> >> > working throughout.
> > >> >> >>
> > >> >> >> So what's the first stop? Move hythread as-is out of classlib
> > >> >> to a
> > >> >> >> peer in the tree?
> > >> >> >
> > >> >> > I can suggest the following steps:
> > >> >> > - pull out hythread from classlib, make it a shared component
> > >> >> > - split hythread, refine the bottom layer (thrdsup.h and
> > >> >> mutex.h) and
> > >> >> > upper layer (hythead_xxx)
> > >> >> > - migrate classlib code to the bottom layer (1) of hythread
> > >> >> > - migrate DRLVM's thread manager to (1) from APR
> > >> >> > Each step can be done without breaking the whole code stack.
> > >> >> > As a result, we'll have a bottom part of hythread which will be
> > >> >> shared
> > >> >> > between the classlib and DRLVM.
> > >> >> >
> > >> >> > Some additional steps could be:
> > >> >> > - pull the rest of the portlib out of the classlib, make it a
> > >> >> shared
> > >> >> > component as well
> > >> >> > - migrate DRLVM to portlib
> > >> >> >
> > >> >> > Thanks,
> > >> >> > Andrey.
> > >> >> >
> > >> >> >
> > >> >> >>
> > >> >> >> geir
> > >> >> >>
> > >> >> >> >
> > >> >> >> > Regards,
> > >> >> >> > Tim
> > >> >> >> >
> > >> >> >> > Weldon Washburn wrote:
> > >> >> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> > >> >> >> >>>
> > >> >> >> >>> Artem Aliev wrote:
> > >> >> >> >>>> Gier,
> > >> >> >> >>>>
> > >> >> >> >>>> The hythread is just most visible example. There are also
> > >> >> signal
> > >> >> >> >>>> handling problem. classlib hysig lib setup signal handlers
> > >> >> and
> > >> >> then
> > >> >> >> >>>> drlvm overrides them by its owns. There are code
> > >> >> duplication in
> > >> >> >> >>>> classlib hyprt.dll drlvm port.lib:
> > >> >> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/
> > >> port/src
> > >> >> >> >>>>
> > >> >> >> >>>> These three pair of components contains significant part
> > >> >> of the
> > >> >> >> >>>> system dependent code for both VM and CLASSLIB. I think,
> > >> >> all this
> > >> >> >> >>>> code naturally defines portlib component that could be
> > >> shared
> > >> >> >> >>>> between
> > >> >> >> >>>> classlib and VMs. So, as a first step, we could move
> > >> all this
> > >> >> >> >>>> code in
> > >> >> >> >>>> to the one place, name portlib to have three directories
> > >> >> classlib,
> > >> >> >> >>>> drlvm, portlib.
> > >> >> >> >>>
> > >> >> >> >>> I think it is quite reasonable to call out the portlib and
> > >> >> threadlib
> > >> >> >> >>> separate (in the repository) to the VM and classlib. As
> > >> you
> > >> >> >> >>> point out,
> > >> >> >> >>> then VM and classlib can share the code -- though it
> > >> will not
> > >> >> >> >>> become a
> > >> >> >> >>> requirement for VMs that run the harmony code to be using
> > >> >> those
> > >> >> >> >>> libraries for their own implementation.
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >> Tim,
> > >> >> >> >> One of the things to worry about is system-wide lock
> > >> >> protocol. We
> > >> >> >> >> will
> > >> >> >> >> need
> > >> >> >> >> to think through what locks portlib, threadlib and JVM are
> > >> >> holding
> > >> >> >> >> and if
> > >> >> >> >> there are any deadlock possibilities.
> > >> >> >> >>
> > >> >> >> >> Another issue is the implementation of signal chaining.
> > >> There
> > >> >> >> >> seems to be
> > >> >> >> >> code in hysignal.c that implement "-Xrs". I guess the idea
> > >> >> is that
> > >> >> a
> > >> >> >> >> Harmony JVM would somehow not link this code and use its own
> > >> >> >> >> implementation. The bottom line is that we probably need to
> > >> >> >> >> carefully pick
> > >> >> >> >> through what is currently in classlib threads/signals and
> > >> >> rearrange
> > >> >> >> >> stuff so
> > >> >> >> >> that it reduces the confusion. We need to make this part of
> > >> >> the
> > >> >> >> >> system
> > >> >> >> >> much
> > >> >> >> >> easier to work on.
> > >> >> >> >>
> > >> >> >> >> Do you have recommendations on next steps? Does it make
> > >> >> sense to
> > >> >> >> >> start
> > >> >> >> >> moving stuff into the directories described above. Or is
> > >> more
> > >> >> >> >> discussion
> > >> >> >> >> needed.
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >>> As the second step, the pairs of libraries should be merged
> > >> >> and the
> > >> >> >> >>>> classlib and drlvm refactoried to have only 3 lib instead
> > >> >> of 6.
> > >> >> >> >>>
> > >> >> >> >>> Yep, this would be part of the consolidation into new
> > >> >> Harmony top-
> > >> >> >> >>> level
> > >> >> >> >>> components. It makes sense that we share the same impl
> > >> in the
> > >> >> >> >>> project.
> > >> >> >> >>>
> > >> >> >> >>>> The 3rd step is to replace most of the functions with APR
> > >> >> ones and
> > >> >> >> >>>> move the rest of the code to the APR.
> > >> >> >> >>>
> > >> >> >> >>> I think it is quite well documented on this list that this
> > >> >> should
> > >> >> >> >>> not be
> > >> >> >> >>> a goal.
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >> I agree we don't need to move classlib to APR provided that:
> > >> >> >> >>
> > >> >> >> >> 1)
> > >> >> >> >> There is an easy to understand distinct seperation of the
> > >> >> different
> > >> >> >> >> threading/signals packages. In specific, we need to know
> > >> which
> > >> >> >> >> threading
> > >> >> >> >> package is being called by DRLVM without ambiguity.
> > >> >> >> >>
> > >> >> >> >> 2)
> > >> >> >> >> There is clear understanding of how JVM and classlib
> > >> threading/
> > >> >> >> >> signals
> > >> >> >> >> interoperate.
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >> Regards,
> > >> >> >> >>> Tim
> > >> >> >> >>>
> > >> >> >> >>>> Thoughts?
> > >> >> >> >>>>
> > >> >> >> >>>> Thanks
> > >> >> >> >>>> Artem
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> > >> >> >> >>>>>
> > >> >> >> >>>>>
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >>
> > >> -------------------------------------------------------------------
> > >> >> >> >>>> --
> > >> >> >> >>>> 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
> > >> >> >> >>>>
> > >> >> >> >>>>
> > >> >> >> >>>
> > >> >> >> >>> --
> > >> >> >> >>>
> > >> >> >> >>> 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
> > >> >> >> >>>
> > >> >> >> >>>
> > >> >> >> >>
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> > --
> > >> >> >> >
> > >> >> >> > 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
> > >> >> >> >
> > >> >> >>
> > >> >> >>
> > >> >> >>
> > >> >>
> > >> ---------------------------------------------------------------------
> > >> >> >> 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
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >>
> > >> >> --
> > >> >>
> > >> >> 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
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > Weldon Washburn
> > >> > 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
> > >>
> > >>
> > >
> > >
> > > --
> > > 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Artem Aliev <ar...@gmail.com>.
Guys,
Let me try to make this changes.
Here is my understanding of the steps I need to do.
1. Make classlib/modules/portlib directory (or portlib in the root?)
and move hyprt, hysig and hythread code into it. Update build to work
with new directory.
> [Andrey]- pull out hythread from classlib, make it a shared component
2. Move DRLVM hythread to classlib and update drlvm build for it. So
both classlib and drlvm will work on the drlvm hythread.
> - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> upper layer (hythead_xxx)
> - migrate classlib code to the bottom layer (1) of hythread
I do not think it is necessary because the hythread will be shared library.
This make sense only in case we move only layer(1) into the shared directory.
3. merge hythreads into one library getting bast code from both sources.
> migrate DRLVM's thread manager to (1) from APR
Will be done on this stage.
4. merge classlib and drlvm signal handling code.
5. merge port libs code.
6. ????
Thanks
Artem
On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
>
> > On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>
> >> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> >>
> >> > +1 on the below.
> >> >
> >> > I am assuming Andrey and his team will do this work. (Andrey, when
> >> > will you
> >> > start?)
> >>
> >> We have to start first by pulling hythread out, but where? After
> >> thinking about it for 5 more seconds, putting it on the top level
> >>
> >> enhanced/<something>
> >>
> >> is IMO a bad idea. There's nothing worse than going to a project's
> >> SVN and finding tons of confusing things.
> >
> > I agree making "thread" a standalone component at the level of
> > enhanced/<something> probably isn't worth doing. What may make a sense
> > is to consider thread a part of the portlib and make the portlib a
> > separate component at that level. Portlib is the only piece which is
> > shared between VM and classlib, this could justify it's appearance at
> > the high level.
> >
> >>
> >> Is there any downside to keeping it somewhere under /classlib/trunk
> >
> > My only guess would be the inability to build VM independently from
> > the classlib.
>
> Sure, you'll still need either to build the /portlib or the /classlib
>
> >
> >> and simply make it a module by itself?
> >
> > If we can not have a portlib as a high level component (like classlib
> > or drlvm), then at least having it as a separate module within
> > classlib would be nice.
>
> This is one of those things where doing the small step (do it in
> classlib) and then consider the large step (do it as a peer) seems to
> be reasonable, but i don't feel too strongly...
>
> geir
>
> >
> > Thanks,
> > Andrey.
> >
> >>
> >> >
> >> > Hopefully we can clean up how drlvm handles the classlib portlib
> >> > function
> >> > table at the same time. Currently two versions of this table are
> >> > created
> >> > during startup. "Portlib function table - let there be one!"
> >> > Seriously,
> >> > this is incredibly difficult code to maintain.
> >> >
> >> >
> >> > On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> >> >>
> >> >> Yes, exactly.
> >> >>
> >> >> Regards,
> >> >> Tim
> >> >>
> >> >> Andrey Chernyshev wrote:
> >> >> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> >> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> >> >> >>
> >> >> >> > Weldon, I agree with your comments and observations below.
> >> >> Let's
> >> >> take
> >> >> >> > baby steps to get fully unified. I'm sure we all want to
> >> >> keep things
> >> >> >> > working throughout.
> >> >> >>
> >> >> >> So what's the first stop? Move hythread as-is out of classlib
> >> >> to a
> >> >> >> peer in the tree?
> >> >> >
> >> >> > I can suggest the following steps:
> >> >> > - pull out hythread from classlib, make it a shared component
> >> >> > - split hythread, refine the bottom layer (thrdsup.h and
> >> >> mutex.h) and
> >> >> > upper layer (hythead_xxx)
> >> >> > - migrate classlib code to the bottom layer (1) of hythread
> >> >> > - migrate DRLVM's thread manager to (1) from APR
> >> >> > Each step can be done without breaking the whole code stack.
> >> >> > As a result, we'll have a bottom part of hythread which will be
> >> >> shared
> >> >> > between the classlib and DRLVM.
> >> >> >
> >> >> > Some additional steps could be:
> >> >> > - pull the rest of the portlib out of the classlib, make it a
> >> >> shared
> >> >> > component as well
> >> >> > - migrate DRLVM to portlib
> >> >> >
> >> >> > Thanks,
> >> >> > Andrey.
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> geir
> >> >> >>
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> > Tim
> >> >> >> >
> >> >> >> > Weldon Washburn wrote:
> >> >> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> >> >> >> >>>
> >> >> >> >>> Artem Aliev wrote:
> >> >> >> >>>> Gier,
> >> >> >> >>>>
> >> >> >> >>>> The hythread is just most visible example. There are also
> >> >> signal
> >> >> >> >>>> handling problem. classlib hysig lib setup signal handlers
> >> >> and
> >> >> then
> >> >> >> >>>> drlvm overrides them by its owns. There are code
> >> >> duplication in
> >> >> >> >>>> classlib hyprt.dll drlvm port.lib:
> >> >> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/
> >> port/src
> >> >> >> >>>>
> >> >> >> >>>> These three pair of components contains significant part
> >> >> of the
> >> >> >> >>>> system dependent code for both VM and CLASSLIB. I think,
> >> >> all this
> >> >> >> >>>> code naturally defines portlib component that could be
> >> shared
> >> >> >> >>>> between
> >> >> >> >>>> classlib and VMs. So, as a first step, we could move
> >> all this
> >> >> >> >>>> code in
> >> >> >> >>>> to the one place, name portlib to have three directories
> >> >> classlib,
> >> >> >> >>>> drlvm, portlib.
> >> >> >> >>>
> >> >> >> >>> I think it is quite reasonable to call out the portlib and
> >> >> threadlib
> >> >> >> >>> separate (in the repository) to the VM and classlib. As
> >> you
> >> >> >> >>> point out,
> >> >> >> >>> then VM and classlib can share the code -- though it
> >> will not
> >> >> >> >>> become a
> >> >> >> >>> requirement for VMs that run the harmony code to be using
> >> >> those
> >> >> >> >>> libraries for their own implementation.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Tim,
> >> >> >> >> One of the things to worry about is system-wide lock
> >> >> protocol. We
> >> >> >> >> will
> >> >> >> >> need
> >> >> >> >> to think through what locks portlib, threadlib and JVM are
> >> >> holding
> >> >> >> >> and if
> >> >> >> >> there are any deadlock possibilities.
> >> >> >> >>
> >> >> >> >> Another issue is the implementation of signal chaining.
> >> There
> >> >> >> >> seems to be
> >> >> >> >> code in hysignal.c that implement "-Xrs". I guess the idea
> >> >> is that
> >> >> a
> >> >> >> >> Harmony JVM would somehow not link this code and use its own
> >> >> >> >> implementation. The bottom line is that we probably need to
> >> >> >> >> carefully pick
> >> >> >> >> through what is currently in classlib threads/signals and
> >> >> rearrange
> >> >> >> >> stuff so
> >> >> >> >> that it reduces the confusion. We need to make this part of
> >> >> the
> >> >> >> >> system
> >> >> >> >> much
> >> >> >> >> easier to work on.
> >> >> >> >>
> >> >> >> >> Do you have recommendations on next steps? Does it make
> >> >> sense to
> >> >> >> >> start
> >> >> >> >> moving stuff into the directories described above. Or is
> >> more
> >> >> >> >> discussion
> >> >> >> >> needed.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>> As the second step, the pairs of libraries should be merged
> >> >> and the
> >> >> >> >>>> classlib and drlvm refactoried to have only 3 lib instead
> >> >> of 6.
> >> >> >> >>>
> >> >> >> >>> Yep, this would be part of the consolidation into new
> >> >> Harmony top-
> >> >> >> >>> level
> >> >> >> >>> components. It makes sense that we share the same impl
> >> in the
> >> >> >> >>> project.
> >> >> >> >>>
> >> >> >> >>>> The 3rd step is to replace most of the functions with APR
> >> >> ones and
> >> >> >> >>>> move the rest of the code to the APR.
> >> >> >> >>>
> >> >> >> >>> I think it is quite well documented on this list that this
> >> >> should
> >> >> >> >>> not be
> >> >> >> >>> a goal.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> I agree we don't need to move classlib to APR provided that:
> >> >> >> >>
> >> >> >> >> 1)
> >> >> >> >> There is an easy to understand distinct seperation of the
> >> >> different
> >> >> >> >> threading/signals packages. In specific, we need to know
> >> which
> >> >> >> >> threading
> >> >> >> >> package is being called by DRLVM without ambiguity.
> >> >> >> >>
> >> >> >> >> 2)
> >> >> >> >> There is clear understanding of how JVM and classlib
> >> threading/
> >> >> >> >> signals
> >> >> >> >> interoperate.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Regards,
> >> >> >> >>> Tim
> >> >> >> >>>
> >> >> >> >>>> Thoughts?
> >> >> >> >>>>
> >> >> >> >>>> Thanks
> >> >> >> >>>> Artem
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> >> >> >> >>>>>
> >> >> >> >>>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >>
> >> -------------------------------------------------------------------
> >> >> >> >>>> --
> >> >> >> >>>> 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
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>
> >> >> >> >>> --
> >> >> >> >>>
> >> >> >> >>> 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
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> > --
> >> >> >> >
> >> >> >> > 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
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> 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
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >>
> >> >> 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
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Weldon Washburn
> >> > 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
> >>
> >>
> >
> >
> > --
> > 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
> >
>
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 28, 2006, at 10:30 AM, Andrey Chernyshev wrote:
> On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
>>
>> > +1 on the below.
>> >
>> > I am assuming Andrey and his team will do this work. (Andrey, when
>> > will you
>> > start?)
>>
>> We have to start first by pulling hythread out, but where? After
>> thinking about it for 5 more seconds, putting it on the top level
>>
>> enhanced/<something>
>>
>> is IMO a bad idea. There's nothing worse than going to a project's
>> SVN and finding tons of confusing things.
>
> I agree making "thread" a standalone component at the level of
> enhanced/<something> probably isn't worth doing. What may make a sense
> is to consider thread a part of the portlib and make the portlib a
> separate component at that level. Portlib is the only piece which is
> shared between VM and classlib, this could justify it's appearance at
> the high level.
>
>>
>> Is there any downside to keeping it somewhere under /classlib/trunk
>
> My only guess would be the inability to build VM independently from
> the classlib.
Sure, you'll still need either to build the /portlib or the /classlib
>
>> and simply make it a module by itself?
>
> If we can not have a portlib as a high level component (like classlib
> or drlvm), then at least having it as a separate module within
> classlib would be nice.
This is one of those things where doing the small step (do it in
classlib) and then consider the large step (do it as a peer) seems to
be reasonable, but i don't feel too strongly...
geir
>
> Thanks,
> Andrey.
>
>>
>> >
>> > Hopefully we can clean up how drlvm handles the classlib portlib
>> > function
>> > table at the same time. Currently two versions of this table are
>> > created
>> > during startup. "Portlib function table - let there be one!"
>> > Seriously,
>> > this is incredibly difficult code to maintain.
>> >
>> >
>> > On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
>> >>
>> >> Yes, exactly.
>> >>
>> >> Regards,
>> >> Tim
>> >>
>> >> Andrey Chernyshev wrote:
>> >> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
>> >> >>
>> >> >> > Weldon, I agree with your comments and observations below.
>> >> Let's
>> >> take
>> >> >> > baby steps to get fully unified. I'm sure we all want to
>> >> keep things
>> >> >> > working throughout.
>> >> >>
>> >> >> So what's the first stop? Move hythread as-is out of classlib
>> >> to a
>> >> >> peer in the tree?
>> >> >
>> >> > I can suggest the following steps:
>> >> > - pull out hythread from classlib, make it a shared component
>> >> > - split hythread, refine the bottom layer (thrdsup.h and
>> >> mutex.h) and
>> >> > upper layer (hythead_xxx)
>> >> > - migrate classlib code to the bottom layer (1) of hythread
>> >> > - migrate DRLVM's thread manager to (1) from APR
>> >> > Each step can be done without breaking the whole code stack.
>> >> > As a result, we'll have a bottom part of hythread which will be
>> >> shared
>> >> > between the classlib and DRLVM.
>> >> >
>> >> > Some additional steps could be:
>> >> > - pull the rest of the portlib out of the classlib, make it a
>> >> shared
>> >> > component as well
>> >> > - migrate DRLVM to portlib
>> >> >
>> >> > Thanks,
>> >> > Andrey.
>> >> >
>> >> >
>> >> >>
>> >> >> geir
>> >> >>
>> >> >> >
>> >> >> > Regards,
>> >> >> > Tim
>> >> >> >
>> >> >> > Weldon Washburn wrote:
>> >> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> Artem Aliev wrote:
>> >> >> >>>> Gier,
>> >> >> >>>>
>> >> >> >>>> The hythread is just most visible example. There are also
>> >> signal
>> >> >> >>>> handling problem. classlib hysig lib setup signal handlers
>> >> and
>> >> then
>> >> >> >>>> drlvm overrides them by its owns. There are code
>> >> duplication in
>> >> >> >>>> classlib hyprt.dll drlvm port.lib:
>> >> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/
>> port/src
>> >> >> >>>>
>> >> >> >>>> These three pair of components contains significant part
>> >> of the
>> >> >> >>>> system dependent code for both VM and CLASSLIB. I think,
>> >> all this
>> >> >> >>>> code naturally defines portlib component that could be
>> shared
>> >> >> >>>> between
>> >> >> >>>> classlib and VMs. So, as a first step, we could move
>> all this
>> >> >> >>>> code in
>> >> >> >>>> to the one place, name portlib to have three directories
>> >> classlib,
>> >> >> >>>> drlvm, portlib.
>> >> >> >>>
>> >> >> >>> I think it is quite reasonable to call out the portlib and
>> >> threadlib
>> >> >> >>> separate (in the repository) to the VM and classlib. As
>> you
>> >> >> >>> point out,
>> >> >> >>> then VM and classlib can share the code -- though it
>> will not
>> >> >> >>> become a
>> >> >> >>> requirement for VMs that run the harmony code to be using
>> >> those
>> >> >> >>> libraries for their own implementation.
>> >> >> >>
>> >> >> >>
>> >> >> >> Tim,
>> >> >> >> One of the things to worry about is system-wide lock
>> >> protocol. We
>> >> >> >> will
>> >> >> >> need
>> >> >> >> to think through what locks portlib, threadlib and JVM are
>> >> holding
>> >> >> >> and if
>> >> >> >> there are any deadlock possibilities.
>> >> >> >>
>> >> >> >> Another issue is the implementation of signal chaining.
>> There
>> >> >> >> seems to be
>> >> >> >> code in hysignal.c that implement "-Xrs". I guess the idea
>> >> is that
>> >> a
>> >> >> >> Harmony JVM would somehow not link this code and use its own
>> >> >> >> implementation. The bottom line is that we probably need to
>> >> >> >> carefully pick
>> >> >> >> through what is currently in classlib threads/signals and
>> >> rearrange
>> >> >> >> stuff so
>> >> >> >> that it reduces the confusion. We need to make this part of
>> >> the
>> >> >> >> system
>> >> >> >> much
>> >> >> >> easier to work on.
>> >> >> >>
>> >> >> >> Do you have recommendations on next steps? Does it make
>> >> sense to
>> >> >> >> start
>> >> >> >> moving stuff into the directories described above. Or is
>> more
>> >> >> >> discussion
>> >> >> >> needed.
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>> As the second step, the pairs of libraries should be merged
>> >> and the
>> >> >> >>>> classlib and drlvm refactoried to have only 3 lib instead
>> >> of 6.
>> >> >> >>>
>> >> >> >>> Yep, this would be part of the consolidation into new
>> >> Harmony top-
>> >> >> >>> level
>> >> >> >>> components. It makes sense that we share the same impl
>> in the
>> >> >> >>> project.
>> >> >> >>>
>> >> >> >>>> The 3rd step is to replace most of the functions with APR
>> >> ones and
>> >> >> >>>> move the rest of the code to the APR.
>> >> >> >>>
>> >> >> >>> I think it is quite well documented on this list that this
>> >> should
>> >> >> >>> not be
>> >> >> >>> a goal.
>> >> >> >>
>> >> >> >>
>> >> >> >> I agree we don't need to move classlib to APR provided that:
>> >> >> >>
>> >> >> >> 1)
>> >> >> >> There is an easy to understand distinct seperation of the
>> >> different
>> >> >> >> threading/signals packages. In specific, we need to know
>> which
>> >> >> >> threading
>> >> >> >> package is being called by DRLVM without ambiguity.
>> >> >> >>
>> >> >> >> 2)
>> >> >> >> There is clear understanding of how JVM and classlib
>> threading/
>> >> >> >> signals
>> >> >> >> interoperate.
>> >> >> >>
>> >> >> >>
>> >> >> >> Regards,
>> >> >> >>> Tim
>> >> >> >>>
>> >> >> >>>> Thoughts?
>> >> >> >>>>
>> >> >> >>>> Thanks
>> >> >> >>>> Artem
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>
>> >> >> >>>>
>> >>
>> -------------------------------------------------------------------
>> >> >> >>>> --
>> >> >> >>>> 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
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>>
>> >> >> >>> 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
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> > --
>> >> >> >
>> >> >> > 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
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> ---------------------------------------------------------------------
>> >> >> 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
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >>
>> >> 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
>> >>
>> >>
>> >
>> >
>> > --
>> > Weldon Washburn
>> > 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
>>
>>
>
>
> --
> 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
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/28/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
>
> > +1 on the below.
> >
> > I am assuming Andrey and his team will do this work. (Andrey, when
> > will you
> > start?)
>
> We have to start first by pulling hythread out, but where? After
> thinking about it for 5 more seconds, putting it on the top level
>
> enhanced/<something>
>
> is IMO a bad idea. There's nothing worse than going to a project's
> SVN and finding tons of confusing things.
I agree making "thread" a standalone component at the level of
enhanced/<something> probably isn't worth doing. What may make a sense
is to consider thread a part of the portlib and make the portlib a
separate component at that level. Portlib is the only piece which is
shared between VM and classlib, this could justify it's appearance at
the high level.
>
> Is there any downside to keeping it somewhere under /classlib/trunk
My only guess would be the inability to build VM independently from
the classlib.
> and simply make it a module by itself?
If we can not have a portlib as a high level component (like classlib
or drlvm), then at least having it as a separate module within
classlib would be nice.
Thanks,
Andrey.
>
> >
> > Hopefully we can clean up how drlvm handles the classlib portlib
> > function
> > table at the same time. Currently two versions of this table are
> > created
> > during startup. "Portlib function table - let there be one!"
> > Seriously,
> > this is incredibly difficult code to maintain.
> >
> >
> > On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> >>
> >> Yes, exactly.
> >>
> >> Regards,
> >> Tim
> >>
> >> Andrey Chernyshev wrote:
> >> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> >> >>
> >> >> > Weldon, I agree with your comments and observations below.
> >> Let's
> >> take
> >> >> > baby steps to get fully unified. I'm sure we all want to
> >> keep things
> >> >> > working throughout.
> >> >>
> >> >> So what's the first stop? Move hythread as-is out of classlib
> >> to a
> >> >> peer in the tree?
> >> >
> >> > I can suggest the following steps:
> >> > - pull out hythread from classlib, make it a shared component
> >> > - split hythread, refine the bottom layer (thrdsup.h and
> >> mutex.h) and
> >> > upper layer (hythead_xxx)
> >> > - migrate classlib code to the bottom layer (1) of hythread
> >> > - migrate DRLVM's thread manager to (1) from APR
> >> > Each step can be done without breaking the whole code stack.
> >> > As a result, we'll have a bottom part of hythread which will be
> >> shared
> >> > between the classlib and DRLVM.
> >> >
> >> > Some additional steps could be:
> >> > - pull the rest of the portlib out of the classlib, make it a
> >> shared
> >> > component as well
> >> > - migrate DRLVM to portlib
> >> >
> >> > Thanks,
> >> > Andrey.
> >> >
> >> >
> >> >>
> >> >> geir
> >> >>
> >> >> >
> >> >> > Regards,
> >> >> > Tim
> >> >> >
> >> >> > Weldon Washburn wrote:
> >> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> >> >> >>>
> >> >> >>> Artem Aliev wrote:
> >> >> >>>> Gier,
> >> >> >>>>
> >> >> >>>> The hythread is just most visible example. There are also
> >> signal
> >> >> >>>> handling problem. classlib hysig lib setup signal handlers
> >> and
> >> then
> >> >> >>>> drlvm overrides them by its owns. There are code
> >> duplication in
> >> >> >>>> classlib hyprt.dll drlvm port.lib:
> >> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/port/src
> >> >> >>>>
> >> >> >>>> These three pair of components contains significant part
> >> of the
> >> >> >>>> system dependent code for both VM and CLASSLIB. I think,
> >> all this
> >> >> >>>> code naturally defines portlib component that could be shared
> >> >> >>>> between
> >> >> >>>> classlib and VMs. So, as a first step, we could move all this
> >> >> >>>> code in
> >> >> >>>> to the one place, name portlib to have three directories
> >> classlib,
> >> >> >>>> drlvm, portlib.
> >> >> >>>
> >> >> >>> I think it is quite reasonable to call out the portlib and
> >> threadlib
> >> >> >>> separate (in the repository) to the VM and classlib. As you
> >> >> >>> point out,
> >> >> >>> then VM and classlib can share the code -- though it will not
> >> >> >>> become a
> >> >> >>> requirement for VMs that run the harmony code to be using
> >> those
> >> >> >>> libraries for their own implementation.
> >> >> >>
> >> >> >>
> >> >> >> Tim,
> >> >> >> One of the things to worry about is system-wide lock
> >> protocol. We
> >> >> >> will
> >> >> >> need
> >> >> >> to think through what locks portlib, threadlib and JVM are
> >> holding
> >> >> >> and if
> >> >> >> there are any deadlock possibilities.
> >> >> >>
> >> >> >> Another issue is the implementation of signal chaining. There
> >> >> >> seems to be
> >> >> >> code in hysignal.c that implement "-Xrs". I guess the idea
> >> is that
> >> a
> >> >> >> Harmony JVM would somehow not link this code and use its own
> >> >> >> implementation. The bottom line is that we probably need to
> >> >> >> carefully pick
> >> >> >> through what is currently in classlib threads/signals and
> >> rearrange
> >> >> >> stuff so
> >> >> >> that it reduces the confusion. We need to make this part of
> >> the
> >> >> >> system
> >> >> >> much
> >> >> >> easier to work on.
> >> >> >>
> >> >> >> Do you have recommendations on next steps? Does it make
> >> sense to
> >> >> >> start
> >> >> >> moving stuff into the directories described above. Or is more
> >> >> >> discussion
> >> >> >> needed.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>> As the second step, the pairs of libraries should be merged
> >> and the
> >> >> >>>> classlib and drlvm refactoried to have only 3 lib instead
> >> of 6.
> >> >> >>>
> >> >> >>> Yep, this would be part of the consolidation into new
> >> Harmony top-
> >> >> >>> level
> >> >> >>> components. It makes sense that we share the same impl in the
> >> >> >>> project.
> >> >> >>>
> >> >> >>>> The 3rd step is to replace most of the functions with APR
> >> ones and
> >> >> >>>> move the rest of the code to the APR.
> >> >> >>>
> >> >> >>> I think it is quite well documented on this list that this
> >> should
> >> >> >>> not be
> >> >> >>> a goal.
> >> >> >>
> >> >> >>
> >> >> >> I agree we don't need to move classlib to APR provided that:
> >> >> >>
> >> >> >> 1)
> >> >> >> There is an easy to understand distinct seperation of the
> >> different
> >> >> >> threading/signals packages. In specific, we need to know which
> >> >> >> threading
> >> >> >> package is being called by DRLVM without ambiguity.
> >> >> >>
> >> >> >> 2)
> >> >> >> There is clear understanding of how JVM and classlib threading/
> >> >> >> signals
> >> >> >> interoperate.
> >> >> >>
> >> >> >>
> >> >> >> Regards,
> >> >> >>> Tim
> >> >> >>>
> >> >> >>>> Thoughts?
> >> >> >>>>
> >> >> >>>> Thanks
> >> >> >>>> Artem
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>>>
> >> -------------------------------------------------------------------
> >> >> >>>> --
> >> >> >>>> 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
> >> >> >>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>> --
> >> >> >>>
> >> >> >>> 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
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> > --
> >> >> >
> >> >> > 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
> >> >> >
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> 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
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >>
> >> 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
> >>
> >>
> >
> >
> > --
> > Weldon Washburn
> > 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
>
>
--
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 27, 2006, at 11:31 AM, Weldon Washburn wrote:
> +1 on the below.
>
> I am assuming Andrey and his team will do this work. (Andrey, when
> will you
> start?)
We have to start first by pulling hythread out, but where? After
thinking about it for 5 more seconds, putting it on the top level
enhanced/<something>
is IMO a bad idea. There's nothing worse than going to a project's
SVN and finding tons of confusing things.
Is there any downside to keeping it somewhere under /classlib/trunk
and simply make it a module by itself?
>
> Hopefully we can clean up how drlvm handles the classlib portlib
> function
> table at the same time. Currently two versions of this table are
> created
> during startup. "Portlib function table - let there be one!"
> Seriously,
> this is incredibly difficult code to maintain.
>
>
> On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
>>
>> Yes, exactly.
>>
>> Regards,
>> Tim
>>
>> Andrey Chernyshev wrote:
>> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
>> >>
>> >> > Weldon, I agree with your comments and observations below.
>> Let's
>> take
>> >> > baby steps to get fully unified. I'm sure we all want to
>> keep things
>> >> > working throughout.
>> >>
>> >> So what's the first stop? Move hythread as-is out of classlib
>> to a
>> >> peer in the tree?
>> >
>> > I can suggest the following steps:
>> > - pull out hythread from classlib, make it a shared component
>> > - split hythread, refine the bottom layer (thrdsup.h and
>> mutex.h) and
>> > upper layer (hythead_xxx)
>> > - migrate classlib code to the bottom layer (1) of hythread
>> > - migrate DRLVM's thread manager to (1) from APR
>> > Each step can be done without breaking the whole code stack.
>> > As a result, we'll have a bottom part of hythread which will be
>> shared
>> > between the classlib and DRLVM.
>> >
>> > Some additional steps could be:
>> > - pull the rest of the portlib out of the classlib, make it a
>> shared
>> > component as well
>> > - migrate DRLVM to portlib
>> >
>> > Thanks,
>> > Andrey.
>> >
>> >
>> >>
>> >> geir
>> >>
>> >> >
>> >> > Regards,
>> >> > Tim
>> >> >
>> >> > Weldon Washburn wrote:
>> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>> >> >>>
>> >> >>> Artem Aliev wrote:
>> >> >>>> Gier,
>> >> >>>>
>> >> >>>> The hythread is just most visible example. There are also
>> signal
>> >> >>>> handling problem. classlib hysig lib setup signal handlers
>> and
>> then
>> >> >>>> drlvm overrides them by its owns. There are code
>> duplication in
>> >> >>>> classlib hyprt.dll drlvm port.lib:
>> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/port/src
>> >> >>>>
>> >> >>>> These three pair of components contains significant part
>> of the
>> >> >>>> system dependent code for both VM and CLASSLIB. I think,
>> all this
>> >> >>>> code naturally defines portlib component that could be shared
>> >> >>>> between
>> >> >>>> classlib and VMs. So, as a first step, we could move all this
>> >> >>>> code in
>> >> >>>> to the one place, name portlib to have three directories
>> classlib,
>> >> >>>> drlvm, portlib.
>> >> >>>
>> >> >>> I think it is quite reasonable to call out the portlib and
>> threadlib
>> >> >>> separate (in the repository) to the VM and classlib. As you
>> >> >>> point out,
>> >> >>> then VM and classlib can share the code -- though it will not
>> >> >>> become a
>> >> >>> requirement for VMs that run the harmony code to be using
>> those
>> >> >>> libraries for their own implementation.
>> >> >>
>> >> >>
>> >> >> Tim,
>> >> >> One of the things to worry about is system-wide lock
>> protocol. We
>> >> >> will
>> >> >> need
>> >> >> to think through what locks portlib, threadlib and JVM are
>> holding
>> >> >> and if
>> >> >> there are any deadlock possibilities.
>> >> >>
>> >> >> Another issue is the implementation of signal chaining. There
>> >> >> seems to be
>> >> >> code in hysignal.c that implement "-Xrs". I guess the idea
>> is that
>> a
>> >> >> Harmony JVM would somehow not link this code and use its own
>> >> >> implementation. The bottom line is that we probably need to
>> >> >> carefully pick
>> >> >> through what is currently in classlib threads/signals and
>> rearrange
>> >> >> stuff so
>> >> >> that it reduces the confusion. We need to make this part of
>> the
>> >> >> system
>> >> >> much
>> >> >> easier to work on.
>> >> >>
>> >> >> Do you have recommendations on next steps? Does it make
>> sense to
>> >> >> start
>> >> >> moving stuff into the directories described above. Or is more
>> >> >> discussion
>> >> >> needed.
>> >> >>
>> >> >>
>> >> >>
>> >> >>> As the second step, the pairs of libraries should be merged
>> and the
>> >> >>>> classlib and drlvm refactoried to have only 3 lib instead
>> of 6.
>> >> >>>
>> >> >>> Yep, this would be part of the consolidation into new
>> Harmony top-
>> >> >>> level
>> >> >>> components. It makes sense that we share the same impl in the
>> >> >>> project.
>> >> >>>
>> >> >>>> The 3rd step is to replace most of the functions with APR
>> ones and
>> >> >>>> move the rest of the code to the APR.
>> >> >>>
>> >> >>> I think it is quite well documented on this list that this
>> should
>> >> >>> not be
>> >> >>> a goal.
>> >> >>
>> >> >>
>> >> >> I agree we don't need to move classlib to APR provided that:
>> >> >>
>> >> >> 1)
>> >> >> There is an easy to understand distinct seperation of the
>> different
>> >> >> threading/signals packages. In specific, we need to know which
>> >> >> threading
>> >> >> package is being called by DRLVM without ambiguity.
>> >> >>
>> >> >> 2)
>> >> >> There is clear understanding of how JVM and classlib threading/
>> >> >> signals
>> >> >> interoperate.
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >>> Tim
>> >> >>>
>> >> >>>> Thoughts?
>> >> >>>>
>> >> >>>> Thanks
>> >> >>>> Artem
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> -------------------------------------------------------------------
>> >> >>>> --
>> >> >>>> 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
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>> --
>> >> >>>
>> >> >>> 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
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> > --
>> >> >
>> >> > 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
>> >> >
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> 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
>> >>
>> >>
>> >
>> >
>>
>> --
>>
>> 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
>>
>>
>
>
> --
> Weldon Washburn
> 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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Weldon Washburn <we...@gmail.com>.
+1 on the below.
I am assuming Andrey and his team will do this work. (Andrey, when will you
start?)
Hopefully we can clean up how drlvm handles the classlib portlib function
table at the same time. Currently two versions of this table are created
during startup. "Portlib function table - let there be one!" Seriously,
this is incredibly difficult code to maintain.
On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
>
> Yes, exactly.
>
> Regards,
> Tim
>
> Andrey Chernyshev wrote:
> > On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> >>
> >> > Weldon, I agree with your comments and observations below. Let's
> take
> >> > baby steps to get fully unified. I'm sure we all want to keep things
> >> > working throughout.
> >>
> >> So what's the first stop? Move hythread as-is out of classlib to a
> >> peer in the tree?
> >
> > I can suggest the following steps:
> > - pull out hythread from classlib, make it a shared component
> > - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> > upper layer (hythead_xxx)
> > - migrate classlib code to the bottom layer (1) of hythread
> > - migrate DRLVM's thread manager to (1) from APR
> > Each step can be done without breaking the whole code stack.
> > As a result, we'll have a bottom part of hythread which will be shared
> > between the classlib and DRLVM.
> >
> > Some additional steps could be:
> > - pull the rest of the portlib out of the classlib, make it a shared
> > component as well
> > - migrate DRLVM to portlib
> >
> > Thanks,
> > Andrey.
> >
> >
> >>
> >> geir
> >>
> >> >
> >> > Regards,
> >> > Tim
> >> >
> >> > Weldon Washburn wrote:
> >> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> >> >>>
> >> >>> Artem Aliev wrote:
> >> >>>> Gier,
> >> >>>>
> >> >>>> The hythread is just most visible example. There are also signal
> >> >>>> handling problem. classlib hysig lib setup signal handlers and
> then
> >> >>>> drlvm overrides them by its owns. There are code duplication in
> >> >>>> classlib hyprt.dll drlvm port.lib:
> >> >>>> classlib/trunk/modules/luni/src/main/native/port vm/port/src
> >> >>>>
> >> >>>> These three pair of components contains significant part of the
> >> >>>> system dependent code for both VM and CLASSLIB. I think, all this
> >> >>>> code naturally defines portlib component that could be shared
> >> >>>> between
> >> >>>> classlib and VMs. So, as a first step, we could move all this
> >> >>>> code in
> >> >>>> to the one place, name portlib to have three directories classlib,
> >> >>>> drlvm, portlib.
> >> >>>
> >> >>> I think it is quite reasonable to call out the portlib and
> threadlib
> >> >>> separate (in the repository) to the VM and classlib. As you
> >> >>> point out,
> >> >>> then VM and classlib can share the code -- though it will not
> >> >>> become a
> >> >>> requirement for VMs that run the harmony code to be using those
> >> >>> libraries for their own implementation.
> >> >>
> >> >>
> >> >> Tim,
> >> >> One of the things to worry about is system-wide lock protocol. We
> >> >> will
> >> >> need
> >> >> to think through what locks portlib, threadlib and JVM are holding
> >> >> and if
> >> >> there are any deadlock possibilities.
> >> >>
> >> >> Another issue is the implementation of signal chaining. There
> >> >> seems to be
> >> >> code in hysignal.c that implement "-Xrs". I guess the idea is that
> a
> >> >> Harmony JVM would somehow not link this code and use its own
> >> >> implementation. The bottom line is that we probably need to
> >> >> carefully pick
> >> >> through what is currently in classlib threads/signals and rearrange
> >> >> stuff so
> >> >> that it reduces the confusion. We need to make this part of the
> >> >> system
> >> >> much
> >> >> easier to work on.
> >> >>
> >> >> Do you have recommendations on next steps? Does it make sense to
> >> >> start
> >> >> moving stuff into the directories described above. Or is more
> >> >> discussion
> >> >> needed.
> >> >>
> >> >>
> >> >>
> >> >>> As the second step, the pairs of libraries should be merged and the
> >> >>>> classlib and drlvm refactoried to have only 3 lib instead of 6.
> >> >>>
> >> >>> Yep, this would be part of the consolidation into new Harmony top-
> >> >>> level
> >> >>> components. It makes sense that we share the same impl in the
> >> >>> project.
> >> >>>
> >> >>>> The 3rd step is to replace most of the functions with APR ones and
> >> >>>> move the rest of the code to the APR.
> >> >>>
> >> >>> I think it is quite well documented on this list that this should
> >> >>> not be
> >> >>> a goal.
> >> >>
> >> >>
> >> >> I agree we don't need to move classlib to APR provided that:
> >> >>
> >> >> 1)
> >> >> There is an easy to understand distinct seperation of the different
> >> >> threading/signals packages. In specific, we need to know which
> >> >> threading
> >> >> package is being called by DRLVM without ambiguity.
> >> >>
> >> >> 2)
> >> >> There is clear understanding of how JVM and classlib threading/
> >> >> signals
> >> >> interoperate.
> >> >>
> >> >>
> >> >> Regards,
> >> >>> Tim
> >> >>>
> >> >>>> Thoughts?
> >> >>>>
> >> >>>> Thanks
> >> >>>> Artem
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> -------------------------------------------------------------------
> >> >>>> --
> >> >>>> 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
> >> >>>>
> >> >>>>
> >> >>>
> >> >>> --
> >> >>>
> >> >>> 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
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> > --
> >> >
> >> > 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
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >>
> >>
> >
> >
>
> --
>
> 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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by Tim Ellison <t....@gmail.com>.
Yes, exactly.
Regards,
Tim
Andrey Chernyshev wrote:
> On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
>>
>> > Weldon, I agree with your comments and observations below. Let's take
>> > baby steps to get fully unified. I'm sure we all want to keep things
>> > working throughout.
>>
>> So what's the first stop? Move hythread as-is out of classlib to a
>> peer in the tree?
>
> I can suggest the following steps:
> - pull out hythread from classlib, make it a shared component
> - split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
> upper layer (hythead_xxx)
> - migrate classlib code to the bottom layer (1) of hythread
> - migrate DRLVM's thread manager to (1) from APR
> Each step can be done without breaking the whole code stack.
> As a result, we'll have a bottom part of hythread which will be shared
> between the classlib and DRLVM.
>
> Some additional steps could be:
> - pull the rest of the portlib out of the classlib, make it a shared
> component as well
> - migrate DRLVM to portlib
>
> Thanks,
> Andrey.
>
>
>>
>> geir
>>
>> >
>> > Regards,
>> > Tim
>> >
>> > Weldon Washburn wrote:
>> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>> >>>
>> >>> Artem Aliev wrote:
>> >>>> Gier,
>> >>>>
>> >>>> The hythread is just most visible example. There are also signal
>> >>>> handling problem. classlib hysig lib setup signal handlers and then
>> >>>> drlvm overrides them by its owns. There are code duplication in
>> >>>> classlib hyprt.dll drlvm port.lib:
>> >>>> classlib/trunk/modules/luni/src/main/native/port vm/port/src
>> >>>>
>> >>>> These three pair of components contains significant part of the
>> >>>> system dependent code for both VM and CLASSLIB. I think, all this
>> >>>> code naturally defines portlib component that could be shared
>> >>>> between
>> >>>> classlib and VMs. So, as a first step, we could move all this
>> >>>> code in
>> >>>> to the one place, name portlib to have three directories classlib,
>> >>>> drlvm, portlib.
>> >>>
>> >>> I think it is quite reasonable to call out the portlib and threadlib
>> >>> separate (in the repository) to the VM and classlib. As you
>> >>> point out,
>> >>> then VM and classlib can share the code -- though it will not
>> >>> become a
>> >>> requirement for VMs that run the harmony code to be using those
>> >>> libraries for their own implementation.
>> >>
>> >>
>> >> Tim,
>> >> One of the things to worry about is system-wide lock protocol. We
>> >> will
>> >> need
>> >> to think through what locks portlib, threadlib and JVM are holding
>> >> and if
>> >> there are any deadlock possibilities.
>> >>
>> >> Another issue is the implementation of signal chaining. There
>> >> seems to be
>> >> code in hysignal.c that implement "-Xrs". I guess the idea is that a
>> >> Harmony JVM would somehow not link this code and use its own
>> >> implementation. The bottom line is that we probably need to
>> >> carefully pick
>> >> through what is currently in classlib threads/signals and rearrange
>> >> stuff so
>> >> that it reduces the confusion. We need to make this part of the
>> >> system
>> >> much
>> >> easier to work on.
>> >>
>> >> Do you have recommendations on next steps? Does it make sense to
>> >> start
>> >> moving stuff into the directories described above. Or is more
>> >> discussion
>> >> needed.
>> >>
>> >>
>> >>
>> >>> As the second step, the pairs of libraries should be merged and the
>> >>>> classlib and drlvm refactoried to have only 3 lib instead of 6.
>> >>>
>> >>> Yep, this would be part of the consolidation into new Harmony top-
>> >>> level
>> >>> components. It makes sense that we share the same impl in the
>> >>> project.
>> >>>
>> >>>> The 3rd step is to replace most of the functions with APR ones and
>> >>>> move the rest of the code to the APR.
>> >>>
>> >>> I think it is quite well documented on this list that this should
>> >>> not be
>> >>> a goal.
>> >>
>> >>
>> >> I agree we don't need to move classlib to APR provided that:
>> >>
>> >> 1)
>> >> There is an easy to understand distinct seperation of the different
>> >> threading/signals packages. In specific, we need to know which
>> >> threading
>> >> package is being called by DRLVM without ambiguity.
>> >>
>> >> 2)
>> >> There is clear understanding of how JVM and classlib threading/
>> >> signals
>> >> interoperate.
>> >>
>> >>
>> >> Regards,
>> >>> Tim
>> >>>
>> >>>> Thoughts?
>> >>>>
>> >>>> Thanks
>> >>>> Artem
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> -------------------------------------------------------------------
>> >>>> --
>> >>>> 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
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>>
>> >>> 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
>> >>>
>> >>>
>> >>
>> >>
>> >
>> > --
>> >
>> > 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
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>
--
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/26/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
>
> > Weldon, I agree with your comments and observations below. Let's take
> > baby steps to get fully unified. I'm sure we all want to keep things
> > working throughout.
>
> So what's the first stop? Move hythread as-is out of classlib to a
> peer in the tree?
I can suggest the following steps:
- pull out hythread from classlib, make it a shared component
- split hythread, refine the bottom layer (thrdsup.h and mutex.h) and
upper layer (hythead_xxx)
- migrate classlib code to the bottom layer (1) of hythread
- migrate DRLVM's thread manager to (1) from APR
Each step can be done without breaking the whole code stack.
As a result, we'll have a bottom part of hythread which will be shared
between the classlib and DRLVM.
Some additional steps could be:
- pull the rest of the portlib out of the classlib, make it a shared
component as well
- migrate DRLVM to portlib
Thanks,
Andrey.
>
> geir
>
> >
> > Regards,
> > Tim
> >
> > Weldon Washburn wrote:
> >> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
> >>>
> >>> Artem Aliev wrote:
> >>>> Gier,
> >>>>
> >>>> The hythread is just most visible example. There are also signal
> >>>> handling problem. classlib hysig lib setup signal handlers and then
> >>>> drlvm overrides them by its owns. There are code duplication in
> >>>> classlib hyprt.dll drlvm port.lib:
> >>>> classlib/trunk/modules/luni/src/main/native/port vm/port/src
> >>>>
> >>>> These three pair of components contains significant part of the
> >>>> system dependent code for both VM and CLASSLIB. I think, all this
> >>>> code naturally defines portlib component that could be shared
> >>>> between
> >>>> classlib and VMs. So, as a first step, we could move all this
> >>>> code in
> >>>> to the one place, name portlib to have three directories classlib,
> >>>> drlvm, portlib.
> >>>
> >>> I think it is quite reasonable to call out the portlib and threadlib
> >>> separate (in the repository) to the VM and classlib. As you
> >>> point out,
> >>> then VM and classlib can share the code -- though it will not
> >>> become a
> >>> requirement for VMs that run the harmony code to be using those
> >>> libraries for their own implementation.
> >>
> >>
> >> Tim,
> >> One of the things to worry about is system-wide lock protocol. We
> >> will
> >> need
> >> to think through what locks portlib, threadlib and JVM are holding
> >> and if
> >> there are any deadlock possibilities.
> >>
> >> Another issue is the implementation of signal chaining. There
> >> seems to be
> >> code in hysignal.c that implement "-Xrs". I guess the idea is that a
> >> Harmony JVM would somehow not link this code and use its own
> >> implementation. The bottom line is that we probably need to
> >> carefully pick
> >> through what is currently in classlib threads/signals and rearrange
> >> stuff so
> >> that it reduces the confusion. We need to make this part of the
> >> system
> >> much
> >> easier to work on.
> >>
> >> Do you have recommendations on next steps? Does it make sense to
> >> start
> >> moving stuff into the directories described above. Or is more
> >> discussion
> >> needed.
> >>
> >>
> >>
> >>> As the second step, the pairs of libraries should be merged and the
> >>>> classlib and drlvm refactoried to have only 3 lib instead of 6.
> >>>
> >>> Yep, this would be part of the consolidation into new Harmony top-
> >>> level
> >>> components. It makes sense that we share the same impl in the
> >>> project.
> >>>
> >>>> The 3rd step is to replace most of the functions with APR ones and
> >>>> move the rest of the code to the APR.
> >>>
> >>> I think it is quite well documented on this list that this should
> >>> not be
> >>> a goal.
> >>
> >>
> >> I agree we don't need to move classlib to APR provided that:
> >>
> >> 1)
> >> There is an easy to understand distinct seperation of the different
> >> threading/signals packages. In specific, we need to know which
> >> threading
> >> package is being called by DRLVM without ambiguity.
> >>
> >> 2)
> >> There is clear understanding of how JVM and classlib threading/
> >> signals
> >> interoperate.
> >>
> >>
> >> Regards,
> >>> Tim
> >>>
> >>>> Thoughts?
> >>>>
> >>>> Thanks
> >>>> Artem
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
> >>>>>
> >>>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> 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
> >>>>
> >>>>
> >>>
> >>> --
> >>>
> >>> 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
> >>>
> >>>
> >>
> >>
> >
> > --
> >
> > 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
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [drlvm][classlib] thread library - let there be one!
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
> Weldon, I agree with your comments and observations below. Let's take
> baby steps to get fully unified. I'm sure we all want to keep things
> working throughout.
So what's the first stop? Move hythread as-is out of classlib to a
peer in the tree?
geir
>
> Regards,
> Tim
>
> Weldon Washburn wrote:
>> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>>>
>>> Artem Aliev wrote:
>>>> Gier,
>>>>
>>>> The hythread is just most visible example. There are also signal
>>>> handling problem. classlib hysig lib setup signal handlers and then
>>>> drlvm overrides them by its owns. There are code duplication in
>>>> classlib hyprt.dll drlvm port.lib:
>>>> classlib/trunk/modules/luni/src/main/native/port vm/port/src
>>>>
>>>> These three pair of components contains significant part of the
>>>> system dependent code for both VM and CLASSLIB. I think, all this
>>>> code naturally defines portlib component that could be shared
>>>> between
>>>> classlib and VMs. So, as a first step, we could move all this
>>>> code in
>>>> to the one place, name portlib to have three directories classlib,
>>>> drlvm, portlib.
>>>
>>> I think it is quite reasonable to call out the portlib and threadlib
>>> separate (in the repository) to the VM and classlib. As you
>>> point out,
>>> then VM and classlib can share the code -- though it will not
>>> become a
>>> requirement for VMs that run the harmony code to be using those
>>> libraries for their own implementation.
>>
>>
>> Tim,
>> One of the things to worry about is system-wide lock protocol. We
>> will
>> need
>> to think through what locks portlib, threadlib and JVM are holding
>> and if
>> there are any deadlock possibilities.
>>
>> Another issue is the implementation of signal chaining. There
>> seems to be
>> code in hysignal.c that implement "-Xrs". I guess the idea is that a
>> Harmony JVM would somehow not link this code and use its own
>> implementation. The bottom line is that we probably need to
>> carefully pick
>> through what is currently in classlib threads/signals and rearrange
>> stuff so
>> that it reduces the confusion. We need to make this part of the
>> system
>> much
>> easier to work on.
>>
>> Do you have recommendations on next steps? Does it make sense to
>> start
>> moving stuff into the directories described above. Or is more
>> discussion
>> needed.
>>
>>
>>
>>> As the second step, the pairs of libraries should be merged and the
>>>> classlib and drlvm refactoried to have only 3 lib instead of 6.
>>>
>>> Yep, this would be part of the consolidation into new Harmony top-
>>> level
>>> components. It makes sense that we share the same impl in the
>>> project.
>>>
>>>> The 3rd step is to replace most of the functions with APR ones and
>>>> move the rest of the code to the APR.
>>>
>>> I think it is quite well documented on this list that this should
>>> not be
>>> a goal.
>>
>>
>> I agree we don't need to move classlib to APR provided that:
>>
>> 1)
>> There is an easy to understand distinct seperation of the different
>> threading/signals packages. In specific, we need to know which
>> threading
>> package is being called by DRLVM without ambiguity.
>>
>> 2)
>> There is clear understanding of how JVM and classlib threading/
>> signals
>> interoperate.
>>
>>
>> Regards,
>>> Tim
>>>
>>>> Thoughts?
>>>>
>>>> Thanks
>>>> Artem
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 9/19/06, Geir Magnusson Jr. <ge...@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
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> 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
>>>>
>>>>
>>>
>>> --
>>>
>>> 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
>>>
>>>
>>
>>
>
> --
>
> 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
>
---------------------------------------------------------------------
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Tim Ellison <t....@gmail.com>.
Weldon, I agree with your comments and observations below. Let's take
baby steps to get fully unified. I'm sure we all want to keep things
working throughout.
Regards,
Tim
Weldon Washburn wrote:
> On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>>
>> Artem Aliev wrote:
>> > Gier,
>> >
>> > The hythread is just most visible example. There are also signal
>> > handling problem. classlib hysig lib setup signal handlers and then
>> > drlvm overrides them by its owns. There are code duplication in
>> > classlib hyprt.dll drlvm port.lib:
>> > classlib/trunk/modules/luni/src/main/native/port vm/port/src
>> >
>> > These three pair of components contains significant part of the
>> > system dependent code for both VM and CLASSLIB. I think, all this
>> > code naturally defines portlib component that could be shared between
>> > classlib and VMs. So, as a first step, we could move all this code in
>> > to the one place, name portlib to have three directories classlib,
>> > drlvm, portlib.
>>
>> I think it is quite reasonable to call out the portlib and threadlib
>> separate (in the repository) to the VM and classlib. As you point out,
>> then VM and classlib can share the code -- though it will not become a
>> requirement for VMs that run the harmony code to be using those
>> libraries for their own implementation.
>
>
> Tim,
> One of the things to worry about is system-wide lock protocol. We will
> need
> to think through what locks portlib, threadlib and JVM are holding and if
> there are any deadlock possibilities.
>
> Another issue is the implementation of signal chaining. There seems to be
> code in hysignal.c that implement "-Xrs". I guess the idea is that a
> Harmony JVM would somehow not link this code and use its own
> implementation. The bottom line is that we probably need to carefully pick
> through what is currently in classlib threads/signals and rearrange
> stuff so
> that it reduces the confusion. We need to make this part of the system
> much
> easier to work on.
>
> Do you have recommendations on next steps? Does it make sense to start
> moving stuff into the directories described above. Or is more discussion
> needed.
>
>
>
>> As the second step, the pairs of libraries should be merged and the
>> > classlib and drlvm refactoried to have only 3 lib instead of 6.
>>
>> Yep, this would be part of the consolidation into new Harmony top-level
>> components. It makes sense that we share the same impl in the project.
>>
>> > The 3rd step is to replace most of the functions with APR ones and
>> > move the rest of the code to the APR.
>>
>> I think it is quite well documented on this list that this should not be
>> a goal.
>
>
> I agree we don't need to move classlib to APR provided that:
>
> 1)
> There is an easy to understand distinct seperation of the different
> threading/signals packages. In specific, we need to know which threading
> package is being called by DRLVM without ambiguity.
>
> 2)
> There is clear understanding of how JVM and classlib threading/signals
> interoperate.
>
>
> Regards,
>> Tim
>>
>> > Thoughts?
>> >
>> > Thanks
>> > Artem
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 9/19/06, Geir Magnusson Jr. <ge...@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
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > 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
>> >
>> >
>>
>> --
>>
>> 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
>>
>>
>
>
--
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Weldon Washburn <we...@gmail.com>.
On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>
> Artem Aliev wrote:
> > Gier,
> >
> > The hythread is just most visible example. There are also signal
> > handling problem. classlib hysig lib setup signal handlers and then
> > drlvm overrides them by its owns. There are code duplication in
> > classlib hyprt.dll drlvm port.lib:
> > classlib/trunk/modules/luni/src/main/native/port vm/port/src
> >
> > These three pair of components contains significant part of the
> > system dependent code for both VM and CLASSLIB. I think, all this
> > code naturally defines portlib component that could be shared between
> > classlib and VMs. So, as a first step, we could move all this code in
> > to the one place, name portlib to have three directories classlib,
> > drlvm, portlib.
>
> I think it is quite reasonable to call out the portlib and threadlib
> separate (in the repository) to the VM and classlib. As you point out,
> then VM and classlib can share the code -- though it will not become a
> requirement for VMs that run the harmony code to be using those
> libraries for their own implementation.
Tim,
One of the things to worry about is system-wide lock protocol. We will need
to think through what locks portlib, threadlib and JVM are holding and if
there are any deadlock possibilities.
Another issue is the implementation of signal chaining. There seems to be
code in hysignal.c that implement "-Xrs". I guess the idea is that a
Harmony JVM would somehow not link this code and use its own
implementation. The bottom line is that we probably need to carefully pick
through what is currently in classlib threads/signals and rearrange stuff so
that it reduces the confusion. We need to make this part of the system much
easier to work on.
Do you have recommendations on next steps? Does it make sense to start
moving stuff into the directories described above. Or is more discussion
needed.
> As the second step, the pairs of libraries should be merged and the
> > classlib and drlvm refactoried to have only 3 lib instead of 6.
>
> Yep, this would be part of the consolidation into new Harmony top-level
> components. It makes sense that we share the same impl in the project.
>
> > The 3rd step is to replace most of the functions with APR ones and
> > move the rest of the code to the APR.
>
> I think it is quite well documented on this list that this should not be
> a goal.
I agree we don't need to move classlib to APR provided that:
1)
There is an easy to understand distinct seperation of the different
threading/signals packages. In specific, we need to know which threading
package is being called by DRLVM without ambiguity.
2)
There is clear understanding of how JVM and classlib threading/signals
interoperate.
Regards,
> Tim
>
> > Thoughts?
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> >
> >
> > On 9/19/06, Geir Magnusson Jr. <ge...@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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> --
>
> 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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by Rana Dasgupta <rd...@gmail.com>.
I am not very familiar with this section of the code. But if this is in
general true, and the classlib dependency on the hythread_XXX api's is
small, what Andrey says above makes sense to me. Why not replace them(
monitor enter/exit, TLS access etc. ) with the portability layer macrodefs
from thrdsup.h and hymutex.h? And just keep the hythread_XXX around
seperately for optional usage by any JVM that may wish to and revisit the
issue later?
That way we know what is the code we are using and needs to be tested,
optimized etc.
Thanks,
Rana
> On 9/20/06, Weldon Washburn <we...@gmail.com> wrote:
> >
> > All,
> > Is there something missing from the below analysis? I did a grep for
> > "hythread_" in all of the classlib directory. There were 1300 hits of
> > which
> > 1200++ where inside the code that implements classlib hythread
> > itself. In
> > other words, 1200++ hits are most likely irrelevant to a VM developer.
> > As
> > far as I can tell, only the following source files containing
> > hythread_xxx
> > APIs are actually used by Harmony Classlib. Is this accurate?
> >
> >
> > C:\t_harmony\classlib\trunk\modules\archive\src\main\native\zip\shared\zipsup.c(116):#define
> > ENTER()
> > hythread_monitor_enter(hythread_global_monitor())C:\t_harmony\classlib\trunk\modules\archive\src\main\native\zip\shared\zipsup.c(117):#define
> >
> > EXIT() hythread_monitor_exit(hythread_global_monitor())
> >
> > from
> > c:\t_harmony\classlib\trunk\modules\luni\arc\main\port\shared\hynls.c
> > hythread_monitor_enter (nls->monitor); hythread_monitor_exit
> > (nls->monitor);
> >
> >
> > C:\t_harmony\classlib\trunk\modules\luni\src\main\native\vmls\shared\vmls.c(82):
> > hythread_monitor_enter(globalMonitor);
> >
> > C:\t_harmony\classlib\trunk\modules\luni\src\main\native\vmls\shared\vmls.c(103):
> > hythread_monitor_exit(globalMonitor);
> >
> >
> >
>
Re: [drlvm][classlib] thread library - let there be one!
Posted by Weldon Washburn <we...@gmail.com>.
All,
Is there something missing from the below analysis? I did a grep for
"hythread_" in all of the classlib directory. There were 1300 hits of which
1200++ where inside the code that implements classlib hythread itself. In
other words, 1200++ hits are most likely irrelevant to a VM developer. As
far as I can tell, only the following source files containing hythread_xxx
APIs are actually used by Harmony Classlib. Is this accurate?
C:\t_harmony\classlib\trunk\modules\archive\src\main\native\zip\shared\zipsup.c(116):#define
ENTER()
hythread_monitor_enter(hythread_global_monitor())C:\t_harmony\classlib\trunk\modules\archive\src\main\native\zip\shared\zipsup.c(117):#define
EXIT() hythread_monitor_exit(hythread_global_monitor())
from c:\t_harmony\classlib\trunk\modules\luni\arc\main\port\shared\hynls.c
hythread_monitor_enter (nls->monitor); hythread_monitor_exit (nls->monitor);
C:\t_harmony\classlib\trunk\modules\luni\src\main\native\vmls\shared\vmls.c(82):
hythread_monitor_enter(globalMonitor);
C:\t_harmony\classlib\trunk\modules\luni\src\main\native\vmls\shared\vmls.c(103):
hythread_monitor_exit(globalMonitor);
On 9/20/06, Tim Ellison <t....@gmail.com> wrote:
>
> Artem Aliev wrote:
> > These three pair of components contains significant part of the
> > system dependent code for both VM and CLASSLIB. I think, all this
> > code naturally defines portlib component that could be shared between
> > classlib and VMs. So, as a first step, we could move all this code in
> > to the one place, name portlib to have three directories classlib,
> > drlvm, portlib.
>
> I think it is quite reasonable to call out the portlib and threadlib
> separate (in the repository) to the VM and classlib. As you point out,
> then VM and classlib can share the code -- though it will not become a
> requirement for VMs that run the harmony code to be using those
> libraries for their own implementation.
>
> > As the second step, the pairs of libraries should be merged and the
> > classlib and drlvm refactoried to have only 3 lib instead of 6.
>
> Yep, this would be part of the consolidation into new Harmony top-level
> components. It makes sense that we share the same impl in the project.
>
> > The 3rd step is to replace most of the functions with APR ones and
> > move the rest of the code to the APR.
>
> I think it is quite well documented on this list that this should not be
> a goal.
>
> Regards,
> Tim
>
> > Thoughts?
> >
> > Thanks
> > Artem
> >
> >
> >
> >
> >
> >
> > On 9/19/06, Geir Magnusson Jr. <ge...@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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> --
>
> 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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm][classlib] thread library - let there be one!
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 20, 2006, at 8:08 AM, Tim Ellison wrote:
> Artem Aliev wrote:
>> Gier,
>>
>> The hythread is just most visible example. There are also signal
>> handling problem. classlib hysig lib setup signal handlers and then
>> drlvm overrides them by its owns. There are code duplication in
>> classlib hyprt.dll drlvm port.lib:
>> classlib/trunk/modules/luni/src/main/native/port vm/port/src
>>
>> These three pair of components contains significant part of the
>> system dependent code for both VM and CLASSLIB. I think, all this
>> code naturally defines portlib component that could be shared between
>> classlib and VMs. So, as a first step, we could move all this code in
>> to the one place, name portlib to have three directories classlib,
>> drlvm, portlib.
>
> I think it is quite reasonable to call out the portlib and threadlib
> separate (in the repository) to the VM and classlib. As you point
> out,
> then VM and classlib can share the code -- though it will not become a
> requirement for VMs that run the harmony code to be using those
> libraries for their own implementation.
>
>> As the second step, the pairs of libraries should be merged and the
>> classlib and drlvm refactoried to have only 3 lib instead of 6.
>
> Yep, this would be part of the consolidation into new Harmony top-
> level
> components. It makes sense that we share the same impl in the
> project.
>
>> The 3rd step is to replace most of the functions with APR ones and
>> move the rest of the code to the APR.
>
> I think it is quite well documented on this list that this should
> not be
> a goal.
Agreed, absolutely.
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Tim Ellison <t....@gmail.com>.
Artem Aliev wrote:
> Gier,
>
> The hythread is just most visible example. There are also signal
> handling problem. classlib hysig lib setup signal handlers and then
> drlvm overrides them by its owns. There are code duplication in
> classlib hyprt.dll drlvm port.lib:
> classlib/trunk/modules/luni/src/main/native/port vm/port/src
>
> These three pair of components contains significant part of the
> system dependent code for both VM and CLASSLIB. I think, all this
> code naturally defines portlib component that could be shared between
> classlib and VMs. So, as a first step, we could move all this code in
> to the one place, name portlib to have three directories classlib,
> drlvm, portlib.
I think it is quite reasonable to call out the portlib and threadlib
separate (in the repository) to the VM and classlib. As you point out,
then VM and classlib can share the code -- though it will not become a
requirement for VMs that run the harmony code to be using those
libraries for their own implementation.
> As the second step, the pairs of libraries should be merged and the
> classlib and drlvm refactoried to have only 3 lib instead of 6.
Yep, this would be part of the consolidation into new Harmony top-level
components. It makes sense that we share the same impl in the project.
> The 3rd step is to replace most of the functions with APR ones and
> move the rest of the code to the APR.
I think it is quite well documented on this list that this should not be
a goal.
Regards,
Tim
> Thoughts?
>
> Thanks
> Artem
>
>
>
>
>
>
> On 9/19/06, Geir Magnusson Jr. <ge...@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
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
>
--
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Tim Ellison <t....@gmail.com>.
Ivan Volosyuk wrote:
> Looks like a matter of relations, how the classlib and VM relates to
> each other.
>
> Either VM and classlib independant, then we need something to be
> common base for them - portlib. If VM links with classlib, then no
> more need for portlib, just well understood interfaces provided by
> classlib's HDK. If classlib links with VM, then it is the VM who
> should provide this interfaces :)
I'm unclear on your definition of 'links with', but I envisage that the
portlib and threadlib become a set of utility functions that are usable
and sufficient for both the DRLVM and classlib code. It certainly
doesn't make sense to maintain two different versions of what is
essentially the same thing.
Let's look at the differences in implementation and resolve to reconcile
them into a single project-wide version.
Regards,
Tim
> On 9/19/06, Artem Aliev <ar...@gmail.com> wrote:
>> Gier,
>>
>> The hythread is just most visible example.
>> There are also signal handling problem.
>> classlib hysig lib setup signal handlers and then drlvm overrides them
>> by its owns.
>> There are code duplication in classlib hyprt.dll drlvm port.lib:
>> classlib/trunk/modules/luni/src/main/native/port
>> vm/port/src
>>
>> These three pair of components contains significant part of the system
>> dependent code for both VM and CLASSLIB.
>> I think, all this code naturally defines portlib component that could
>> be shared between classlib and VMs.
>> So, as a first step, we could move all this code in to the one place,
>> name portlib
>> to have three directories classlib, drlvm, portlib.
>>
>> As the second step, the pairs of libraries should be merged and the
>> classlib and drlvm refactoried to have only 3 lib instead of 6.
>>
>> The 3rd step is to replace most of the functions with APR ones and
>> move the rest of the code to the APR.
>>
>> Thoughts?
>>
>> Thanks
>> Artem
>>
>>
>>
>>
>>
>>
>> On 9/19/06, Geir Magnusson Jr. <ge...@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
>
>
--
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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Ivan Volosyuk <iv...@gmail.com>.
Looks like a matter of relations, how the classlib and VM relates to each other.
Either VM and classlib independant, then we need something to be
common base for them - portlib. If VM links with classlib, then no
more need for portlib, just well understood interfaces provided by
classlib's HDK. If classlib links with VM, then it is the VM who
should provide this interfaces :)
--
Ivan
On 9/19/06, Artem Aliev <ar...@gmail.com> wrote:
> Gier,
>
> The hythread is just most visible example.
> There are also signal handling problem.
> classlib hysig lib setup signal handlers and then drlvm overrides them
> by its owns.
> There are code duplication in classlib hyprt.dll drlvm port.lib:
> classlib/trunk/modules/luni/src/main/native/port
> vm/port/src
>
> These three pair of components contains significant part of the system
> dependent code for both VM and CLASSLIB.
> I think, all this code naturally defines portlib component that could
> be shared between classlib and VMs.
> So, as a first step, we could move all this code in to the one place,
> name portlib
> to have three directories classlib, drlvm, portlib.
>
> As the second step, the pairs of libraries should be merged and the
> classlib and drlvm refactoried to have only 3 lib instead of 6.
>
> The 3rd step is to replace most of the functions with APR ones and
> move the rest of the code to the APR.
>
> Thoughts?
>
> Thanks
> Artem
>
>
>
>
>
>
> On 9/19/06, Geir Magnusson Jr. <ge...@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
Re: [drlvm][classlib] thread library - let there be one!
Posted by Artem Aliev <ar...@gmail.com>.
Gier,
The hythread is just most visible example.
There are also signal handling problem.
classlib hysig lib setup signal handlers and then drlvm overrides them
by its owns.
There are code duplication in classlib hyprt.dll drlvm port.lib:
classlib/trunk/modules/luni/src/main/native/port
vm/port/src
These three pair of components contains significant part of the system
dependent code for both VM and CLASSLIB.
I think, all this code naturally defines portlib component that could
be shared between classlib and VMs.
So, as a first step, we could move all this code in to the one place,
name portlib
to have three directories classlib, drlvm, portlib.
As the second step, the pairs of libraries should be merged and the
classlib and drlvm refactoried to have only 3 lib instead of 6.
The 3rd step is to replace most of the functions with APR ones and
move the rest of the code to the APR.
Thoughts?
Thanks
Artem
On 9/19/06, Geir Magnusson Jr. <ge...@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
>
>
---------------------------------------------------------------------
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