Mixing coherence on 64-bit and 32 bit jvms

Hello,
Can you mix 32bit and 64bit JVMs for Coherence or does Coherence require Java binaries be compatible across all nodes.
Thanks,
Heji

Hello,
You can cluster heterogeneous JDK across heterogeneous operating systems.
So yes you can mix 32bit and 64bit JVMs.
-Dave

Similar Messages

INST-07408: Unable to install or configure the product on a 32-bit JVM on a 64-bit machine. Make sure to install and configure the product in supported modes.

Hi there, i have an issue installing oracle forms and reports. its throwing this error"INST-07408: Unable to install or configure the product on a 32-bit JVM on a 64-bit machine. Make sure to install and configure the product in supported modes." on step 5. I have jdk 64bit installed, weblogic server was installed successfully but iam getting stuck somehow.
Below are details of my pc.
OS Name    Microsoft Windows 7 Professional
Version    6.1.7601 Service Pack 1 Build 7601
Other OS Description     Not Available
OS Manufacturer    Microsoft Corporation
System Name   ...........-HP
System Manufacturer    Hewlett-Packard
System Model    HP ProBook 4530s
System Type    x64-based PC
Processor    Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz, 2501 Mhz, 2 Core(s), 4 Logical Processor(s)
BIOS Version/Date    Hewlett-Packard 68SRR Ver. F.23, 09/03/2012
SMBIOS Version    2.6
Windows Directory    C:\windows
System Directory    C:\windows\system32
Boot Device    \Device\HarddiskVolume1
Locale    United Kingdom
Hardware Abstraction Layer    Version = "6.1.7601.17514"
User Name    ...........-HP\................
Time Zone    South Africa Standard Time
Installed Physical Memory (RAM)    4.00 GB
Total Physical Memory    3.94 GB
Available Physical Memory    1.00 GB
Total Virtual Memory    7.87 GB
Available Virtual Memory    1.25 GB
Page File Space    3.94 GB
Page File    C:\pagefile.sys

To clarify further.... It is important to note that Forms/Repors 11.1.2.x software (including WLS and JDK) must be of the same archetecture as the machine. In other words, you cannot use the 32bit Forms/Reports 11.1.2 software on 64bit Windows. If you are using a 64bit OS, you must install the 64bit software. Again, this would include Forms/Reports, WLS, and JDK

Heap dumps on 32bit and 64 bit JVM

We are experiencing memory leak issues with one of our application deployed on JBOSS (SUN JVM 1.5, Win 32 OS). The application is already memory intensive and consumes the maximum heap (1.5 GB) allowed on a 32-bit JVM on Win32.
This leaves very few memory for heap dump and the JVM crashes whenever we try adding the heap dump flag (-agentlib:), with a "malloc error"..
Has anyone faced a scenario like this?
Alternatively for investigation purpose, we are trying to deploy it on a Windows X64 - but the vendor advises only to run on 32 bit JVM. Here is my question:
1) Can we run 32bit JVM on Windows 64? Even if we run, can i allocate more than 2 GB for heap memory?
2) I dont see the rational why we cannot run on 64bit JVM - because, JAVA programs are supposed to be 'platform-independent' and the application in form of byte code should be running no matter if it is a 32bit or 64-bit JVM?
3) Do we have any other better tools (except HPROF heapdumps) to analyze memory leaks - we tried using profiling tools but they too fail becos of very few memory available.
Any help is really appreciated! :-)
Anush
This topic has no replies.

Originally Posted by gleach1
I've done this a few time with ZCM 11.2
take special note that for each action in a bundle you can set a requirement - this is where you shold be specifying the appropriate architecture for the action, takes a bit longer to do but saves on the number of bundles and clogging up event logs with junk
modifying your existing actions in your bundles would probably be easier and make things cleaner to manage in the long term, this is more so the case when you have software that might only differ in the launch action depending on what program files folder it ends up in
Sorry to dig this late topic, but I've created a bundle which have an action that needs to be executed on 32 / 64 bits, each by an specific executable. Said,
(32 bits) ipxfer -s officescan.server -m 1 -p 8080 -c 63016
(64 bits) ipxfer_x64 -s officescan.server -m 1 -p 8080 -c 63016
So I added these two actions, marked each to have the correct arch ("Architecture / = / 32" or "Architecture / = / 64"), no fail on pre-requisite.
But now, every time one 32 bit machine executes the bundle, it gets an error:
Error starting "ipXfer_x64 -s officescan.server -m 1 -p 8080 -c 63016". Windows Error: This version of %1 is not compatible with the windows version in use. Please verify in your computer's system information if you need a x86 (32 bit) or x64 (64 bit) version of the program and contact software vendor
All the machines' CPU are 64 bits, but some of them have 32-bit Windows 7. These are the ones that are raising these errors.
I have other bundles restricted to 32/64 architectures, working correctly, but the restriction was created on the bundle level, not on the action level.
Sorry for the bad english.

