I would suggest we avoid it until we resolve the VMI and get DRLVM and the IBMVM with similar support.
- Nathan On 4/12/07, Zakharov, Vasily M <[EMAIL PROTECTED]> wrote:
Hmm, the situation seems uncertain. In this case, the third question becomes even more actual: - Can/should we use Concurrent package in implementation of other Harmony packages (like AWT) ? Vasily -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Beyer Sent: Thursday, April 12, 2007 11:20 PM To: [EMAIL PROTECTED] Subject: Re: [ibmvm][classlib][concurrent] java.util.concurrent doesn't work on IBM VM? The plan for this was to define the VM Objects/Threads classes and implement sun.misc.Unsafe using the VM Objects/Threads, which would be part of the luni-kernel. Then, each VM would implement the VM Objects/Threads classes as part their implementation of luni-kernel. I believe the IBM folks were willing to implement things this way, but everything seems to fall apart when we discussed the Objects/Threads classes, so they never really got finalized and for some reason the DRLVM code was hacked together to implement sun.misc.Unsafe directly and implement LockSupport. If we can pull this back together, perhaps we can get the IBM folks to implement this stuff for us. :) -Nathan On 4/12/07, Zakharov, Vasily M <[EMAIL PROTECTED]> wrote: > Hi, all, > > As far as I can see, currently java.util.concurrent package doesn't work > with IBM VM, because it relies on sun.misc.Unsafe that doesn't work with > IBM VM. So I've got a number of interesting questions: > > - Does IBM VM have an operational implementation of sun.misc.Unsafe ? > > - What is the "official" status of Concurrent package implementation in > Harmony with respect to IBM VM ? > > - Can/should we use Concurrent package in implementation of other > Harmony packages (like AWT) ? > > This issue showed up while investigating AWT issue HARMONY-3601. The > simple test that demonstrates the problem is simply running: > > java java.util.concurrent.locks.LockSupport > > Consider the following printouts: > > DRL VM: > > Uncaught exception in main: > java.lang.NoSuchMethodError: main > (this is clearly the correct behavior) > > IBM VM: > > Exception in thread "main" java.lang.NoClassDefFoundError: > sun.misc.Unsafe > at > java.util.concurrent.locks.LockSupport.<clinit>(LockSupport.java:80) > at java.lang.J9VMInternals.initializeImpl(Native Method) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:177) > (sun.misc.Unsafe is just absent) > > IBM VM (with Suncompat module enabled in bootclasspath.properties): > > Exception in thread "main" java.lang.NoClassDefFoundError: > org.apache.harmony.kernel.vm.Objects > at sun.misc.Unsafe.<init>(Unsafe.java:64) > at sun.misc.Unsafe.<clinit>(Unsafe.java:34) > at java.lang.J9VMInternals.initializeImpl(Native Method) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:177) > at > java.util.concurrent.locks.LockSupport.<clinit>(LockSupport.java:80) > at java.lang.J9VMInternals.initializeImpl(Native Method) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:177) > > This stack demonstrates that the default implementation of > sun.misc.Unsafe in Suncompat module doesn't work with IBM VM (it > wouldn't work with DRL VM either, but DRL VM has its own implementation > in jdk/jre/bin/kernel.jar), as org.apache.harmony.kernel.vm.Objects > class doesn't exist in jdk/jre/bin/luni-kernel.jar. > > IBM VM has luni-kernel-stubs.jar in jdk/jre/lib/boot, but it's not > mentioned in bootclasspath.properties. Adding it to bootclasspath > manually seems to resolve the problem: > > IBM VM (with luni-kernel-stubs.jar appended to bootclasspath): > > Uncaught exception in main: > java.lang.NoSuchMethodError: main > (seems like the correct behavior, though the jar name makes me think > this solution is not really proper) > > Vasily Zakharov > Intel ESSD >
