Skip to main content

Q: JAI and disabling calls to native image libraries

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
4 replies [Last post]
jbhickey
Offline
Joined: 2011-07-28
Points: 0

Hi All:
I am a newbie to the forum and a novice at Java troubleshooting. Our company is currently having a problem with a third party product (Markview) running on Sun hardware and the 64-bit Sun Solaris 10 Update 9 O/S, using Weblogic 10.2.3/JRockit R27.5.6 middle tier software. We are using the 64-bit JRockit JVM. The application is an Accounts Payable document imaging solution, which creates and manipulates images primary in the TIFF format.
The problem we are having is that under load, we are seeing stack overflows, causing the JVM to crash and generate core dumps. The root cause has been traced to calls to the JAI which are invoking native acceleration using the Sun Solaris Sparcv9 library libmlib_image_v.so
We are currently investigating disabling the native accelerator to determine if the will resolve the stack overflow / JVM crashing issues. We plan to disable native acceleration in one of the following 3 ways:
-Dcom.sun.media.jai.disableMediaLib=true
or
-Dcom.sun.media.imageio.disableCodecLib=true
or simply renaming the image library so that it cannot be found and will revert to the pure Java implementation.
Q1: What is the difference between disabling the JAI medialib vs disabling the codec.
Q2: Despite running 64 bit O/S and 64 bit JVM and calling a 64 bit native library (libmlib_image_v.so), it appears the we have a memory ceiling of 4 GIG. We tried increasing the heap size from 3 GIG to 8 GIG and the crashes became more frequent (counter-intuitive). Any thoughts on this?
Thanks,
John Hickey

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rgd
Offline
Joined: 2005-08-23
Points: 0

Hey...

The media library implements native acceleration for JAI operators,
those that actually manipulate the image. The codec library implements
acceleration for I/O operations. If you're having problems with
libmlib_image then I would expect that to be the media library, although
I'm not 100% sure. You could try disabling just one at a time, see if
that helps.

I would not recommend renaming, as someone might have their own
installation of JAI already; renaming would either break their
installation, or be ineffective as it finds their version rather than
yours. The disable route is the best approach.

There never have been 64-bit builds of the JAI native libraries. That
is a sore spot on this list. So your native-acceleration libraries are
32-bit libraries, which would explain the memory issues. It might even
explain the crashes, if a 64-bit VM were trying to pass out-of-range
pointers to a 32-bit library. I'm a little surprised it would allow you
to load a 32-bit library though. You say libmlib_image_v.so is 64 bits
and that may be true, but that's the media library itself... the JAI
native code is in libmlib_jai*.so for Solaris, which as far as I
understand wraps the media library and is almost certainly 32-bits only.

Sounds like disabling the native acceleration is your best bet.

Hope that helps...

-Bob

On 7/28/11 9:37 AM, forums@java.net wrote:
> Hi All:
> I am a newbie to the forum and a novice at Java troubleshooting. Our
> company is currently having a problem with a third party product
> (Markview)
> running on Sun hardware and the 64-bit Sun Solaris 10 Update 9 O/S, using
> Weblogic 10.2.3/JRockit R27.5.6 middle tier software. We are using the
> 64-bit JRockit JVM. The application is an Accounts Payable document
> imaging
> solution, which creates and manipulates images primary in the TIFF format.
> The problem we are having is that under load, we are seeing stack
> overflows, causing the JVM to crash and generate core dumps. The root
> cause
> has been traced to calls to the JAI which are invoking native acceleration
> using the Sun Solaris Sparcv9 library *libmlib_image_v.so* We are
> currently investigating disabling the native accelerator to determine if
> the
> will resolve the stack overflow / JVM crashing issues. We plan to disable
> native acceleration in one of the following 3 ways:
> -Dcom.sun.media.jai.disableMediaLib=true or
> -Dcom.sun.media.imageio.disableCodecLib=true or simply renaming the image
> library so that it cannot be found and will revert to the pure Java
> implementation. Q1: What is the difference between disabling the JAI
> medialib vs disabling the codec. Q2: Despite running 64 bit O/S and 64
> bit JVM and calling a 64 bit native library (libmlib_image_v.so), it
> appears
> the we have a memory ceiling of 4 GIG. We tried increasing the heap size
> from 3 GIG to 8 GIG and the crashes became more frequent
> (counter-intuitive). Any thoughts on this? Thanks, John Hickey
>

neelin
Offline
Joined: 2006-02-03
Points: 0

On Thu, Jul 28, 2011 at 1:05 PM, Bob Deen wrote:

