Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 66.249.92.174 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=otIlY76tkCI35G+umPncQ7pJeCnS7HP33p8ChgUVF34pSz7z2Npmhle8m48AUbUnuX9CdjA365KvM5ELOMNFMJfDTsHqE8X723kmFq8ue5i6VcKHKyoRzyoiI9TYmoNK5SFpQzbtj3C4U+RHnPmtfwOQAMAOAIc+UcndNNwHwho=
Message-ID: <45130A98.3060102@gmail.com>
Date: Thu, 21 Sep 2006 22:56:40 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
 java.util.concurrent
References: <009401c6dd13$8645b430$0201a8c0@LITTLEGUY>
In-Reply-To: <009401c6dd13$8645b430$0201a8c0@LITTLEGUY>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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