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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
