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. 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. > 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. >> [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? > 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? > 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>. > 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. 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/modules/misc/src/main/java/org/apache/harmony/misc/accessors/ObjectAccessor.java?view=markup > > > [4] > http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessors/ArrayAccessor.java?view=markup > > > [5] > http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/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]
