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 Fri, 22 Sep 2006 04:29:21 GMT
Moved.

> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
> Sent: Thursday, September 21, 2006 5:14 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
> for java.util.concurrent
> 
> +1
> 
> On Sep 21, 2006, at 5:56 PM, Tim Ellison wrote:
> 
> > Nathan,
> >
> > How about you move sun.misc.Unsafe from luni-kernel to suncompat -- it
> > may be confusing the design discussion by leaving it in there
> > alongside
> > Threads/Objects.
> >
> > Regards,
> > Tim
> >
> > Nathan Beyer 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?
> >>
> >>>> 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
> >>
> >>
> >
> > --
> >
> > 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


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