harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Date Tue, 26 Sep 2006 17:12:49 GMT


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


Mime
View raw message