On 8/21/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 8/21/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
