On 9/18/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
I've added some classes[1][2] to luni-kernel in the
org.apache.harmony.kernel.vm package that are intended the VMI replacement
for the sun.misc.Unsafe class. The intent is to provide a VMI class to
support java.util.concurrent. Initially this will be done by implementing
the sun.misc.Unsafe in 'suncompat' module in terms of these new classes.
For the most part, the methods are essentially the subset of Unsafe that's
needed for java.util.concurrent. I've separated the methods into two
classes; Threads [1] for the threading features and Objects [2] for the
object manipulation features. My initial thought is that Threads may be
extended to provide additional support needed for lang-management features.
Please take a look at the classes and provide some feedback.
[1]
http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/mo
dules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/Threads.java
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.
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?
[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, plus the o.a.util.concurrent.Atomics [5] from the DRLVM. 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 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.
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.
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?
Thanks,
Andrey.
[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
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
