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 Sun, 24 Sep 2006 19:36:36 GMT

On Sep 24, 2006, at 3:29 PM, Nathan Beyer wrote:

> I made some updates to Threads and Objects based on the feedback in  
> this
> thread. I've also implemented Unsafe in terms of these two classes,  
> just to
> validate the code path.
> Some comments based on observations in the code and some items in this
> thread.
> * ObjectAccessor in misc currently can't fulfill the Unsafe  
> contract; it's
> missing volatile get/set. This is also missing for array element  
> volatile
> get/set and there's no mapping from Unsafe's relative/scaled access  
> for
> array elements.
> * I don't think there is any value in separating the atomic compare  
> and swap
> method into a concurrency-kernel; there are only three method
> (int/long/Object), the methods use the same fieldOffset/Field ref  
> mechanism
> that the Objects/ObjectAccessor does, so this would have to be  
> duplicated in
> the interface or a consumer would have to use Objects/ 
> ObjectAccessor to work
> with an Atomics class, which creates a loose coupling anyway.
> * I think we should utilize the Accessor classes in 'misc' (in  
> place of
> Objects), but I think these all need to be refactored into a kernel  
> or VM
> module. I really don't like the 'misc' naming, as it make it seem  
> like it's
> just some extra crap that doesn't fit in any category, which seems  
> very
> inappropriate as these are core VM services and utilities used by many
> modules.

This isn't our fault that it's named that way.  I think that all it  
does is make suncompat a required piece, something I have no  
objection to :)