Solaris 10 64 bit and 64 bit JVM support for Weblogic Server 9.1

Does the following configuration supported:
Weblogic Server 9.1
Sun Solaris 10 (64 bit)
Sun JVM 5.0 (64 bit)
I could only find reference to 32 bit JVM on bea site.
Any help is appreciated.
Thanks

Hi.
answers inline:
sanjay wrote:
Hi,
Can Weblogic Express (Cluster edition)6.1J sp2 be installed on Sun Solaris(Sparc)
8(64 bit) ?Yes - http://edocs.bea.com/wls/platforms/index.html#solaris8
>
>
Can Weblogic Express (Cluster edition)6.1J sp2 JDBC driver be used for Oracle 8.1.7(Solaris
64 bit) ?
Yes - http://edocs.bea.com/wls/platforms/index.html#jdbc
Michael Young
Developer Relations Engineer
BEA Support

64 Bit jvm issue?

First and foremost: my hardware and software specifications -
OS:
Microsoft Windows XP Pro Edition x64
Version 2003 SP2
JRE:
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
Graphics Card:
The Quadro FX 5800 Graphics Card
I have an GUI application that uses a JPanel to draw rectangles (g.fillrect(...)) as data continuously comes in. If I use JRE 1.4 32 bit JVM the application runs as expected. If I use JRE 64-Bit Server JVM, the rectangles grow and shrink randomly in the vertical direction. which is unexpected behavior and incorrect.
Does anyone know if there's an issue with the 64 bit JVM? As mentioned above, the application runs fine using a 32 bit 1.4 JRE?
I have also tried compiling the application using the 64 bit JDK, but it did not help.
Any ideas?
TIA,
DB

