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: 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 ([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] > > -- 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]
