Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4846904

RFE: Max memory relative to physical memory option


    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 1.4.0
    • Fix Version/s: None
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • CPU:
    • OS:


      Name: rmT116609 Date: 04/10/2003

      For shrink-wrapped desktop Java applications, there is no way of setting the max heap size (-Xmx option) relative to the physical memory in the computer.

      PLEASE give us an option to say -Xmx50% to use up to 50% of the physical memory. SURELY that would be easy to add to the Java launcher! Here's why we need it:

      A simple example of a desktop application is one that manages a collection of images. In order to provide quick responses on browsing images, it caches the images in memory. Typically it needs at least 40Mb of memory and more depending on the required performance (for usability) and the number of images.

      With the current Java options the application packager needs to make an assumption as to the max amount of memory allowed for the application. BUT this needs to be within the physical memory of the target audience. Let's say they decide on 90Mb.

      - If a user has 1Gb of memory, the Java runtime can NEVER use any of this extra capacity, and so the application runs at a similar speed to a PC with 128Mb of memory.

      - If a user has 64Mb of memory and tries to view some reasonably large images, the Java application will start using virtual memory. The operating system will be constantly paging memory from disk (regardless of whether the user switches to and from other applications) which will render the performance utterly useless. Operations that happen millions of times a second will now take 100's of times longer. (Hard disk access speed is several orders of magnitude slower than RAM).

      It is impossible to bundle a Java application that determines a suitable amount of memory to use based on the user's desktop PC configuration.

      For server applications, this isn't such a problem. There will be a technical person installing the application and they *should* be capable of configuring the memory use appropriately.

      But for desktop applications this is unacceptable. There is no way you can expect an end user to determine the amount of memory in MB that they allocate to their newly installed "Bob's Image Browser".

      There are some other RFE's that touch on this issue but none that are specifically about this problem. Some mention that you can't use (say) 50% of the physical RAM because you have no idea how many other applications are running at the same time.

      But this is a weak argument. Heavyweight desktop applications such as Adobe Photoshop have a max memory limit according to some percentage of the memory of the PC. The default is 50%, which allows extra space for system memory and other light-weight applications.

      And in any case, the purpose of paging on a desktop OS is to allow ONE application to use up a large amount of memory (but in many cases including Java it is best limited to the amount of physical RAM). When the user switches applications there is an acceptable pause as the entire applications may be paged to and from disk until the next app is entirely in physical RAM.

      There *are* other RFE's that touch upon this issue but none devoted to it. Note that *dynamically* changing the memory allocation (as discussed in other RFE's) is not relevant since no desktop PC's currently allow hot-swapping of RAM.

      Although the desktop market for Java is less mature and smaller than the server / enterprise market, please help us minority developers who are trying to build realistic shrink-wrap applications for the desktop and add this one small feature to Java.

      (Review ID: 183791)


          Issue Links



              • Assignee:
                sbohne Steve Bohne (Inactive)
                rmandalasunw Ranjith Mandala (Inactive)
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: