You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Zakharov, Vasily M" <va...@intel.com> on 2007/04/12 21:03:39 UTC

[ibmvm][classlib][concurrent] java.util.concurrent doesn't work on IBM VM?

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

Re: [ibmvm][classlib][concurrent] java.util.concurrent doesn't work on IBM VM?

Posted by Nathan Beyer <nd...@apache.org>.
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 <va...@intel.com> 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: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan
> Beyer
> Sent: Thursday, April 12, 2007 11:20 PM
> To: dev@harmony.apache.org
> 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 <va...@intel.com> 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
> >
>

RE: [ibmvm][classlib][concurrent] java.util.concurrent doesn't work on IBM VM?

Posted by "Zakharov, Vasily M" <va...@intel.com>.
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: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan
Beyer
Sent: Thursday, April 12, 2007 11:20 PM
To: dev@harmony.apache.org
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 <va...@intel.com> 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
>

Re: [ibmvm][classlib][concurrent] java.util.concurrent doesn't work on IBM VM?

Posted by Nathan Beyer <nd...@apache.org>.
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 <va...@intel.com> 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
>