Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 64.233.184.226 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=L8CMjoR+rPHt6DzDFhLvOTDlQ7ZvcmrecYUPF0/MddXH1GtUaVzVKef4Fhjjbi2zc0OMhp1CbhDoEKXUMWx86XvAM8jGi7FZbgVeb6pGQ+7v/yyqRPF5AqbwHRelQ3g78r/kWIbycAbPuZyPgXzNO9iqcfYyxrVvnoOAUYo5vwc=
Message-ID: <6928c5160609210542i381a0154ged3668f20f6af718@mail.gmail.com>
Date: Thu, 21 Sep 2006 16:42:55 +0400
From: "Andrey Chernyshev" <a.y.chernyshev@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
 java.util.concurrent
In-Reply-To: <009401c6dd13$8645b430$0201a8c0@LITTLEGUY>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45113DE6.7080205@gmail.com>
	 <009401c6dd13$8645b430$0201a8c0@LITTLEGUY>

On 9/21/06, Nathan Beyer <nbeyer@kc.rr.com> wrote:
>
>
> > -----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?

The other option could be just to check that the class loader of the
calling method is the same as the one which was used to load Threads -
this is how it is done in the AccessorFactory. I suspect the
PriviledgedAction block would do eventually the same, but possibly
with some extra expense on creating the PriviledgedAction object.

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

I completely agree with this point of view.

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

I don't know the original intent that was put in the Unsafe design. My
only guesses would be:
To access the field in JNI code, you'd finally need the jfieldID. Then
the question comes - what to remember in the Java heap, 64-bit fieldID
or a Field object? The Field object is likely to consume more memory
in the Java heap compared to the long value.

Perhaps there could be also some pointer arithmetic with fieldID's
assuming that they are corresponding to the field offsets in the
object, and assuming that the layout of fields in the objects is
known. But I'm not sure if we want our classlib code be dependent on
that - ID's could be more abstract than the offsets.

Thanks,
Andrey.

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


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