harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [classlib][concurrent] Integrating into builds and snapshot
Date Mon, 28 Aug 2006 19:48:40 GMT
On 8/21/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> On 8/21/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> >
> >
> > Nathan Beyer wrote:
> > > Now that we're getting some good submissions to make the
> > > java.util.concurrent code to work with DRLVM, I'd like make a proposal for
> > > getting the code in the Class Library and a part of our regular builds,
> > > tests and snapshots.
> > >
> > >
> > >
> > >>From a technical/code integration standpoint, the go ahead assumption is
> > > that Harmony will have VMs implement a subset of the 'sun.misc.Unsafe'
> > > class, such that the concurrent code, most of which is in the public domain,
> > > from the Concurrency Interest Site [1] can be used as-is, as least to the
> > > greatest extent possible. Are there any major dissents to this?
> >
> > This is my understanding of what we already agreed to, and I'm getting a
> > note from Doug about the code provenance.
> >
>
> I was not able to see any open documentation on sun.misc.Unsafe on the
> web.  I did notice emails that describe using sun.misc.Unsafe to
> read/write specific memory addresses.  I suspect that both
> sun.misc.Unsafe and Jikes vmmagic do essentially the same thing.  That
> is, read/write and also compare/swap specific memory addresses from
> Java code.
>
> MMTk definitely relies on efficient JIT inlining of Jikes vmmagic.  It
> also looks like java.util.concurrent needs efficient JIT inlining of
> sun.misc.Unsafe.  If indeed both vmmagic and Unsafe do the same thing,
> it probably does not make sense to rewrite Concurrency or MMTk.  In
> other words, we might be stuck with supporting both APIs in the short
> term.

I agree that j.u.c. will need efficient inlining for the Unsafe.
However, if the Harmony impl of Unsafe does nothing but simple call
forwarding to the appropriate methods of vmmagic, then we probably
won't get that big overhead.
In other words, we can try keeping Unsafe interface as a bridge
between j.u.c. and various VM's at the price of one extra method call
to it's "real" implementation (which could be vmmagic in our case). It
would be nice, however, if we can agree with the concurrency group to
hide Unsafe under some other interface which would have a more neutral
package name (e.g. not sun.misc).

Thanks,
Andrey.


>
> In any case, can the sun.misc.Unsafe API be described on this mailing
> list?  It would help us all figure out what existing pieces can be
> reused to support high-performance java.util.concurrent.
>
> Thanks
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

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