harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Date Thu, 21 Sep 2006 00:18:54 GMT


> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> Sent: Wednesday, September 20, 2006 8:11 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
> for java.util.concurrent
> 
> 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.

This sounds appropriate; I'll make an update to Threads.

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

I'll add a factory/singleton method, which can be used then perform any
security checks. Then I presume other Classlib code would invoke this via
PrivilegedAction, correct?

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

I agree with Tim, but in addition to that I'd like to not fiddle with the
j.u.c code as much as possible, so as to ensure implementation consistency.

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

Personally, I'm all for combining all of these down into one set of
interfaces in one module. It's really confusing to have all of these
different Object manipulation interfaces that seem alike, but are used in
different places.

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

Objects should cover everything that is in Atomics, but we'll need
additional methods to cover the accessor stuff, but that should be trivial.

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

I would prefer working with Field objects, but we'll need the long "offset"
values to implement sun.misc.Unsafe. If you haven't looked at that API,
check it out, it's a little weird [1]. The way you manipulate fields is to
lookup the Field, then look up the offset, then you pass the instance and
field offset into the accessor/mutator methods. It's even more difficult for
arrays. You get the field offset, then you get a base offset and scalar
offset for the array field's type (int[], Object[]), which you then use to
calculate the actual element's offset (base + idx * scalar). Check out the
AtomicXXX classes for examples of usage [2].

[1]
http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/mo
dules/luni-kernel/src/main/java/sun/misc/Unsafe.java
[2]
http://svn.apache.org/repos/asf/incubator/harmony/standard/classlib/trunk/mo
dules/concurrent/src/main/java/java/util/concurrent/atomic/AtomicLongArray.j
ava


> 
> > 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.
> 
> > 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?
> 
> +1 for Atomics moving into a kernel.

+1 for moving most of this stuff into kernel and then merging it as much as
possible and appropriate.

> 
> Same comment as above for atomics etc. not being left as unguarded
> public types/methods to avoid surprises from mischievous apps.
> 
> Regards,
> Tim
> 
> 
> > [3]
> >
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mod
> ules/misc/src/main/java/org/apache/harmony/misc/accessors/ObjectAccessor.j
> ava?view=markup
> >
> >
> > [4]
> >
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mod
> ules/misc/src/main/java/org/apache/harmony/misc/accessors/ArrayAccessor.ja
> va?view=markup
> >
> >
> > [5]
> >
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmc
> ore/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


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


Mime
View raw message