> My suggestion would be to move the accessor parts of 'misc' into  
> kernel, put
> them in the "vm" package and add some "getInstance" methods for  
> security.
> -Nathan
>> -----Original Message-----
>> From: Andrey Chernyshev [mailto:a.y.chernyshev@gmail.com]
>> Sent: Sunday, September 24, 2006 6:44 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib][vmi] VMI classes for Thread/Object  
>> manipulation
>> for java.util.concurrent
>> On 9/22/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>> Andrey Chernyshev wrote:
>>>> On 9/20/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>>> 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.
>>>> Yes, accessor classes were also designed as sigletones those  
>>>> instances
>>>> can only be obtained through the AccessorFactory which handles the
>>>> security checks.
>>>> I wonder if it may make sense to have a single factory for accessor
>>>> classes and Threads.
>>> Just let each type handle the security check.
>> Good suggestion. So it sounds like the ObjectAccessor, ArrayAccessor
>> and other accessors should be created with the static
>> XXXAccessor.getInstance() calls (instead of Factory.getXXXAccessor
>> calls)?
>> Yes, it would help to split accessors, though probably at the  
>> price of
>> the duplication of the security checking code.
>> Right now it is in the AccessorFactory.checkPermissions()), but it
>> will have to be replicated in Atomics (or whatever) from the
>> concurrent-kernel if we want to avoid dependencies between
>> concurrent-kernel and o.a.h.accessors package.
>>> <snip>
>>>>> Do these need to be rearranged?  Why can't we write the  
>>>>> suncompat's
>>>>> Unsafe equivalents in terms of these accessors?
>>>> I wouldn't wish we a have multiple classes which are doing the same
>>>> things, even if some of them are delegating work to others (e.g.
>>>> Objects is written on top of accessors or accessors are  
>>>> rewritten on
>>>> top of Objects) - this seems to me just like extra layers/function
>>>> calls.
>>> Agreed.  I suggest that we have separate types for VM-specific  
>>> vs. JNI
>>> based accessors so we can have a clean kernel code and common code
>> split.
>>> As written elsewhere, the only delegation/adapter code will be from
>>> suncompat Unsafe to o.a.harmony types.
>>>>>> 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.
>>>> If all VM's are supposed to be 1.5+ compliant anyways, why not just
>>>> adding to the luni-kernel...
>>> Because we want to keep the modularity of concurrency utils separate
>>> from LUNI.  If there is no need for atomic/volatile operations  
>>> outside
>>> the concurrency module, then we should put them into a concurrent-
>> kernel.
>> There is a set of informational methods one would need to access
>> objects and arrays, regardless of whether the access is going to be
>> ordinary, volatile or atomic. They are sort of like (I'm taking the
>> signatures from the accessor package):
>> long getFieldID(Field f);
>> long getArrayBaseOffset(Class arrayClass)
>> int getArrayElementSize(Class arrayClass)
>> (Unsafe also has the similar method triple called objectFieldOffset 
>> (),
>> arrayBaseOffset(), arrayIndexScale()). If  we are doing a split
>> between the different types of access, then the questions are:
>> - Should the implementations of the above 3 methods be the part of  
>> the
>> accessor or the kernel classes set?,
>> - Should they be duplicated in both accessors and kernel?
>> - If we keep them in the accessors package where they currently are,
>> would it be OK for concurrent-kernel to have the dependencies on the
>> accessors package?
>>> <snip>
>>>>> Andrey: did you check that everything in Objects is covered by
>> existing
>>>>> accessor/atomics?
>>>> Yes, the Objects is a subset of the existing accessors + Atomics
>>>> combination.
>>> Then how about we delete 'Objects' and implement those parts of  
>>> Unsafe
>>> in terms of existing ObjectAccessor methods?
>> I think it would be possible, the only problem that I can see is a
>> slight difference between the types which are used in the accessors
>> and in the Unsafe:
>> - Unsafe works in terms of offsets and is using same offsets for
>> accessing objects and arrays. For ex, once you get an offset to a
>> specific element of an array, you can then use that offset for  
>> calling
>> putField() method for array just like it was an ordinary object.
>> - in the accessor package, objects and arrays are separate - objects
>> are accessed with fieldID while arrays are accessed with indexes.  
>> This
>> was done because the underlying JNI implementations of those accesses
>> will be different.
>> The missing piece in the current combination of the Atomics and
>> accessors is a volatile access to array. There could be two  
>> approaches
>> to deal with that:
>> 1) Go with the current design of the accessors and add
>> get/setXXXVolatile() methods for long/integer/boolean arrays to the
>> Atomics;
>> 2) Slightly redesign the accessors package and make it more
>> Unsafe-like - e.g. use the same offsets for objects and arrays. It  
>> may
>> lead, however, to some performance degradation - for the set/getXXX
>> methods of the ObjectAccessor, we would have to check if the  
>> Object is
>> array and use the different implementation in JNI code then.
>>> <snip>
>>>>> Do accessors need to be in kernel?  They are implemented solely in
>> terms
>>>>> of JNI - right?
>>>> Right. It is clear that now we have a set of API's that provide
>>>> different type of access to objects (e.g. simple, atomic or  
>>>> volatile),
>>>> arrays and threads. I can imagine the following types of it's
>>>> classification:
>>>> - VM specific or not (or, can be implemented with JNI or not)
>>> yep, this is our kernel vs. common code distinction.
>>>> - Package where they are needed (e.g. j.u.c, awt/swing, io or
>> whatever)
>>> yep, we need to judge where the best place is for each type.   
>>> Since they
>>> are o.a.harmony types the risk of putting them too 'low' (e.g.  
>>> luni) is
>>> that they bloat the module where they are not actually used; and the
>>> risk of putting them too 'high' (e.g. swing) is that we create
>>> dependencies 'up' the semantic stack.
>>> In this instance I think we only need to decide between whether
>>> accessors go into luni, concurrent, and misc (maybe misc gets rolled
>>> into those two?).
>> Probably the most natural place for the accessors would be somewhere
>> at luni - we may consider them as covering some gaps in the lang API
>> which are not allowing the classlib developers to access objects and
>> arrays easily.
>>>> - Objects they are accessing (e.g. object, array, thread)
>>> Do you think we need this distinction in the type hierarchy?  All
>>> accessors work on fundamental types, right?
>> I think the distinction between Arrays and Objects in the accessor
>> package is caused by the difference how the JNI spec treats the
>> objects and arrays. For arrays, JNI allows "raw" access to the memory
>> region occupied by the array in Java heap. Hence the thing you'd need
>> to know is an array type (array element size) and index within the
>> array. For objects, JNI doesn't expose anything except the abstract
>> fieldID. Those ID's may not necessarily represent the offsets within
>> the memory of object.
>> As I wrote earlier, we may avoid such distinction at some lost of the
>> performance and adding some pointer arithmetic which would translate
>> offsets in the arrays back to indexes which are used as the  
>> parameters
>> for JNI calls. It would be like:
>> index = <offset provided by user code> / <array element size>,
>> while the user would do in the code:
>> offset = <array element size> * <arrayIndexScale> + <arrayBaseOffset>
>> In other words, if we use JNI to implement access to the arrays and
>> keep Unsafe-like interface, we'll be doing extra computations
>> converting each time indexes to offsets in classlib code and then
>> converting offsets back to the indexes in the accessor's
>> implementation code.
>>>> We may pick one or another type of classification and split the API
>>>> into different pacakges/jars in accordance with it.
>>>> On the other hand, obviously all of these classes would have the  
>>>> same
>>>> mechanism for getting their instances, and most likely share the  
>>>> way
>>>> how fieldID's (or offsets) are obtained. In other words, it may be
>>>> unnatural to try to split them. This is why I proposed to keep  
>>>> them in
>>>> a single place.
>>> If we can think of a usecase for volatile/atomic operations outside
>>> concurrent then I agree they go into luni & luni-kernel.  If we  
>>> cannot
>>> then they are split into luni, concurrent, and concurrent-kernel.
>> The more clean way for classlib code to use the atomic variables  
>> would
>> be to create instances of the appropriate j.u.c.atomic classes, I
>> think.
>> It seems like the volatile variables can always just be declared with
>> the "volatile" keyword if needed.
>>>> Assuming that there is a portion in this API set which
>>>> is VM-specific, it probably may make sense to put them into kernel.
>>> ack
>>>>> +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.
>>>> Right, I would add the Atomics creation to the AccessorFactory  
>>>> if we
>>>> agreed that all of this stuff is of the same nature.
>>> Again, if they are all in the same component, then one factory is ok
>>> (but unnecessary imho) -- if they are in different components  
>>> then let's
>>> not couple them at this point.
>>> What do you think?
>> I agree it would be good to not couple them. The problem would be how
>> to deal with the "informational methods" (see above) which are
>> supposed to be same for all accesses, for example - where the method
>> which would report fieldID's should be located if we are splitting
>> accessors between multiple packages according to VM-dependence rule.
>> Thanks,
>> Andrey.
>>> Tim
>>> --
>>> 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
>> --
>> Andrey Chernyshev
>> Intel Middleware Products Division
>> ---------------------------------------------------------------------
>> 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

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

View raw message