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
|