harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Date Tue, 26 Sep 2006 12:48:44 GMT

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...


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

View raw message