21

I'm trying to run a 32bit Hotspot JVM on a 64bit Debian Mint machine. At first sight it all works until you'll try to run something using Swing:

java.lang.UnsatisfiedLinkError: /opt/javadev/jdk1.7.0_03_32b/jre/lib/i386/xawt/libmawt.so:   
libXext.so.6: cannot open shared object file: No such file or directory

Adding that to the library path: export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu.

But then it gives this error: 

java.lang.UnsatisfiedLinkError: /opt/javadev/jdk1.7.0_03_32b/jre/lib/i386/xawt/libmawt.so: 
libXext.so.6: wrong ELF class: ELFCLASS64

Any idea what else has to be done here ?

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
Jan Goyvaerts
  • 2,913
  • 4
  • 35
  • 48
  • 5
    32-bit processes cannot load 64-bit libraries. You'll need to install 32-bit compatibility libraries. On Ubuntu you'd need to install the package `ia32-libs`. Don't know what the equivalent is on Debian. – Jesper Feb 22 '12 at 11:13
  • 1
    *Why* are you trying to run a 32bit JVM on a 64bit machine again? – Marcelo Feb 22 '12 at 11:14
  • @Jesper That did it ! File it as an answer if you want to. MANY thanks indeed ! :-D – Jan Goyvaerts Feb 22 '12 at 11:22
  • @Marcelo For performance reasons mainly. In my case to run Netbeans with a very large C++ project. A 32bit JVM performs better compared to a 64bit because the references are half the size. Allowing more to be put into caches. Resulting in a higher performance. (that's what I read at least) In my case I have LOADS of objects created when Netbeans initializes the project. In my case it keeps the memory footprint down. – Jan Goyvaerts Feb 22 '12 at 11:25
  • @Qwe Now I do :-) With the advice of Jesper. But many thanks for this lightning fast replies. :-) – Jan Goyvaerts Feb 22 '12 at 11:27
  • @JanGoyvaerts - on x86 you have (roughly) half the registers though so there's going to be more load/stores to memory in quite a lot of cases - did you try benchmarking it? – Flexo Feb 22 '12 at 11:56
  • 2
    @Marcelo -- A 32-bit JVM will generally run in a smaller heap (and therefore faster) than a 64-bit one. A compromise is the IBM J9 JVM, which has a "32/64 bit mode" which allows a heap approaching 68G while using only 32-bit pointers. – Hot Licks Feb 22 '12 at 11:58
  • @HotLicks This comment would deserve an up, a pipe and a +50 bounty if it had been an answer to one of my questions :-) – peterh Aug 25 '16 at 11:47

4 Answers4

15

To be able to use the 32-bit JVM, you'll need to have the 32-bit compatibility libraries installed. The second error message means that the 32-bit JVM process is trying to load a 64-bit library; that doesn't work.

On Ubuntu you'd have to install the package ia32-libs, which contains the 32-bit compatibility libraries for 64-bit Ubuntu.

UPDATE: Ubuntu 13.10 introduced multi-arch which replaced ia32-libs with libstdc++6:i386 libgcc1:i386 zlib1g:i386 libncurses5:i386. Source: https://stackoverflow.com/a/10473415/14731

Community
  • 1
  • 1
Jesper
  • 202,709
  • 46
  • 318
  • 350
14

I just had the same issue on Ubuntu 14.04, where I wanted to keep my 32-bit Oracle Java on a 64-bit install. ia32-libs is gone since Ubuntu 13.10, and now the glib answer is "just download the i386 libraries that you need". Unfortunately, there doesn't seem to be an easy way to find out which libraries those are.

The simple remedy is to install 32-bit OpenJDK as 

sudo apt-get install openjdk-7-jdk:i386

That pulls in a large number of i386 libraries. You can uninstall the OpenJDK again if you like, but I left it in place so I don't accidentally autoremove the libraries.

Put Oracle JDK on the PATH, and now Eclipse and NetBeans will start up fine.

cayhorstmann
  • 3,192
  • 1
  • 25
  • 17
7

I had similar problems with CentOS 6.4 and the solution was to install the ia32-libs equivalents (as root): yum install glibc.i686 libXext.i686 libXtst.i686

Jim H
  • 106
  • 1
  • 3
  • I tried the above but I am getting No package available.No package glibc.i686 available. No package libXext.i686 available. No package libXtst.i686 available. – java_enthu Dec 02 '14 at 06:30
  • 1
    Thanks from the CentOS/RedHat/Fedora users. Just note that for the latest JRE/JDK the libgcc.i686 package is also needed. – Dime Feb 16 '16 at 09:15
4

If you want to use 32-bit references, use the 64-bit JVM. It uses 32-bit references by default for up to 32 GB of memory (more than a 32-bit program can normally) from Java 6 update 23.

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

@Hot Licks comments that the IBM JVM can access up to 68 GB with a "32/64 bit mode"

If you need to use more than this amount (or indeed anything like it), I would use off heap memory. This keeps full GC times under control and means you can always use 32-bit references.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Thanks ! I didn't know the "compressed oops" were enabled by default now. And that's why it didn't make any difference for Netbeans. It was already using 32bit references. So in the end it doesn't make any difference. Weird that the Netbeans support team asked me to run a 32bit JVM... – Jan Goyvaerts Feb 22 '12 at 15:35
  • I am often amazed when I see advice on SO which 5 - 10 years out of date. ;) Its quite natural to assume a 64-bit process uses 64-bit pointers, it does in C which is assumed to be the most efficient. – Peter Lawrey Feb 23 '12 at 08:11
  • I guess it would be better in some way. But I've had numerous people telling the Client JVM (32bit) is somewhat faster. And in "Java Performance", a recent book, it is stated that this is because some cache contains more entries because they're smaller. Hence, a better hit rate. Hence the performance increase. I'm always running with the compressed oops on. But ignored until now it was applied by default for 32GB or lower. – Jan Goyvaerts Feb 23 '12 at 10:33