harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Date Thu, 21 Sep 2006 22:14:06 GMT
+1

On Sep 21, 2006, at 5:56 PM, Tim Ellison wrote:

> 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:t.p.ellison@gmail.com]
>>> 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 (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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
> -- 
>
> 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
>


---------------------------------------------------------------------
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