> There never have been 64-bit builds of the JAI native libraries.

I don't think that this is quite true. If I run the following command
in the jai-core source tree:

find . -name '*.so' -exec file {} \;

I get this:

./src/share/mediaLib/solaris/i386/libmlib_jai.so: ELF 32-bit LSB
shared object, Intel 80386, version 1 (SYSV), not stripped
./src/share/mediaLib/solaris/sparcv9/libmlib_jai_vis2.so: ELF 64-bit
MSB shared object, SPARC V9, version 1 (SYSV), not stripped
./src/share/mediaLib/solaris/sparcv9/libmlib_jai_vis.so: ELF 64-bit
MSB shared object, SPARC V9, version 1 (SYSV), not stripped
./src/share/mediaLib/solaris/sparcv9/libmlib_jai.so: ELF 64-bit MSB
shared object, SPARC V9, version 1 (SYSV), not stripped
./src/share/mediaLib/solaris/sparc/libmlib_jai_vis2.so: ELF 32-bit MSB
shared object, SPARC32PLUS, V8+ Required, Sun UltraSPARC1 Extensions
Required, Sun UltraSPARC3 Extensions Required, version 1 (SYSV), not
stripped
./src/share/mediaLib/solaris/sparc/libmlib_jai_vis.so: ELF 32-bit MSB
shared object, SPARC32PLUS, V8+ Required, Sun UltraSPARC1 Extensions
Required, version 1 (SYSV), not stripped
./src/share/mediaLib/solaris/sparc/libmlib_jai.so: ELF 32-bit MSB
shared object, SPARC, version 1 (SYSV), not stripped
./src/share/mediaLib/solaris/amd64/libmlib_jai.so: ELF 64-bit LSB
shared object, AMD x86-64, version 1 (SYSV), not stripped
./src/share/mediaLib/linux/i386/libmlib_jai.so: ELF 32-bit LSB shared
object, Intel 80386, version 1 (SYSV), not stripped
./src/share/mediaLib/linux/amd64/libmlib_jai.so: ELF 64-bit LSB shared
object, AMD x86-64, version 1 (SYSV), not stripped

We can clearly see a number of 64-bit medialib .so's for Solaris and
linux. I am not familiar with the various flavours of Solaris, so I do
not know which of these would be applicable to the problem mentioned
here.

> That is a sore spot on this list.

I believe that this is a reference to infamous bug 46
(http://java.net/jira/browse/JAI_CORE-46), which can be seen with this
command:

find . -name '*.dll' -exec file {} \;

Giving this output:

./src/share/mediaLib/windows/i386/mlib_jai_util.dll: PE32 executable
for MS Windows (DLL) (GUI) Intel 80386 32-bit
./src/share/mediaLib/windows/i386/mlib_jai_mmx.dll: PE32 executable
for MS Windows (DLL) (GUI) Intel 80386 32-bit
./src/share/mediaLib/windows/i386/mlib_jai.dll: PE32 executable for MS
Windows (DLL) (GUI) Intel 80386 32-bit

Only 32-bit on Windows :(

BTW, the Mac version (supported by Apple from snow leopard) supports
64-bit as well.

It is, however, entirely possible that the Solaris 64-bit version has
bugs in which handling of addresses beyond 32-bits lead to a crash.
Given the lack of support and lack of source code for the medialib
code and wrappers, I suspect that the best solution to the problem is
to disable acceleration. I too would recommend using the java
properties, if only to avoid the warning about missing libraries.

Peter

jbhickey
Offline
Joined: 2011-07-28
Points: 0

We tested the Markview application with JAI native acceleration disabled (-Dcom.sun.media.jai.disableMediaLib=true). This led our middle tier consultant to trace the source of the problem to a Markview call to a JAI library class/function called getscaledimage which according to the SUN bug database causes an infinite loop.

Side benefit of disabling JAI native acceleration is that we can now increase the heap size beyond the 4 GIG limit without the constant JVM crashing.

Thanks to all for input

John

jbhickey
Offline
Joined: 2011-07-28
Points: 0

Hi Bob:
Thanks for the quick reply! We suspected that 32-bit code was the culprit, but were unable to determine where the 32-bit stuff existed. The Markview application bundles JAI with their product in an executable archive (.ear) file, so we are unable to determine the bitness of those programs (or even find them).

We are hopeful that eliminating the native calls will resolve the crashing problem. If it does, the next step is to bump the java heap size beyond 4 GIG to see if we can handle more users without crashing.

Cheers,

John