32 bit JVM running on 64 bit OS

Hi,
I would like to know how much memory can use a java process if the JVM is 32 bit and the SO is 64 bit, for example on windows a 32 bit process can use as max 2GB so java heap+native memory+thread stuck=2GB, but what happend if a JVM of 32 bit is running on a 64 bit OS, how much memory can use a java process?java heap+native memory+thread stuck=? any help will be appreciate,
regards

Peter Lawrey wrote:
On a 32-bit Windows, the JVM can use atleast 1.2 GB, On a 64 bit Windows, you may get closer to 2 GB. Really?
The reason for the limit (Sun VM) is the way that it is built, it uses a base address that tells the OS to run it from a certain place and because of that and the contigous requirement it can't get anymore memory (actually about 1.6 gigs.)
So for it to work differently on 64 bits it would seems likely that the OS would need to run it from a different location.

Similar Messages

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?

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 iTunes running in 32 bit mode?

I installed the 64bit version of iTunes ont he 64bit Windows 7 Beta. It works fine, but taskmaster tells me that itunes.exe is a 32 bit program. Is the 64 bit iTunes just an installer or is it supposed to actually run in 64 bits?

My understanding is that the iTunes executable is still 32-bit.

32 bit Host running on 64 bit machine

Hi All,
I am running biztalk on 64 bit computer. I know we can configure 32 bit host on 64 bit computer.
My question is will there be any negative impact or performance hit? Can this configuration create any issue in future?
Thanks

First the impact on usage point of view,
running
FTP adapter, POP3 adapter, and MIME Decoder on 64-bit host instances is not supported. So you got to have 32-bit host instance configured for these adapters.
You don’t have option, so no performance comparisons if you want to use host instances on these adapters.
FYI, SQL adapter in BizTalk 2013 and R2 does support 64-bit. This was the case until BizTalk 2009. Things have changed from BizTalk 2010 onwards (I think change happened in BTS
2010, I am sure SQL adapter is supported in 64 in BizTalk 2013/R2). Reference:
http://technet.microsoft.com/en-us/library/aa560166.aspx
For all other adapters and processes:
Since you’re checking the performance impact of 32-bit host instances in 64-bit product, it’s better to understand the background and its impact in BizTalk process.
On Windows x64, 32-bit host instance under WOW64 and may utilize the full 4GB of virtual memory i.e 4 GB can be addressable ((2^32) in BizTalk
application which is "large address aware" app. On this 4 GB, 2GB are allocated for applications handles (user mode), and 2GB for the Kernel handles –OS. However, 32-bit applications may not be able to
create as many threads under WOW64 as they can when running natively on x86-based systems because WOW64 allocates an additional 64-bit stack (usually 512 KB) for each thread. In addition, some amount of address space is reserved for WOW64 itself and the data
structures it uses. The amount reserved depends on the processor; more is reserved on the Intel Itanium than on the x64 processor. There is an impact when you compare 32 bit process in 64-bit.
Having said this, the 4GB of virtual memory allocation is just for one host instance, But with host instance design you can have more than one host instance and allocate
BizTalk process to different host instances based on expected load. So any performance impact due to the fact “32-bit host in 64-bit” is low and manageable with correct host instance allocation design.
Reference:
Performance and Memory Consumption Under 32-bit in WOW64.
If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

Switching back from 64 bit jvm process to 32 bit process

I have my customer, go-live on WLS 9.2 MP2 on Sun Solaris 10 on 64 -bit. We have faced several crashes related to different reasons. I had applied 3X4R patch from Weblogic as well. Now, because they are on production and server crash is unacceptable, I need to rollback to 32 bit version that is more stable. So, can anyone point me to documentation that states the steps to rolling back to 32 bit process from 64 bit. The concern here is to ensure that rolling back along with 64 bit patches from weblogic shouldn't create any new issue.
Please let me know.
Thanks.

First of all I am kind of surprised you've got a
speed gain of 20% using the 64 bit mode. I thought in
general there was not much speed gain and sometimes
even a loss of performance. My own reason for using
64bit mode is to be able to address more than 4gb of
memory.
Saying that, it seems you have the choice of either
run in 64bit mode and connect somehow (RMI???) to a
32bit JVM that will run your 32bit native libraries.
This seems to be a bit of a fragile and dingy
solution to me, which probably quickly loses any
speedgains you get from running in 64bit mode.
Or you just go for the 32bit mode all over, and hope
that some day in future your 3rd part libraries
become available in 64 bit mode.
Honestly, unless you're going to address lots of
memory, I think this last solution is the most viable
option.Good advice!

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

Can I get Snow Leopard to run in 64-bit mode? (Black MacBook - Early 2008)

I have a Black Macbook (macbook4,1) with the latest firmare and OSX 10.6.4
I've tried holding "6" and "4" on bootup, and I can't get SL into true 64-bit mode. (System Software Overview: 64-bit Kernel and Extensions: No)
If I look at the Extensions, most say "Yes" to 64-bit (Intel), however, the following are still 32-bit:
AppleIntelGMAX3100
AppleIntelGMAX3100FB
BSDKernel6.0
IOKit6.0
Libkern6.0
Mach6.0
System6.0
Does that basically mean that my video card is limiting my ability to run pure 64-bit? If so, does anyone know if this is something that is planned to be fixed in a future release?
Thanks!
Mark

Does that basically mean that my video card is limiting my ability to run pure 64-bit? If so, does anyone know if this is something that is planned to be fixed in a future release?
Yes. No. All 64-bit software runs in 64-bit. You simply cannot use the 64-bit kernel unless Apple provides a 64-bit video driver which may not even be possible for the GPU in your computer.
What makes you think you even have a need for the 64-bit kernel?

How to find out if running 64 bit jvm

Hi all,
I have an application which can be run using 64 bit JNI libraries, or 32 bit libraries depending on the command line parameters. I want to know if there is any way for me to find out if the JVM is running in 64 bit mode (the -d64 parameter was sent to it) or 32 bit mode. If I could find out the command line parameters sent to the JVM it would be as useful.
Thanks in advance for your help.

D'oh answered my own question about 5 mins after posting :) If anyone is interested there is, starting in jdk1.4, a property called sun.arch.data.model which will be "64" for a when -d64 is used as a command line argument. This property has 3 states, "64", "32" and "unknown" I don't know on what occasion "unknown" will be used

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?

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.

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

32 bit JVM running on 64 bit OS

Similar Messages

Maybe you are looking for