You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nb...@kc.rr.com> on 2006/09/18 03:38:41 UTC
[classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
I've added some classes[1][2] to luni-kernel in the
org.apache.harmony.kernel.vm package that are intended the VMI replacement
for the sun.misc.Unsafe class. The intent is to provide a VMI class to
support java.util.concurrent. Initially this will be done by implementing
the sun.misc.Unsafe in 'suncompat' module in terms of these new classes.
For the most part, the methods are essentially the subset of Unsafe that's
needed for java.util.concurrent. I've separated the methods into two
classes; Threads [1] for the threading features and Objects [2] for the
object manipulation features. My initial thought is that Threads may be
extended to provide additional support needed for lang-management features.
Please take a look at the classes and provide some feedback.
[1]
http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/mo
dules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/Threads.java
[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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
Andrey Chernyshev wrote:
> On 9/21/06, Nathan Beyer <nb...@kc.rr.com> wrote:
>> > From: Tim Ellison
<snip>
>> 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?
>
> The other option could be just to check that the class loader of the
> calling method is the same as the one which was used to load Threads -
> this is how it is done in the AccessorFactory. I suspect the
> PriviledgedAction block would do eventually the same, but possibly
> with some extra expense on creating the PriviledgedAction object.
Agreed, make the constructor private/default visibility then the
getSingleton() method can check...
if (VM.callerClassLoader() != null) { throw new SecurityException(); }
>> > 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.
>
> I completely agree with this point of view.
The only 'duplication' of API behavior will be the functionality in the
o.a.harmony types and the sun.misc.Unsafe adapter. That is, let's
design the o.a.harmony types along the dimensions we want to distinguish
and write Unsafe in terms of those.
<snip>
> I don't know the original intent that was put in the Unsafe design. My
> only guesses would be:
> To access the field in JNI code, you'd finally need the jfieldID. Then
> the question comes - what to remember in the Java heap, 64-bit fieldID
> or a Field object? The Field object is likely to consume more memory
> in the Java heap compared to the long value.
>
> Perhaps there could be also some pointer arithmetic with fieldID's
> assuming that they are corresponding to the field offsets in the
> object, and assuming that the layout of fields in the objects is
> known. But I'm not sure if we want our classlib code be dependent on
> that - ID's could be more abstract than the offsets.
No point in speculating, let's do the right thing for our needs.
Regards,
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/21/06, Nathan Beyer <nb...@kc.rr.com> 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?
The other option could be just to check that the class loader of the
calling method is the same as the one which was used to load Threads -
this is how it is done in the AccessorFactory. I suspect the
PriviledgedAction block would do eventually the same, but possibly
with some extra expense on creating the PriviledgedAction object.
>
> >
> > > 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.
I completely agree with this point of view.
>
> >
> > > 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].
I don't know the original intent that was put in the Unsafe design. My
only guesses would be:
To access the field in JNI code, you'd finally need the jfieldID. Then
the question comes - what to remember in the Java heap, 64-bit fieldID
or a Field object? The Field object is likely to consume more memory
in the Java heap compared to the long value.
Perhaps there could be also some pointer arithmetic with fieldID's
assuming that they are corresponding to the field offsets in the
object, and assuming that the layout of fields in the objects is
known. But I'm not sure if we want our classlib code be dependent on
that - ID's could be more abstract than the offsets.
Thanks,
Andrey.
>
> [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
>
>
--
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Mark Hindess <ma...@googlemail.com>.
On 24 September 2006 at 14:29, "Nathan Beyer" <nb...@kc.rr.com> wrote:
>
> * 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.
I'd always assumed we'd merge misc (which I integrated from the
awt/swing contribution) in to the luni module. I probably mentioned it
when I did the integration (since it was part of my justification for
converting the misc natives from C++ to C.)
Currently, they are VM-independent so I'd say they should say in a
classlib module.
-Mark.
---------------------------------------------------------------------
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 24, 2006, at 3:55 PM, Nathan Beyer wrote:
>>
>> 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 :)
>
> Are you referring to "sun.misc.Unsafe"? If so, my statement was
> confusing; I
> was referring to the "org.apache.harmony.misc" stuff - I don't like
> that
> Harmony has a 'misc' sub package and module. I know we can't do
> anything the
> suncompat stuff. Sorry for confusing you.
No, my apologies. I should have taken a look. I really don't mind a
misc or util package, although for what you are talking about, I
*think* I agree, but given the usefulnes of my last observation, I'll
go read to be sure :)
geir
>
> -Nathan
>>
>>>
>>> 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....@gmail.com> wrote:
>>>>> Andrey Chernyshev wrote:
>>>>>> On 9/20/06, Tim Ellison <t....@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
>
>
> ---------------------------------------------------------------------
> 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
RE: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
> Sent: Sunday, September 24, 2006 2:37 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
> for java.util.concurrent
>
>
> 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 :)
Are you referring to "sun.misc.Unsafe"? If so, my statement was confusing; I
was referring to the "org.apache.harmony.misc" stuff - I don't like that
Harmony has a 'misc' sub package and module. I know we can't do anything the
suncompat stuff. Sorry for confusing you.
-Nathan
>
> >
> > 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....@gmail.com> wrote:
> >>> Andrey Chernyshev wrote:
> >>>> On 9/20/06, Tim Ellison <t....@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
---------------------------------------------------------------------
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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....@gmail.com> wrote:
>>> Andrey Chernyshev wrote:
>>>> On 9/20/06, Tim Ellison <t....@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
RE: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geir@pobox.com]>
>
> On Sep 26, 2006, at 1:16 PM, Tim Ellison wrote:
>
> > Geir Magnusson Jr. wrote:
> >> On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
> >>> It sounds like you prefer not to split them, which would put an
> >>> extra
> >>> burden on the VM-port to implement more stuff. If they were
> >>> split then
> >>> the consumer (classlib developer) would/may have to use both types.
> >>
> >> Is that so bad, the latter? Seems like we get it right once, and
> >> then
> >> it makes it easier for others to integrate w/ Harmony classlib...
> >
> > Is that question to me? No it is not so bad, that would be my
> > preferred
> > solution, but Nathan indicated that he would prefer to put them
> > together.
>
> Yeah - mine too instinctively, but I've not been in that code...
>
Here's my perspective on things:
* The atomic operations are only the compare and swaps and there are only
three needed - casInt, casLong and casObject. The volatile set/get are just
part of the object accessor API.
* The CAS operations have nearly the same signature as the set methods. For
example, consider the int methods.
public boolean compareAndSwapInt(Object o, long fld, int exp, int val);
public void putInt(Object o, long fld, int val);
These seem functionality very close and related.
Now, I do understand Tim's comments about keeping the accessor portable code
separate from the VM-specific code. Would it be possible to perhaps put the
portable pieces of accessor and the java interfaces in luni and put the
required stubs in luni-kernel? Keep in mind, I have limited experience with
designing the API interactions between Java and native code, so take these
comments a bit lightly. Regardless, my thought is that we can keep the VM's
Java API together, but perhaps delegate the native part in some clean
manner.
-Nathan
---------------------------------------------------------------------
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 26, 2006, at 1:16 PM, Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
>>> It sounds like you prefer not to split them, which would put an
>>> extra
>>> burden on the VM-port to implement more stuff. If they were
>>> split then
>>> the consumer (classlib developer) would/may have to use both types.
>>
>> Is that so bad, the latter? Seems like we get it right once, and
>> then
>> it makes it easier for others to integrate w/ Harmony classlib...
>
> Is that question to me? No it is not so bad, that would be my
> preferred
> solution, but Nathan indicated that he would prefer to put them
> together.
Yeah - mine too instinctively, but I've not been in that code...
>
> Regards,
> 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
>
---------------------------------------------------------------------
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
>> It sounds like you prefer not to split them, which would put an extra
>> burden on the VM-port to implement more stuff. If they were split then
>> the consumer (classlib developer) would/may have to use both types.
>
> Is that so bad, the latter? Seems like we get it right once, and then
> it makes it easier for others to integrate w/ Harmony classlib...
Is that question to me? No it is not so bad, that would be my preferred
solution, but Nathan indicated that he would prefer to put them together.
Regards,
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
> Nathan Beyer wrote:
>>
>
>> 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.
>
> Ok, so let's agree that the code in misc gets merged into kernel,
> and we
> drop the idea of a concurrency-kernel. The only question that remains
> open for me is whether we need to split the accessors into common
> (JNI-based) methods and kernel (VM-specific) methods.
>
> It sounds like you prefer not to split them, which would put an extra
> burden on the VM-port to implement more stuff. If they were split
> then
> the consumer (classlib developer) would/may have to use both types.
Is that so bad, the latter? Seems like we get it right once, and
then it makes it easier for others to integrate w/ Harmony classlib...
geir
---------------------------------------------------------------------
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
RE: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>
> Andrey Chernyshev wrote:
> > So if we built the full code path, would the picture be like:
> >
> > j.u.concurrent.atomic.AtomicXXXX //
> > | // untouched JSR 166
> > \/ //
> > Unsafe //
> > |
> > \/
> > Objects // What we propose as Unsafe replacement
> > to JSR
> > |
> > \/
> > accessors in kernel
> >
> > or, it will be something different?
>
> Actually I was thinking more like this:
>
> j.u.concurrent.atomic.AtomicXXXX
> |
> \/
> Unsafe
> +-------+-------+
> | |
> \/ \/
> ObjectAccessor AtomicAccessor (in kernel)
>
> i.e. we are free to implement the Unsafe operations in terms of multiple
> types in harmony. Any sensible name is fine by me.
This is what I had in mind as well. Though, ObjectAccessor and
AtomicAccessor would be merged into one interface (more on this in the other
thread).
-Nathan
>
> <snip>
>
> > From the usability point of view, the most convenient way to split API
> > could be according to the functionality exposed, rather than the
> > underlying implementation specifics.
>
> True, but IMHO its not much of a usability inconvenience to use two
> types, and that allows us to separate the VM-specific behavior into a
> different type, so it can be put into the kernel module. Unlike Thread,
> Class, etc. there is no state in accessor instances, so I don't see an
> advantage for VMs to define those types outright.
>
> If you feel strongly otherwise then it simply means there is more for
> the VM writer to do.
>
> > For accessors we currently have two separate classes, one for objects
> > and one for arrays. We may complement them both with volatile and
> > atomic type of access. The other option could be to put volatile and
> > atomic access into a separate class, as it was suggested. May be it
> > can be named "AtomicAccessor"? Either "Objects" or "Atomics" class
> > name doesn't seem to align nicely with the other existing
> > "XXXAccessors".
>
> Can you implement Unsafe in terms of these? How can you go from a field
> offset (in Unsafe API) to a field id (in accessor API)?
>
> Regards,
> 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
---------------------------------------------------------------------
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
Andrey Chernyshev wrote:
> So if we built the full code path, would the picture be like:
>
> j.u.concurrent.atomic.AtomicXXXX //
> | // untouched JSR 166
> \/ //
> Unsafe //
> |
> \/
> Objects // What we propose as Unsafe replacement
> to JSR
> |
> \/
> accessors in kernel
>
> or, it will be something different?
Actually I was thinking more like this:
j.u.concurrent.atomic.AtomicXXXX
|
\/
Unsafe
+-------+-------+
| |
\/ \/
ObjectAccessor AtomicAccessor (in kernel)
i.e. we are free to implement the Unsafe operations in terms of multiple
types in harmony. Any sensible name is fine by me.
<snip>
> From the usability point of view, the most convenient way to split API
> could be according to the functionality exposed, rather than the
> underlying implementation specifics.
True, but IMHO its not much of a usability inconvenience to use two
types, and that allows us to separate the VM-specific behavior into a
different type, so it can be put into the kernel module. Unlike Thread,
Class, etc. there is no state in accessor instances, so I don't see an
advantage for VMs to define those types outright.
If you feel strongly otherwise then it simply means there is more for
the VM writer to do.
> For accessors we currently have two separate classes, one for objects
> and one for arrays. We may complement them both with volatile and
> atomic type of access. The other option could be to put volatile and
> atomic access into a separate class, as it was suggested. May be it
> can be named "AtomicAccessor"? Either "Objects" or "Atomics" class
> name doesn't seem to align nicely with the other existing
> "XXXAccessors".
Can you implement Unsafe in terms of these? How can you go from a field
offset (in Unsafe API) to a field id (in accessor API)?
Regards,
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/26/06, Tim Ellison <t....@gmail.com> wrote:
> 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.
>
> That's the right approach.
So if we built the full code path, would the picture be like:
j.u.concurrent.atomic.AtomicXXXX //
| // untouched JSR 166
\/ //
Unsafe //
|
\/
Objects // What we propose as Unsafe replacement to JSR
|
\/
accessors in kernel
or, it will be something different?
>
> > 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
>
> Yep, the volatile and atomic operations are VM specific (need to go into
> luni-kernel); the misc module only has portable methods at the moment.
>
> > 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.
>
> Ok, so let's agree that the code in misc gets merged into kernel, and we
> drop the idea of a concurrency-kernel. The only question that remains
> open for me is whether we need to split the accessors into common
> (JNI-based) methods and kernel (VM-specific) methods.
>From the usability point of view, the most convenient way to split API
could be according to the functionality exposed, rather than the
underlying implementation specifics. For accessors we currently have
two separate classes, one for objects and one for arrays. We may
complement them both with volatile and atomic type of access.
The other option could be to put volatile and atomic access into a
separate class, as it was suggested. May be it can be named
"AtomicAccessor"? Either "Objects" or "Atomics" class name doesn't
seem to align nicely with the other existing "XXXAccessors".
Thanks,
Andrey.
>
> It sounds like you prefer not to split them, which would put an extra
> burden on the VM-port to implement more stuff. If they were split then
> the consumer (classlib developer) would/may have to use both types.
>
> > * 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.
>
> yep, go ahead and move them and remove the 'misc' module.
>
> > 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.
>
> I just ask you to consider the kernel / non-kernel split. When they go
> into kernel they are no longer shared code (and any fixes or changes we
> need to put in there have to be propagated to each VM).
>
> Regards,
> Tim
>
> > -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....@gmail.com> wrote:
> >>> Andrey Chernyshev wrote:
> >>>> On 9/20/06, Tim Ellison <t....@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
> >
> >
>
> --
>
> 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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
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.
That's the right approach.
> 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
Yep, the volatile and atomic operations are VM specific (need to go into
luni-kernel); the misc module only has portable methods at the moment.
> 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.
Ok, so let's agree that the code in misc gets merged into kernel, and we
drop the idea of a concurrency-kernel. The only question that remains
open for me is whether we need to split the accessors into common
(JNI-based) methods and kernel (VM-specific) methods.
It sounds like you prefer not to split them, which would put an extra
burden on the VM-port to implement more stuff. If they were split then
the consumer (classlib developer) would/may have to use both types.
> * 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.
yep, go ahead and move them and remove the 'misc' module.
> 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.
I just ask you to consider the kernel / non-kernel split. When they go
into kernel they are no longer shared code (and any fixes or changes we
need to put in there have to be propagated to each VM).
Regards,
Tim
> -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....@gmail.com> wrote:
>>> Andrey Chernyshev wrote:
>>>> On 9/20/06, Tim Ellison <t....@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
>
>
--
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
RE: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
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.
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....@gmail.com> wrote:
> > Andrey Chernyshev wrote:
> > > On 9/20/06, Tim Ellison <t....@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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
Andrey Chernyshev wrote:
> On 9/22/06, Tim Ellison <t....@gmail.com> 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 (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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/22/06, Tim Ellison <t....@gmail.com> wrote:
> Andrey Chernyshev wrote:
> > On 9/20/06, Tim Ellison <t....@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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
Andrey Chernyshev wrote:
> On 9/20/06, Tim Ellison <t....@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.
<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.
<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?
<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?).
> - 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?
> 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.
> 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?
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/20/06, Tim Ellison <t....@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.
>
> > 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?
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.
>
> > 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...
>
> > 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?
Yes, the Objects is a subset of the existing accessors + Atomics combination.
>
> > 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>.
Right, the initial version was containing Field as a parameter because
the intent was to have no dependencies on accessors package (Atomics
might be in the kernel set, but the accessors are currently not).
>
> > 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.
I've noticed that Objects have added simple put/getLong operations
which were not in the Atomics, I'm not sure if the j.u.c code really
needs them (I thought it only needs either atomic or volatile access).
>
> > 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?
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)
- Package where they are needed (e.g. j.u.c, awt/swing, io or whatever)
- Objects they are accessing (e.g. object, array, thread)
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. Assuming that there is a portion in this API set which
is VM-specific, it probably may make sense to put them into kernel.
>
> +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.
>
> 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
>
>
--
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
RE: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
Moved.
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
> Sent: Thursday, September 21, 2006 5:14 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
> for java.util.concurrent
>
> +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
---------------------------------------------------------------------
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
+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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
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
RE: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Nathan Beyer <nb...@kc.rr.com>.
> -----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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Posted by Andrey Chernyshev <a....@gmail.com>.
On 9/18/06, Nathan Beyer <nb...@kc.rr.com> wrote:
> I've added some classes[1][2] to luni-kernel in the
> org.apache.harmony.kernel.vm package that are intended the VMI replacement
> for the sun.misc.Unsafe class. The intent is to provide a VMI class to
> support java.util.concurrent. Initially this will be done by implementing
> the sun.misc.Unsafe in 'suncompat' module in terms of these new classes.
>
>
>
> For the most part, the methods are essentially the subset of Unsafe that's
> needed for java.util.concurrent. I've separated the methods into two
> classes; Threads [1] for the threading features and Objects [2] for the
> object manipulation features. My initial thought is that Threads may be
> extended to provide additional support needed for lang-management features.
>
>
>
> Please take a look at the classes and provide some feedback.
>
>
>
> [1]
> http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/mo
> dules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/Threads.java
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.
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?
>
> [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, plus the o.a.util.concurrent.Atomics [5] from the DRLVM. 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 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.
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.
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?
Thanks,
Andrey.
[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
>
>
>
>
--
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
Re: [classlib][vmi] VMI classes for Thread/Object manipulation for
java.util.concurrent
Posted by Tim Ellison <t....@gmail.com>.
Thanks Nathan -- I'll take a look and post comments back here.
Regards,
Tim
Nathan Beyer wrote:
> I've added some classes[1][2] to luni-kernel in the
> org.apache.harmony.kernel.vm package that are intended the VMI replacement
> for the sun.misc.Unsafe class. The intent is to provide a VMI class to
> support java.util.concurrent. Initially this will be done by implementing
> the sun.misc.Unsafe in 'suncompat' module in terms of these new classes.
>
>
>
> For the most part, the methods are essentially the subset of Unsafe that's
> needed for java.util.concurrent. I've separated the methods into two
> classes; Threads [1] for the threading features and Objects [2] for the
> object manipulation features. My initial thought is that Threads may be
> extended to provide additional support needed for lang-management features.
>
>
>
> Please take a look at the classes and provide some feedback.
>
>
>
> [1]
> http://svn.apache.org/repos/asf/incubator/harmony/enhanced/classlib/trunk/mo
> dules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/Threads.java
>
> [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
>
>
>
>
--
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