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.

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

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] )?

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

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

Launching a 64 bit jvm from a 32 bit jvm

I want to launch a 64 bit jvm from a 32 bit jvm. The current application works like this
1) The parent jvm A allows users to launch a child jvm B. Child jvm B inherits A's libraries (LD_LIBRARY_PATH) and also A's classpath entries.
2) User can specify his/her own libraries that are to be passed to B (child jvm). These entries are prepended to the inherited entries (A.LD_LIBRARY_PATH).
3) User can specify his/her own classpath entries that are to be added to B. These entries are appended to the inherited entries (A.classapth).
The whole idea behind making the child jvm configurable is that the user can specify a suitable jvm for the child. But optionally the user might specify a different java home (pointing to a 64bit jre/jdk).
Questions :
1) Would simply changing the java for the child suffice? That is instead of
java -classpath=<inherited-entries:specified-entries> abc
we do
-user-specified-java -classpath=<inherited-entries:specified-entries> abc
I have seen that the jvm uses the java.home from the java provided while launching the jvm. Example
$java -version
1.5
$java abc
// will use default java's home as java home internally
$/usr/lib/java-64/jdk/bin/java -version
1.5 64bit
$/usr/lib/java-64/jdk/binjava abc
// will use /usr/lib/java-64/jdk as java home internally
2) How will the classpath entries and libraries interact/interfere with the newly spawned jvm?
Here if the user specifies new libraries for 64 bit jvm, how will they interact/interfere with the 32bit libs.
3) What about native(esp jni) libraries?
Bigger picture :
If A is running sun java jdk1.5_a (32bit) and user can specify B as
1) sun jdk 1.x_y (32bit) such that x_y != 5_a
2) sun jdk 64 bit
3) any other 32 bit java implementation (ibm, jrocket ...)
4) any other 64 bit java implementation (ibm, jrocket ...)

jschell wrote:
Questions :
1) Would simply changing the java for the child suffice? That is instead of
java -classpath=<inherited-entries:specified-entries> abc
we do
-user-specified-java -classpath=<inherited-entries:specified-entries> abc
You cannot do it without creating a new process.
ProcessBuilder/Runtime.exec() create a new process. The new process can do anything.
You can set the environment using either.
Yes. The process B will be spawned either using ProcessBuilder or using Runtime. The question still remains,
Q: If I have a classpath defined already for a particular java implementation and the LD_LIBRARY path is all set, what will be effect of changing the default java.
Example :
If my classpath and LD_LIBRARY_PATH is set to use/work-with /usr/lib/javaA/ then
"/usr/lib/javaA/jre/bin/java -classpath $classpath abc" will work smoothly
But what will happen if I do classpath=$classpath:$new-javaB-classpath-entries and LD_LIBRARY_PATH=$LD_LIBRARY_PATH_FOR_B:$LD_LIBRARY_PATH and
"/usr/lib/javaB/jre/bin/java -classpath $classpath abc"
>
2) How will the classpath entries and libraries interact/interfere with the newly spawned jvm?
Here if the user specifies new libraries for 64 bit jvm, how will they interact/interfere with the 32bit libs.
3) What about native(esp jni) libraries?
New process = new environment.
If there is a problem it is because of how you set it up or how they are used in the first place.I am more interested in the if. My question is can it happen and if yes whats the explanation and how to solve it.
>
As an example if an app needs a 64 bit library and there is only a 32 bit library then what happens depends entirely on the app that needs the 64 bit library. That question would be the same if you attempted to run the application from a console window.So here is another way of looking at it. Imagine you want to kick off a 64 bit java app from your console. Assume that you can only prepend to classpath. Also you can append to LD path. Now you have provided all that is needed for the app to run. But under the classpath constraints, what will be the behaviour?

Problem in invoking 32 bit JVM by using -d32 option

Hi all,
I am facing the following error message on solaris 10, when i use -d32 option in java command.
execv(): No such file or directory
Error trying to exec /usr/j2se/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.)
I am not able to figure out why this error is coming.
cheers,
ngs

Hi Sush,
I tried executing by giving full path of java. It gave same error. I have one more question. I have compiled the code using 64 bit JVM. Can i run that class code by using -d32 option in java command ?
[ Thats exactly what i am doing. And it is giving the same error. ]
bash-3.00$ /omcsw/29.0.1.3.00/lib/3pt/jdk/jre/bin/java -d32 test
execve(): No such file or directory
Error trying to exec /omcsw/29.0.1.3.00/lib/3pt/jdk/jre/bin/../java.
Check if file exists and permissions are set correctly.
Failed to start a 32-bit JVM process from a 64-bit JVM.
Verify all necessary J2SE components have been installed.
(Solaris SPARC 64-bit components must be installed after 32-bit components.)
regards,
ngs

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

Build using 32-bit Sun JDK in dev windows OS and deploy in 32-bit RHEL

Is there any potential problems associated with building/compiling my Java classes for my EE (Seam) app into an EAR and deploying on 32-bit Windows OS JBoss AS dev box using 32-bit Windows JDK 1.5 and then deploying the same EAR into 32-bit RHEL OS JBoss AS? The dev envmt is not clustered and the UAT RHEL envmt is a 2 node horizontal cluster without state replication (only mod_jk load balancing and failover).
Perhaps the entity (and other) classes that implement java.io.Serializable will have issues? thx.

Note: This thread was originally posted in the Serialization forum, but moved to this forum for closer topic alignment.

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.

Running a 64-bit JVM is not supported on this platform.error on DAC install

Hi Friends,
I am getting the error while installating DAC server on RHEL5.4(64 bit)
Running a 64-bit JVM is not supported on this platform.
What is the fix?
Regards,
DB

I have tried that but run into issues too... are you installing DAC directly on Linux 64 from installer or copying over from Windows binaries of DAC?

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 on jdk 1.4.2_10 with tomcat 5 - out of memory Xms500M Xmx1000

Hello,
I recently toke over an existing project. The production server is an Itanium 64 bit. Jdk 1.4.2_10 is installed, tomcat 5 is used as app server. The problem is that after a few days the tomcat proces runs out of memory after being hardly used. Because it takes some days to happen I rather ask here if somebody knows about problems with this configuration.
I suspect that using java5 could help out. I started up tomcat with plenty memory (500 / 1000). About 9 webapps are installed on the tomcat server. Any sugesstions are highly appreciated.
regards,
Dennis

Hi,
You can get the HeapDump Analyzer for analyzing IBM AIX heapdumps from the below mentioned link.
http://www.alphaworks.ibm.com/tech/heapanalyzer
http://www-1.ibm.com/support/docview.wss?uid=swg21190608
Prerequistes for obtaining a heapdump:
1.You have to add -XX:+HeapDumpOnOutOfMemoryError to the java options of the server (see note 710146,1053604) to get a heap dump on its occurance, automatically.
2.You can also generate heapdumps on request :
Add -XX:+HeapDumpOnCtrlBreak to the java options of the server
(see note 710146).
Send signal SIGQUIT to the jlaunch process representing the
server e.g. using kill -3 <jlaunch pid> (see note 710154).
The heap dump will be written to output file java_pid<pid>.hprof.<millitime> in:
/usr/sap/<SID>/<instance>/j2ee/cluster/server<N> directory.
Both these parameters can be set together too to get the benefit of both the approaches.
Regards,
Sandeep.
Edited by: Sandeep Sehgal on Mar 25, 2008 6:51 PM

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)

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

Similar Messages

Maybe you are looking for