harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Date Wed, 20 Sep 2006 13:11:02 GMT
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message