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 05:23:22 GMT
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geir@pobox.com]> 
> On Sep 26, 2006, at 1:16 PM, Tim Ellison wrote:
> > Geir Magnusson Jr. wrote:
> >> On Sep 26, 2006, at 6:36 AM, Tim Ellison wrote:
> >>> 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...
> >
> > Is that question to me?  No it is not so bad, that would be my
> > preferred
> > solution, but Nathan indicated that he would prefer to put them
> > together.
> Yeah - mine too instinctively, but I've not been in that code...

Here's my perspective on things:
* The atomic operations are only the compare and swaps and there are only
three needed - casInt, casLong and casObject. The volatile set/get are just
part of the object accessor API.
* The CAS operations have nearly the same signature as the set methods. For
example, consider the int methods. 

public boolean compareAndSwapInt(Object o, long fld, int exp, int val);

public void putInt(Object o, long fld, int val);

These seem functionality very close and related.

Now, I do understand Tim's comments about keeping the accessor portable code
separate from the VM-specific code. Would it be possible to perhaps put the
portable pieces of accessor and the java interfaces in luni and put the
required stubs in luni-kernel? Keep in mind, I have limited experience with
designing the API interactions between Java and native code, so take these
comments a bit lightly. Regardless, my thought is that we can keep the VM's
Java API together, but perhaps delegate the native part in some clean


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