Tim Ellison wrote:
Just revisiting this thread -- and even I can't decipher what I wrote as
I ran out the door.
Let me try again. Rather than put sun.misc.Unsafe into luni-kernel I
suggest that we have an o.a.h.kernel.vm.Risky[1] type containing just
the relevant subset of operations that we need for concurrent to work,
and put that subset into kernel. Then we can implement Unsafe in terms
of those methods and work on convincing the concurrency group to
generalize their impl.
Fine w/ me.
Once we have the Harmony subset defined I can look at getting them into
the IBM VME.
Thanks
[1] or o.a.h.concurrent... package, or whatever we decide.
Regards,
Tim
Tim Ellison wrote:
Nathan Beyer wrote:
For those kind souls working that help release the IBM VME, I'd like to ask
for an implementation of the "sun.misc.Unsafe" interface for the next
release to facilitate the 'concurrent' modules continued development. As
such, the only portion of the Unsafe class that would need to be implemented
is what's defined in the 'luni-kernel' module. Additionally, the
'concurrent' module has one other requirement and that's the implementation
of a native method in AtomicLong [1]. My initial goal it to be able to
enable all of the tests in the 'concurrent' module's build (all tests are
currently disabled).
Hey Nathan -- I'm just about to set off for a few days, but briefly, I'd
expect that we'd agree on an addition to the luni kernel for some
o.a.h.FooBar type that has the required functionality, and create
sun.misc in the suncompat component.
Regards,
Tim
Let me and the list know how we can help if there's anything needed. Thanks.
-Nathan
[1] private static native boolean VMSupportsCS8();
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
