Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of nbeyer@gmail.com designates
 64.233.162.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=OO0TOl7x1PLJEt8oglGREpmbiPOj40uaqCjoTKeiS/IdtxdVuCyTSWX8dHmx9WO25EHuJTu1FjCkQJtMAminr2suBQ9Ea52AmsRzqTqQAzW1G6MS0b9Nwbz+y7VPONpSCYU6axhXVr7Agi/sDAJV8QsMG+sNKqCIgKcWIPGOXAA=
Message-ID: <3b3f27c60704121219l514d098flff471214e0fc4405@mail.gmail.com>
Date: Thu, 12 Apr 2007 14:19:52 -0500
From: "Nathan Beyer" <ndbeyer@apache.org>
Sender: nbeyer@gmail.com
To: dev@harmony.apache.org
Subject: Re: [ibmvm][classlib][concurrent] java.util.concurrent doesn't work
 on IBM VM?
In-Reply-To: <3D8E84095C6A524A985B787423094E40DE819B@mssmsx411>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <3D8E84095C6A524A985B787423094E40DE819B@mssmsx411>

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 <vasily.m.zakharov@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
>