Andrey Chernyshev wrote: > On 9/22/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
<snip> > 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?, These would be defined on a kernel class, since they depend upon the object layout, which is the prerogative of the VM. > - Should they be duplicated in both accessors and kernel? No need. > - 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? Thinking about it a bit more, we should just go ahead and define them in luni-kernel (and I'll drop the idea of concurrent-kernel). These may be more generally useful. <snip> >> 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. Hmm, that's too bad; it implies that we have to use field offset, since we can go from fieldID to field offset, but not the other way so easily. My preference would have been to use fieldID & indexes too. > 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; I agree. > 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> >> 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. I agree. <snip> >> 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. Sure, but I was thinking of a more dynamic case where you may need atomicity/volatile. If we put them into luni then classlib developers have the option. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
