JDK-4774036 : Java 1.4.x and virtual memory limits
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2002-11-05
  • Updated: 2010-09-02
  • Resolved: 2010-09-02
Related Reports
Relates :  
JDK-4665470 - improve memory footprint of the J2SE platform
Relates :  
JDK-4607284 - improve memory footprint of the JVM
Relates :  
JDK-6940674 - Progressively step down default heap size reservation request until OS can satisfy it
Description
Name: gm110360			Date: 11/05/2002


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

generally all 1.4.x versions & Linux

FULL OPERATING SYSTEM VERSION :kernel 2.4.10,
glibc-2.2.4-77, SuSE 7.3


A DESCRIPTION OF THE PROBLEM :
Perhaps not really a bug, but I don't think that this should
be normal:

  user@...~> ulimit -a
  ...
  virtual memory (kbytes)     unlimited

  user@...~> java -version
  java version "1.4.1_01"
  Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.1_01-b01)
  Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

That's ok. But:

  user@...~> ulimit -a
  ...
  virtual memory (kbytes)     200000       (200MB)!!!

  user@...~> java -version
  Error occurred during initialization of VM
  java.lang.OutOfMemoryError: unable to create new native thread

200MB of virtual memory is not enough to only show the
version number of java?


REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
see description

I've set the limits for users using the file
/etc/security/limits.conf, adding this line:

@users hard    as       200000

EXPECTED VERSUS ACTUAL BEHAVIOR :
Is it really necessary to arise the virtual memory limit to
more than 200MB only to get version information? This is a
server where students "play" with programs using CPLEX (LP
solver) so we have to limit the virtual memory because of
erroneous programs using all memory (we had lot of system
crashes before).

ERROR MESSAGES/STACK TRACES THAT OCCUR :
see description

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
No limits for virtual memory.
(Review ID: 166328) 
======================================================================
Comments
EVALUATION Closing as WNF. The problem is that heap size ergo will come up with a size that can easily exceed the memory ulimit. This isn't so important now, what with the typical client machine having 2-4gb of memory, but the idea of automatic adaption to memory limits (i.e., chunking the heap or shrinking the ergo requent down until we succeed (in the absence of -Xmx) is a good one. It may be possible to adapt G1 in such as way as to accomplish the former, and the latter is documented by 6940674.
02-09-2010
EVALUATION Doesn't occur on redhat 7.2. Tried with JDK 1.4.2 -b05 ###@###.### 2002-11-05 ----------------------------------------- > Is it really necessary to arise the virtual memory limit to > more than 200MB only to get version information? If just to get version information, you can use a smaller heap, e.g. java -Xmx16m -version. But 16M heap might be too small for some applications. One of the reasons that 200M virtual memory is not enough is because GC needs continuous address space. So it has to reserve address space upfront. Note that it's not real memory allocation. Heap can grow/shrink as needed, but the address space for the entire Java heap must be reserved for GC. Also the 200M address space is shared by program image, thread stacks, C heaps, jar files, etc. Indeed, on my Redhat 7.3 box, by default "java -version" needs about 220M address space. So yes, (unfortunately) by default we need more than 200M address space. ###@###.### 2002-12-18 ------------------------------------------ See also 4607284 and 4665470. They are the umbrella bugs to track the efforts of reducing footprint. But unfortunately the virtual memory requirement will unlikely to change. The focus is to reduce physical memory usage. To reduce virtual memory usage, heap must be split into chunks, which requires significant changes in VM, but with very little benefit (virtual memory does not use real physical memory until the page is touched). At this point, it seems the best solution is to document the virtual memory usage as a known limit. So I'm closing the bug as will-not-fix. ###@###.### 2004-04-21
21-04-2004