P5
Name: rmT116609 Date: 06/10/2004
A DESCRIPTION OF THE REQUEST :
Currently, it seems that the java.exe executable was not compiled with the /LARGEADDRESSAWARE flag on windows, so we cannot take advantage of the /3Gb boot.ini option. This option allows for 3 Gb of user address space rather than the default 2. It is very commonly used by applications such as Oracle. BEA's JRocket JVM will soon be supporting this as well.
JUSTIFICATION :
This enhancement is necessary because, currently, the 2 Gb of address space is severly limiting for running large server applications on Windows. This 2 Gb must house not only the java object heap but also the memory required for native components such as "thick" jdbc drivers. We are currently finding this limitation to be very problematic when trying to fully utilize the resources of a dual CPU windows server.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would like to see the java executable resepect the /3Gb option, allowing the memory available for the object heap and the native jdbc components to approach 3 Gb instead of the current limit of 2 Gb
ACTUAL -
The object heap must be kept small (1 Gb vs 1.5 Gb on linux and solaris, which limits our applications scalabiltiy) and the JVM may crash under load when there is not enough "non-heap" memory.
CUSTOMER SUBMITTED WORKAROUND :
Run multiple JVMs, which is not a good solution
(Incident Review ID: 276957)
======================================================================
###@###.### 10/14/04 14:09 GMT
A DESCRIPTION OF THE REQUEST :
Currently, it seems that the java.exe executable was not compiled with the /LARGEADDRESSAWARE flag on windows, so we cannot take advantage of the /3Gb boot.ini option. This option allows for 3 Gb of user address space rather than the default 2. It is very commonly used by applications such as Oracle. BEA's JRocket JVM will soon be supporting this as well.
JUSTIFICATION :
This enhancement is necessary because, currently, the 2 Gb of address space is severly limiting for running large server applications on Windows. This 2 Gb must house not only the java object heap but also the memory required for native components such as "thick" jdbc drivers. We are currently finding this limitation to be very problematic when trying to fully utilize the resources of a dual CPU windows server.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I would like to see the java executable resepect the /3Gb option, allowing the memory available for the object heap and the native jdbc components to approach 3 Gb instead of the current limit of 2 Gb
ACTUAL -
The object heap must be kept small (1 Gb vs 1.5 Gb on linux and solaris, which limits our applications scalabiltiy) and the JVM may crash under load when there is not enough "non-heap" memory.
CUSTOMER SUBMITTED WORKAROUND :
Run multiple JVMs, which is not a good solution
(Incident Review ID: 276957)
======================================================================
###@###.### 10/14/04 14:09 GMT
- duplicates
-
JDK-6743170 1.4.2_18 JVM crashing on Windows 2003 EE server running on a multi-core CMT chip w/ Hyper-Threading
-
- Closed
-
- relates to
-
JDK-8252803 Add the /LARGEADDRESSAWARE flag when linking executables for Windows 32-bit
-
- Closed
-