-----Original Message-----
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 8:11 AM
To: [email protected]
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 ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--------------------------------------------------------------------
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