Which thread should hold the active discussion? This one or the one in the Swing forum ( [Swing thread|http://forums.sun.com/thread.jspa?threadID=5423460&messageID=10904216#10904216] )?

Could not start/run 64-bit JVM on solaris

Hi,
Basically I wanted to increase the heap size of java on solaris to 4GB .
some where I read ,2GB is the max limit for 32-bit JVM,
Hence I used 64-bit setting to start JVM,
I added "-d64" option.
after this ,when I tried to start weblogic (which calls java) ,it failed to start . giving below error
execv(): No such file or directory
Error trying to exec /data/mss/bea/jdk142_04/jre/bin/sparcv9/java.
Check if file exists and permissions are set correctly.
Failed to start a 64-bit JVM process from a 32 bit JVM.
Verify all necessary J2SE components have been installed.
(Solaris SPARC 64-bit components must be installed after 32-bit components.)
Environment details are :
os.arch = sparc
os.name = SunOS
os.version = 5.9
java.version = 1.4.2_04
java.vm.info = mixed mode
java.vm.name = Java HotSpot(TM) Server VM
Can any one help me on this issue.
setting heap size of java on solaris to 4GB ??
Thanks

Well...
Check if file exists and permissions are setcorrectly.
Verify all necessary J2SE components have beeninstalled.
Did you do that?I am logged using su
I think i must be having all permissions .
Is there any way to verify "J2SE components have been installed"
please refer below url for this kind the bug in sun website.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6181254
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6181254

64-bit JVM on solaris 8/9

Has anyone run the 64-bit JVM (-d64) on Solaris 8 or 9?
1.4.1
http://java.sun.com/products/archive/j2se/1.4.1_05/index.html
1.4.2
http://java.sun.com/j2se/1.4.2/install-solaris-64.html
Support tells me BEA has not certified WLS for use with the 64-bit JVM. However,
according to the following link the -server option is implicit to using the 64-bit
JVM:
http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/java.html
======================
-d32
-d64
Specifies whether the program is to be run in a 32-bit or 64-bit environment.
On Solaris these correspond to the ILP32 and LP64 data models, respectively. The
-d64 option may only be used on 64-bit Solaris systems.
Currently only the Java HotSpot Server VM supports 64-bit operation, and the "-server"
option is implicit with the use of -d64. This is subject to change in a future
release.
If neither -d32 nor -d64 is specified, the default is to run in a 32-bit environment.
This is subject to change in a future release.
======================
If BEA does not officially support the 64-bit JVM on either 1.4.1 or 1.4.2, then
why do the default startup scripts coming with WLS 8.1 sp2 (startWebLogic.sh,
comm_Env.sh) allow for the use of the -server option, which, according to Sun's
docs, means you are using the 64-bit JVM?
If anyone has used the 64-bit JVM, what kind of performance gain, if any, are
they seeing?
Thanks for any help.

My dear friend,
You understood java docs incorrectly. That say that if you specify -d64, -server
is implicit, not the other way.
Regards
"achen" <[email protected]> wrote:
>
Has anyone run the 64-bit JVM (-d64) on Solaris 8 or 9?
1.4.1
http://java.sun.com/products/archive/j2se/1.4.1_05/index.html
1.4.2
http://java.sun.com/j2se/1.4.2/install-solaris-64.html
Support tells me BEA has not certified WLS for use with the 64-bit JVM.
However,
according to the following link the -server option is implicit to using
the 64-bit
JVM:
http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/java.html
======================
-d32
-d64
Specifies whether the program is to be run in a 32-bit or 64-bit environment.
On Solaris these correspond to the ILP32 and LP64 data models, respectively.
The
-d64 option may only be used on 64-bit Solaris systems.
Currently only the Java HotSpot Server VM supports 64-bit operation,
and the "-server"
option is implicit with the use of -d64. This is subject to change in
a future
release.
If neither -d32 nor -d64 is specified, the default is to run in a 32-bit
environment.
This is subject to change in a future release.
======================
If BEA does not officially support the 64-bit JVM on either 1.4.1 or
1.4.2, then
why do the default startup scripts coming with WLS 8.1 sp2 (startWebLogic.sh,
comm_Env.sh) allow for the use of the -server option, which, according
to Sun's
docs, means you are using the 64-bit JVM?
If anyone has used the 64-bit JVM, what kind of performance gain, if
any, are
they seeing?
Thanks for any help.

32-bit vs 64-bit JVM, JDK, DLL's

I've got a project that has a couple dependencies:
1. My project interacts with an FTDI USB->Serial converter based device. Access to this device is via DLL(FTDI calls them D2XX drivers). FTDI offers both 32-bit and 64-bit drivers. Please see here .
2. In order to get access to the DLL via Java, I'm using a JNI called [jd2xx|http://bleyer.org/jd2xx/] . I don't know if or how a JNI would change if the DLL used is 32-bit or 64-bit.
My build & run environment was XP/32. Now I want to build/run on Vista64. But I'm confused because there are multiple options for downloading and installing the different parts which make up the system:
1. Netbeans is available for 32-bit and 64-bit. Which JVM should I point Netbeans to?
2. JVM comes in 32-bit or 64-bit.
3. JDK comes in 32-bit or 64-bit.
While I don't think anyone else actually uses my project, I'd like to have both XP/32 support and Vista/64 support. If I must go one way or the other, it's gotta be Vista/64.
I have tried multiple combinations, but I get a variety of errors depending on what's installed. The errors are all related to 32-bit/64-bit conflicts.
Can someone point me down the right path?
Thanks
Keith

I searched fairly thoroughly through the NetBeans GUI to see if I could target a particular platform, like 32-bit vs 64-bit ---- and I didn't find one. While it may not matter for java itself, when java interacts with a native dll, there are obviously implications.Java class files are os-agnostic - there isn't a "32-bit version" or a "64-bit version", they're both the same. What is different is the JVM that you run a class file on. A 32-bit JVM requires the appropriate 32-bit libraries, etc; the same requirement exists for a 64-bit JVM. I don't know if you can tell an IDE to run using one JVM or the other (obviously this would be possible only with 64-bit arch). I do know that the java tool for Linux/Solaris allows the use of a -d32 or -d64 option to specify that, and that the options aren't valid for the Windows java tool. I also know that Eclipse has native dependencies due to SWT, so that probably causes some restrictions. And. as you note, doing somethisng like JNI has "implications".
If you have further questions re NB, you should raise then at a NB site, not here.

Flash CS 5.5 Professional requires 32-bit JVM when publishing for iOS

When trying to publish my file to AIR for iOS I get the following error:
Error: This Java instance does not support a 32-bit JVM.Please install the desired version.
I'm on Mac OS (Mavericks) and have both java 6 (which supports 32-bit) and 7 (which does not) installed. I've verified I can launch a 32-bit jvm from the terminal with "java -d32".
Interestingly, it publishes to AIR with no problems when it's not to iOS.
How can I get Flash to use the correct version of Java? I've tried setting JAVA_HOME to point to version 6 in /etc/profile with still no luck.
Thanks for reading, I will really appreciate the help!!

Ok, found the answer thanks to Christopher Caleb. Needed to upgraded CS5.5's bundled AIR from 2.6 to the current one, and it compiled with no errors. Directions are here for anyone that winds up having the same issue:
http://www.yeahbutisitflash.com/?p=2949

64 bit JVM on Standard Edition of 8.0.1

http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403277&sliceId=1#_Toc193176416
http://www.adobe.com/products/coldfusion/pdfs/cf8_systemsupportmatrix.pdf
You have to have CF Enterprise before you can use a 64 BIT
JVM. I am very disappointed that the bean counters at Adobe made
this choice. I have 4 standard edition CF servers Iand all are on
64 bit hardware since our company buys nothing but 64 bit hardware
for consistency. I cannot convince anyone to pay the HUGE cost
difference for CF Enterprise. Yes, I know I am just complaining
here.

My dear friend,
You understood java docs incorrectly. That say that if you specify -d64, -server
is implicit, not the other way.
Regards
"achen" <[email protected]> wrote:
>
Has anyone run the 64-bit JVM (-d64) on Solaris 8 or 9?
1.4.1
http://java.sun.com/products/archive/j2se/1.4.1_05/index.html
1.4.2
http://java.sun.com/j2se/1.4.2/install-solaris-64.html
Support tells me BEA has not certified WLS for use with the 64-bit JVM.
However,
according to the following link the -server option is implicit to using
the 64-bit
JVM:
http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/java.html
======================
-d32
-d64
Specifies whether the program is to be run in a 32-bit or 64-bit environment.
On Solaris these correspond to the ILP32 and LP64 data models, respectively.
The
-d64 option may only be used on 64-bit Solaris systems.
Currently only the Java HotSpot Server VM supports 64-bit operation,
and the "-server"
option is implicit with the use of -d64. This is subject to change in
a future
release.
If neither -d32 nor -d64 is specified, the default is to run in a 32-bit
environment.
This is subject to change in a future release.
======================
If BEA does not officially support the 64-bit JVM on either 1.4.1 or
1.4.2, then
why do the default startup scripts coming with WLS 8.1 sp2 (startWebLogic.sh,
comm_Env.sh) allow for the use of the -server option, which, according
to Sun's
docs, means you are using the 64-bit JVM?
If anyone has used the 64-bit JVM, what kind of performance gain, if
any, are
they seeing?
Thanks for any help.

64 bit JVM Crash when loading shared library

I wrote a simple code to test loading of 64 bit shared library in linux. My JVM crashes on System.loadLibrary method.
JAVA CODE
import java.awt.Dimension;
import javax.swing.JFrame;
public class TestJNI extends JFrame{
        public native void init();
        static{
                System.loadLibrary("testJNI");
        public static void main(String ...args){
                TestJNI test = new TestJNI();
                test.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
                test.setSize(new Dimension(500,500));
                test.setVisible(true);
                System.out.println("Before init");
                //test.init();
                System.out.println("After init");
} Header file created using javah
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class TestJNI */
#ifndef _Included_TestJNI
#define _Included_TestJNI
#ifdef __cplusplus
extern "C" {
#endif
#undef TestJNI_FOCUS_TRAVERSABLE_UNKNOWN
#define TestJNI_FOCUS_TRAVERSABLE_UNKNOWN 0L
#undef TestJNI_FOCUS_TRAVERSABLE_DEFAULT
#define TestJNI_FOCUS_TRAVERSABLE_DEFAULT 1L
#undef TestJNI_FOCUS_TRAVERSABLE_SET
#define TestJNI_FOCUS_TRAVERSABLE_SET 2L
#undef TestJNI_TOP_ALIGNMENT
#define TestJNI_TOP_ALIGNMENT 0.0f
#undef TestJNI_CENTER_ALIGNMENT
#define TestJNI_CENTER_ALIGNMENT 0.5f
#undef TestJNI_BOTTOM_ALIGNMENT
#define TestJNI_BOTTOM_ALIGNMENT 1.0f
#undef TestJNI_LEFT_ALIGNMENT
#define TestJNI_LEFT_ALIGNMENT 0.0f
#undef TestJNI_RIGHT_ALIGNMENT
#define TestJNI_RIGHT_ALIGNMENT 1.0f
#undef TestJNI_serialVersionUID
#define TestJNI_serialVersionUID -7644114512714619750LL
#undef TestJNI_serialVersionUID
#define TestJNI_serialVersionUID 4613797578919906343LL
#undef TestJNI_INCLUDE_SELF
#define TestJNI_INCLUDE_SELF 1L
#undef TestJNI_SEARCH_HEAVYWEIGHTS
#define TestJNI_SEARCH_HEAVYWEIGHTS 1L
#undef TestJNI_OPENED
#define TestJNI_OPENED 1L
#undef TestJNI_serialVersionUID
#define TestJNI_serialVersionUID 4497834738069338734LL
#undef TestJNI_DEFAULT_CURSOR
#define TestJNI_DEFAULT_CURSOR 0L
#undef TestJNI_CROSSHAIR_CURSOR
#define TestJNI_CROSSHAIR_CURSOR 1L
#undef TestJNI_TEXT_CURSOR
#define TestJNI_TEXT_CURSOR 2L
#undef TestJNI_WAIT_CURSOR
#define TestJNI_WAIT_CURSOR 3L
#undef TestJNI_SW_RESIZE_CURSOR
#define TestJNI_SW_RESIZE_CURSOR 4L
#undef TestJNI_SE_RESIZE_CURSOR
#define TestJNI_SE_RESIZE_CURSOR 5L
#undef TestJNI_NW_RESIZE_CURSOR
#define TestJNI_NW_RESIZE_CURSOR 6L
#undef TestJNI_NE_RESIZE_CURSOR
#define TestJNI_NE_RESIZE_CURSOR 7L
#undef TestJNI_N_RESIZE_CURSOR
#define TestJNI_N_RESIZE_CURSOR 8L
#undef TestJNI_S_RESIZE_CURSOR
#define TestJNI_S_RESIZE_CURSOR 9L
#undef TestJNI_W_RESIZE_CURSOR
#define TestJNI_W_RESIZE_CURSOR 10L
#undef TestJNI_E_RESIZE_CURSOR
#define TestJNI_E_RESIZE_CURSOR 11L
#undef TestJNI_HAND_CURSOR
#define TestJNI_HAND_CURSOR 12L
#undef TestJNI_MOVE_CURSOR
#define TestJNI_MOVE_CURSOR 13L
#undef TestJNI_NORMAL
#define TestJNI_NORMAL 0L
#undef TestJNI_ICONIFIED
#define TestJNI_ICONIFIED 1L
#undef TestJNI_MAXIMIZED_HORIZ
#define TestJNI_MAXIMIZED_HORIZ 2L
#undef TestJNI_MAXIMIZED_VERT
#define TestJNI_MAXIMIZED_VERT 4L
#undef TestJNI_MAXIMIZED_BOTH
#define TestJNI_MAXIMIZED_BOTH 6L
#undef TestJNI_serialVersionUID
#define TestJNI_serialVersionUID 2673458971256075116LL
#undef TestJNI_EXIT_ON_CLOSE
#define TestJNI_EXIT_ON_CLOSE 3L
* Class:     TestJNI
* Method:    init
* Signature: ()V
JNIEXPORT void JNICALL Java_TestJNI_init
(JNIEnv *, jobject);
#ifdef __cplusplus
#endif
#endifC code TestJNI.c
#include "TestJNI.h"
#include <stdio.h>
JNIEXPORT void JNICALL Java_TestJNI_init
(JNIEnv *env, jobject ob){
printf("TESTING JNI CALL");
}gcc options are as follows to get the shared library:
gcc -fPIC -pthread -g -Wall -D_REENTRANT -I/vobs/3p/jdk1.6.0_10/linux/include/linux -I/vobs/3p/jdk1.6.0_10/linux/include/ -c TestJNI.c -o TestJNI.o
gcc -z defs -pthread -D_REENTRANT -Wl,-soname,libnative.so -shared -o libtestJNI.so TestJNI.o -lcAny help is appreciated. I am not sure what i am doing wrong here.
Running the same code on a 32 bit jvm with a 32 bit shared library works.

Hi,
I was also having a problem under 64 bit, Now I am certain that if ur Java code makes a call to the DLL, make sure that DLL is compiled under 64 bit compiler and not 32 bit compiler. This is the mistake I made and the JVM was throwing unsatisfied link error. Now this DLL (compiled under 64 bit) could call a 32 bit dll, I dont think that should be a problem.
Hope it helps.
Subu

32-bit JVM receiving Java objects from 64-bit JVM

Hi folks,
Question is: will there be problems for 32-bit JVM receiving Java objects from 64-bit JVM? and vice versa.
Our application client is running on 32-bit JVM, our server is running on 64-bit JVM. Client will send Java objects to server, and vice versa.
My past experience suggested when sending Java objects between client and server, both client and server needs to be compiled under the same JVM version. Any advice?
Christy

My past experience suggested when sending Java
objects between client and server, both client and
server needs to be compiled under the same JVM
version. Any advice?This is only a case if you omit explicit serialVersionUID. My advice is to ALWAYS specify it for classes you want to serialize over the wire or put into persistent storage. It is way too tricky to rely on default one to fail half a year later when some new programmer adds one new public method to a class.
Unless you need to deserialize already existing resources, there is no need to put any magic number in serialVersionUID - just put 1 for every class you create and possibly increase it by 1 every time you want to make incompatible version (which is not happening so often, as in real world you often try to stay as compatible as possible)

Experiencing a 32-bit Java heap barrier on a 64-bit JVM

We are attempting to run a Java application on a Sun Fire V440 with Solaris 9 and 16GB RAM. We are using the 5.0 JRE.
We are starting the application with the -d64 and -server options, and 6g of heap space with the max/min settings the same.
We have queried the Runtime object to confirm that the heap is what we expect it to be, and have plotted our heap usage.
Our full data matrix requests about 3.4GB of memory at one point in the code. We are unable to analyse the full matrix and encounter an OutOfMemoryError on array allocation. What we notice is that when we scale down the matrix so that heap usage is just under the 32 bit barrier (4.3GB) it runs, but as soon as we cross it we error.
We have checked that we are using the 64-bit JVM via the sun.arch.data.model system property and the java.version property. The Runtime object also clearly shows that the free memory is available.
What we see is that before allocation we are using 1,3GB of heap.
Adding about 3.4GB, on array allocation, to this puts us over the 32-bit threshold and we error. Any input would be greatly appreciated.

Thank you for the replies. It has helped significantly! As was suggested, the problem seems to be a young and old generation heap problem. Unfortunately, it's too late to change the subject heading. The barrier was just an artifact of a number of coincidences.
We are closer to solving the issue, but we're not there yet. We tried an experiment with 8GB of heap split 50/50 for young and old using:
java -d64 -server -Xms8000m -Xmx8000m -Xmn4000m
resulting in settings of:
-XX:MaxHeapSize=8388608000
-XX:MaxNewSize=4194304000
-XX:NewSize=4194304000
-XX:+UseParallelGC
Then we manually GC'd before the array allocation just to make sure the young generation heap was cleared out. Prior to this most of the young generation cycling is due to a BufferedReader readline() command.
After System.gc(), we read in an matrix of 900K x 300 double values = 2.1GB of data. We still run out of heap space. Our manual GC is invocation #3 and clears out the young heap, and even promotes an insignificant amount of data to the old heap, but leaves both generations largely empty:
{Heap before gc invocations=1:
PSYoungGen      total 3584000K, used 3072000K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 100% used [0xfffffffe3d400000,0xfffffffef8c00000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
to   space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen        total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen       total 24576K, used 7593K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6a718,0xfffffffd3fc00000)
0.000: [GCAdaptiveSizePolicy::compute_survivor_space_size_and_thresh: survived: 1032296 promoted: 0 overflow: falseAdaptiveSizeStart: 0.016 collection: 1
AdaptiveSizePolicy::compute_generation_free_space: minor_time: 0.000157 major_cost: 0.000000 mutator_cost: 0.999843 throughput_goal: 0.990000 live_space: 277243776 free_space: 7340032000 old_promo_size: 4194304000 old_eden_size: 3145728000 desired_promo_size: 4194304000 desired_eden_size: 3145728000
AdaptiveSizeStop: collection: 1
[PSYoungGen: 3072000K->1008K(3584000K)] 3072000K->1008K(7680000K), 0.0162566 secs]
Heap after gc invocations=1:
PSYoungGen total 3584000K, used 1008K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8cfc068,0xffffffff18000000)
to space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
PSOldGen total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen total 24576K, used 7593K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6a718,0xfffffffd3fc00000)
{Heap before gc invocations=2:
PSYoungGen      total 3584000K, used 2952191K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 96% used [0xfffffffe3d400000,0xfffffffef1603f40,0xfffffffef8c00000)
from space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8cfc068,0xffffffff18000000)
to   space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
PSOldGen        total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen       total 24576K, used 7596K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6b3d8,0xfffffffd3fc00000)
88.203: [GCAdaptiveSizePolicy::compute_survivor_space_size_and_thresh: survived: 999520 promoted: 0 overflow: falseAdaptiveSizeStart: 88.212 collection: 2
AdaptiveSizeStop: collection: 2
[PSYoungGen: 2952191K->976K(3584000K)] 2952191K->976K(7680000K), 0.0096021 secs]
Heap after gc invocations=2:
PSYoungGen total 3584000K, used 976K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff180f4060,0xffffffff37400000)
to space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen total 24576K, used 7596K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6b3d8,0xfffffffd3fc00000)
{Heap before gc invocations=3:
PSYoungGen      total 3584000K, used 976K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff180f4060,0xffffffff37400000)
to   space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen        total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen       total 24576K, used 7596K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6b3d8,0xfffffffd3fc00000)
88.213: [Full GCAdaptiveSizeStart: 88.392 collection: 3
AdaptiveSizeStop: collection: 3
[PSYoungGen: 976K->0K(3584000K)] [PSOldGen: 0K->874K(4096000K)] 976K->874K(7680000K) [PSPermGen: 7596K->7596K(24576K)], 0.1788788 secs]
Heap after gc invocations=3:
PSYoungGen total 3584000K, used 0K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
to space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen total 4096000K, used 874K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd434da8c0,0xfffffffe3d400000)
PSPermGen total 24576K, used 7596K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6b3d8,0xfffffffd3fc00000)
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
So next we reduced our data to 890K x 300 double values = 2.14GB of data, not a lot less, and it allocates fine. In fact in GC #4 it has even promoted the signal matrix to the old generation:
{Heap before gc invocations=1:
PSYoungGen      total 3584000K, used 3072000K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 100% used [0xfffffffe3d400000,0xfffffffef8c00000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
to   space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen        total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen       total 24576K, used 7593K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6a768,0xfffffffd3fc00000)
0.000: [GCAdaptiveSizePolicy::compute_survivor_space_size_and_thresh: survived: 1048656 promoted: 0 overflow: falseAdaptiveSizeStart: 0.017 collection: 1
AdaptiveSizePolicy::compute_generation_free_space: minor_time: 0.000281 major_cost: 0.000000 mutator_cost: 0.999719 throughput_goal: 0.990000 live_space: 277260224 free_space: 7340032000 old_promo_size: 4194304000 old_eden_size: 3145728000 desired_promo_size: 4194304000 desired_eden_size: 3145728000
AdaptiveSizeStop: collection: 1
[PSYoungGen: 3072000K->1024K(3584000K)] 3072000K->1024K(7680000K), 0.0170110 secs]
Heap after gc invocations=1:
PSYoungGen total 3584000K, used 1024K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8d00050,0xffffffff18000000)
to space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
PSOldGen total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen total 24576K, used 7593K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6a768,0xfffffffd3fc00000)
{Heap before gc invocations=2:
PSYoungGen      total 3584000K, used 2891377K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 94% used [0xfffffffe3d400000,0xfffffffeeda9c6d8,0xfffffffef8c00000)
from space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8d00050,0xffffffff18000000)
to   space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
PSOldGen        total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen       total 24576K, used 7593K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6a768,0xfffffffd3fc00000)
37.161: [GCAdaptiveSizePolicy::compute_survivor_space_size_and_thresh: survived: 1015880 promoted: 0 overflow: falseAdaptiveSizeStart: 37.171 collection: 2
AdaptiveSizeStop: collection: 2
[PSYoungGen: 2891377K->992K(3584000K)] 2891377K->992K(7680000K), 0.0098960 secs]
Heap after gc invocations=2:
PSYoungGen total 3584000K, used 992K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff180f8048,0xffffffff37400000)
to space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen total 24576K, used 7593K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6a768,0xfffffffd3fc00000)
{Heap before gc invocations=3:
PSYoungGen      total 3584000K, used 992K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff180f8048,0xffffffff37400000)
to   space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen        total 4096000K, used 0K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd43400000,0xfffffffe3d400000)
PSPermGen       total 24576K, used 7593K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6a768,0xfffffffd3fc00000)
37.172: [Full GCAdaptiveSizeStart: 37.352 collection: 3
AdaptiveSizeStop: collection: 3
[PSYoungGen: 992K->0K(3584000K)] [PSOldGen: 0K->874K(4096000K)] 992K->874K(7680000K) [PSPermGen: 7593K->7593K(24576K)], 0.1802284 secs]
Heap after gc invocations=3:
PSYoungGen total 3584000K, used 0K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
to space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen total 4096000K, used 874K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd434da8c0,0xfffffffe3d400000)
PSPermGen total 24576K, used 7593K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6a768,0xfffffffd3fc00000)
{Heap before gc invocations=4:
PSYoungGen      total 3584000K, used 3072000K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 100% used [0xfffffffe3d400000,0xfffffffef8c00000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
to   space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen        total 4096000K, used 874K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 0% used [0xfffffffd43400000,0xfffffffd434da8c0,0xfffffffe3d400000)
PSPermGen       total 24576K, used 7611K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6eeb0,0xfffffffd3fc00000)
54.054: [GC-- [PSYoungGen: 3072000K->3072000K(3584000K)] 3072874K->5158809K(7680000K), 23.1725940 secs]
Heap after gc invocations=4:
PSYoungGen total 3584000K, used 3072000K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 100% used [0xfffffffe3d400000,0xfffffffef8c00000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
to space 512000K, 1% used [0xfffffffef8c00000,0xfffffffef947a490,0xffffffff18000000)
PSOldGen total 4096000K, used 2086809K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 50% used [0xfffffffd43400000,0xfffffffdc29e6578,0xfffffffe3d400000)
PSPermGen total 24576K, used 7611K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6eeb0,0xfffffffd3fc00000)
{Heap before gc invocations=5:
PSYoungGen      total 3584000K, used 3072000K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 100% used [0xfffffffe3d400000,0xfffffffef8c00000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
to   space 512000K, 1% used [0xfffffffef8c00000,0xfffffffef947a490,0xffffffff18000000)
PSOldGen        total 4096000K, used 2086809K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 50% used [0xfffffffd43400000,0xfffffffdc29e6578,0xfffffffe3d400000)
PSPermGen       total 24576K, used 7611K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6eeb0,0xfffffffd3fc00000)
77.227: [Full GCAdaptiveSizeStart: 81.903 collection: 5
AdaptiveSizePolicy::compute_generation_free_space limits: desired_promo_size: 5310531271 promo_limit: 4194304000 free_in_old_gen: 2048607488 max_old_gen_size: 4194304000 avg_old_live: 4746786511456829440
AdaptiveSizePolicy::compute_generation_free_space limits: desired_eden_size: 5454285546 old_eden_size: 3145728000 eden_limit: 3145728000 cur_eden: 3145728000 max_eden_size: 3145728000 avg_young_live: 524328
AdaptiveSizePolicy::compute_generation_free_space: minor_time: 0.289393 major_cost: 0.104945 mutator_cost: 0.605662 throughput_goal: 0.990000 live_space: 2422441472 free_space: 7340032000 old_promo_size: 4194304000 old_eden_size: 3145728000 desired_promo_size: 4194304000 desired_eden_size: 3145728000
AdaptiveSizeStop: collection: 5
[PSYoungGen: 3072000K->0K(3584000K)] [PSOldGen: 2086809K->2095406K(4096000K)] 5158809K->2095406K(7680000K) [PSPermGen: 7611K->7611K(24576K)], 4.6758162 secs]
Heap after gc invocations=5:
PSYoungGen total 3584000K, used 0K [0xfffffffe3d400000, 0xffffffff37400000, 0xffffffff37400000)
eden space 3072000K, 0% used [0xfffffffe3d400000,0xfffffffe3d400000,0xfffffffef8c00000)
from space 512000K, 0% used [0xffffffff18000000,0xffffffff18000000,0xffffffff37400000)
to space 512000K, 0% used [0xfffffffef8c00000,0xfffffffef8c00000,0xffffffff18000000)
PSOldGen total 4096000K, used 2095406K [0xfffffffd43400000, 0xfffffffe3d400000, 0xfffffffe3d400000)
object space 4096000K, 51% used [0xfffffffd43400000,0xfffffffdc324bad0,0xfffffffe3d400000)
PSPermGen total 24576K, used 7611K [0xfffffffd3e400000, 0xfffffffd3fc00000, 0xfffffffd43400000)
object space 24576K, 30% used [0xfffffffd3e400000,0xfffffffd3eb6eeb0,0xfffffffd3fc00000)
Apologies for the long trace information, but it's not clear yet what is going on. We even tried to add:
-XX:PretenureSizeThreshold=1000m
to try to force the signal matrix into old generation first upon allocation. This is where it should be, and would save the heap from having to promote it later. So question is: Is there something we're missing w.r.t. eden/from/to space ? Clearly, there is!
Thanks again!

Loading a 32-bit native library on a 64-bit JVM environment

Hello
I have a 3rd party 32-bit native library (abc.so). I am creating a JVM from my 64-bit C code (myC.c). Within this JVM i try to load the 32-bit abc.so
I get the following run-time error
Exception in thread "main" java.lang.UnsatisfiedLinkError: abc.so: ld.so.1: myC: fatal: abc.so: wrong ELF class: ELFCLASS32
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1480)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1404)
at java.lang.Runtime.loadLibrary0(Runtime.java:772)
at java.lang.System.loadLibrary(System.java:832)
When I try to load the same abc.so using a wrapper Java code(instead of myC.c) by running it with java -d32, it works ok.
Do we have any option that we can set while creating a JVM from C, with which we can allow it to load 32-bit native libraries?
Moreover do we have a list of all the options that can be set in the JavaVMInitArgs?
I am using Java 1.4, as 1.3 doesn't support 64-bit JVM.
regards
Rahul

Hi,
I was also having a problem under 64 bit, Now I am certain that if ur Java code makes a call to the DLL, make sure that DLL is compiled under 64 bit compiler and not 32 bit compiler. This is the mistake I made and the JVM was throwing unsatisfied link error. Now this DLL (compiled under 64 bit) could call a 32 bit dll, I dont think that should be a problem.
Hope it helps.
Subu

WLS 32-bit installer on a 64-bit JVM

Hi All,
I was also told that I could run the WLS 10.3.1 (32 bit) installer wls1031_solaris32.bin along with a 64-bit JVM and WebLogic will run in 64-bit mode. Is that true?
If yes then what is the need for a 64 bit installer?
My underlying OS is solaris 64 bit.
I wonder how is that possible. Can anyone help me understand?
Thanks in advance.

It doesn't make sense to me that a 32-bit installer is installing a 64-bit JVM unless that installer will install both 32-bit and 64-bit JVMs.
I would suggest you use the installer from the edelivery site: WebLogic Server 9.2 MP3 Sun Solaris SPARC (64-bit) V15433-01 598M.
Regards,
John A. Booth
http://www.metavero.com

Mixing coherence on 64-bit and 32 bit jvms

Similar Messages

Maybe you are looking for