Moved. > -----Original Message----- > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 21, 2006 5:14 PM > To: [email protected] > 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:[EMAIL PROTECTED] > >>> Sent: Wednesday, September 20, 2006 8:11 AM > >>> To: [email protected] > >>> 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 ([EMAIL PROTECTED]) > >>> IBM Java technology centre, UK. > >>> > >>> -------------------------------------------------------------------- > >>> - > >>> Terms of use : http://incubator.apache.org/harmony/mailing.html > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: harmony-dev- > >>> [EMAIL PROTECTED] > >> > >> > >> --------------------------------------------------------------------- > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: harmony-dev- > >> [EMAIL PROTECTED] > >> > >> > > > > -- > > > > Tim Ellison ([EMAIL PROTECTED]) > > IBM Java technology centre, UK. > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
