As a first step I would like to implement the following methods: 1. getFieldOffset - it may be done by forwarding call to ObjectAccessor.getFieldID or by JNI wrapping of existing impl in atomics.cpp. The second, I think, is preferable because we avoid further conversion of fieldID to field offset on each CAS call (in common case). But in this case we will need to implement set/getVolatile instead of using the impl from ObjectAccessor. 2. compareAndSet* - to implement this I need to change interface of cas methods in the Atomics.java to use long field IDs.
If nobody has objections I am going to prepare a patch adding this implementation. Rustem Rafikov Intel Middleware Products Division On 8/7/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:
On 8/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > > > > On of the technical things we have to do still for java.util.concurrent > > is to create sun.misc.Unsafe for the VMs and see how things work together. > > > > How much work will it be for DRLVM? > > Some of it seems to be available in a class called > "org.apache.harmony.util.concurrent.Atomics", at least the CAS stuff. > There's a replacement for java.util.concurrent.locks.LockSupport in the > DRLVM source that has a JNI complement, but this will need to be converted > to be used within sun.misc.Unsafe. > > The other major missing piece is the object field manipulation and the > volatile set of those fields as well. Some of this may already be available, > but I don't know for sure. Would the accessors package available at classlib/trunk/modules/misc/src/main/java/org/apache/harmony/misc/accessors suite these needs? May be the ObjectAccessor and ArrayAccessor classes could help. They don't, however, provide a volatile access support yet. But, it probably can be added with the help of MemoryReadWriteBarrier() function defined in drlvm/trunk/vm/vmcore/include/atomics.h. BTW: what if we use a simple access instead of the volatile one for a while, is this API frequently used (compared to the other util.concurrent ones)? May be we could adopt concurrent in several steps. First, add lock support and the basic CAS operations, then add volatile access e.t.c. Thanks, Andrey. > > -Nathan > > > > > geir > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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]
