harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Fri, 10 Nov 2006 17:59:09 GMT
On 11/10/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>
> 2006/11/10, Weldon Washburn <weldonwjw@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.y.chernyshev@gmail.com> wrote:
> > >
> > > On 10/26/06, Angela Lin <alin.harmony@gmail.com> wrote:
> > > > On 10/24/06, Weldon Washburn <weldonwjw@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 <alin.harmony@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 <weldonwjw@gmail.com> wrote:
> > > > > > > On 10/23/06, Angela Lin <alin.harmony@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 <artem.aliev@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 <alin.harmony@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

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