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][concurrent] Integrating into builds and snapshot
Date Tue, 22 Aug 2006 00:37:39 GMT
The sun.misc.Unsafe service stub is available at
http://svn.apache.org/repos/asf/incubator/harmony/standard/sandbox/juc-propo
sal/concurrent/src/main/java/sun/misc/Unsafe.java.

This is my best guess estimate of the interface based on the j.u.c code.
There is a partial implementation of this class in DRLVM trunk.

-Nathan

> -----Original Message-----
> From: Weldon Washburn [mailto:weldonwjw@gmail.com]
> Sent: Monday, August 21, 2006 1:07 PM
> To: harmony-dev@incubator.apache.org; geir@pobox.com
> Subject: Re: [classlib][concurrent] Integrating into builds and snapshot
> 
> 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.
> 
> 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


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