You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Andrey Chernyshev <a....@gmail.com> on 2006/11/10 10:12:04 UTC
Re: [drlvm][classlib] thread library - let there be one!
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 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 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 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