harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib][vmi] VMI classes for Thread/Object manipulation for java.util.concurrent
Date Wed, 27 Sep 2006 04:41:18 GMT
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> 
> 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.

This is what I had in mind as well. Though, ObjectAccessor and
AtomicAccessor would be merged into one interface (more on this in the other
thread).

-Nathan

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


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