harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Date Thu, 21 Sep 2006 12:09:24 GMT
On 9/20/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Andrey Chernyshev wrote:
> > Thanks Nathan! The Threads interface looks fine. Still, may be it
> > would be nice if two different methods are allocated for parkNanos and
> > parkUntil - passing the extra boolean parameter seems like an
> > overhead, though very little.
> I agree, just create another method rather than passing in a boolean flag.
> How are you going to avoid apps calling these public methods?  We can do
> a security/calling stack check on each method send, but it may be
> preferable to make Threads a singleton and check in a getSingleton() call.

Yes, accessor classes were also designed as sigletones those instances
can only be obtained through the AccessorFactory which handles the
security checks.
I wonder if it may make sense to have a single factory for accessor
classes and Threads.

> > Another solution could be just to keep our own implementation of the
> > LockSupport in the luni-kernel (there is nothing to share for the
> > LockSupport with the original j.u.c, it contains almost no code). Is
> > there a reason why we can not do that?
> Probably best to keep our own primitive operations separate in the
> o.a.harmony package namespace.
> >> [2]
> >> http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/mo
> >>
> >> dules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/Objects.java
> >>
> >
> > I guess the interesting question would be how do we rearrange the
> > already existing classes in Harmony, e.g. ObjectAccessor [3] and
> > ArrayAccessor [4] from the o.a.h.misc.accessors package of the
> > classlib,
> Do these need to be rearranged?  Why can't we write the suncompat's
> Unsafe equivalents in terms of these accessors?

I wouldn't wish we a have multiple classes which are doing the same
things, even if some of them are delegating work to others (e.g.
Objects is written on top of accessors or accessors are rewritten on
top of Objects) - this seems to me just like extra layers/function

> > plus the o.a.util.concurrent.Atomics [5] from the DRLVM.
> Yep, these need to be moved into the kernel for all VMs to implement.
> We can define them in (a new) concurrent-kernel unless there is
> consensus that they would be more generally useful, i.e. misc-kernel or
> luni-kernel.

If all VM's are supposed to be 1.5+ compliant anyways, why not just
adding to the luni-kernel...

> > The proposed "Objects" seems like a combination of the above three.
> > For example, the following API set from the Objects:
> >
> > public static long objectFieldOffset(Field field)
> > public static void putLong(Object object, long fieldOffset, long
> > newValue) {
> > public static long getLong(Object object, long fieldOffset)
> >
> > is just equivalent to the one from the ObjectAccessor:
> >
> > public final native long getFieldID(Field f);
> > public final native void setLong(Object o, long fieldID, long value);
> > public final native long getLong(Object o, long fieldID);
> I agree.  We should design the set the accessor/atomic methods that make
> sense, then express the suncompat version of Unsafe in terms of them.
> Andrey: did you check that everything in Objects is covered by existing
> accessor/atomics?

Yes, the Objects is a subset of the existing accessors + Atomics combination.

> > I guess j.u.concurrent won't use the direct read/write to objects,
> > except for volatile or atomic access?
> > Having two different interfaces for doing the same can be confusing -
> > it may not be clear, what is the relationship between "fieldID" from
> > the accessors package and "fieldOffset" from the Objects.
> Is there a big advantage to using longs rather than Field's directly?
> It looks like the Atomics may have been that way once, the javadoc still
> refers to '@parm field' though the signature is now 'long offset' <g>.

Right, the initial version was containing Field as a parameter because
the intent was to have no dependencies on accessors package (Atomics
might be in the kernel set, but  the accessors are currently not).

> > If we have a task to identify the minimum set of functionality which
> > is needed for j.u.concurrent, then it looks like the only object API
> > set we really may need to pick up is the one which is currently
> > contained in the o.a.util.concurrent.Atomics.
> I believe this is what Nathan did already in the Objects spec -- at
> least that was my understanding.

I've noticed that Objects have added simple put/getLong operations
which were not in the Atomics, I'm not sure if the j.u.c code really
needs them (I thought it only needs either atomic or volatile access).

> > If the purpose is to propose some more generic interface for direct
> > object access, then why just don't move the existing XXXAccessor and
> > Atomics to the luni-kernel and go with their combination?
> Do accessors need to be in kernel?  They are implemented solely in terms
> of JNI - right?

Right. It is clear that now we have a set of API's that provide
different type of access to objects (e.g. simple, atomic or volatile),
arrays and threads. I can imagine the following types of it's
- VM specific or not (or, can be implemented with JNI or not)
- Package where they are needed (e.g. j.u.c, awt/swing, io or whatever)
- Objects they are accessing (e.g. object, array, thread)
We may pick one or another type of classification and split the API
into different pacakges/jars in accordance with it.

On the other hand, obviously all of these classes would have the same
mechanism for getting their instances, and most likely share the way
how fieldID's (or offsets) are obtained. In other words, it may be
unnatural to try to split them. This is why I proposed to keep them in
a single place. Assuming that there is a portion in this API set which
is VM-specific, it probably may make sense to put them into kernel.

> +1 for Atomics moving into a kernel.
> Same comment as above for atomics etc. not being left as unguarded
> public types/methods to avoid surprises from mischievous apps.

Right, I would add the Atomics creation to the AccessorFactory if we
agreed that all of this stuff is of the same nature.

> Regards,
> Tim
> > [3]
> > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessors/ObjectAccessor.java?view=markup
> >
> >
> > [4]
> > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessors/ArrayAccessor.java?view=markup
> >
> >
> > [5]
> > http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/Atomics.java?view=markup
> >
> >
> >>
> >>
> >>
> >>
> >
> >
> --
> 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

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

View raw message