Method, apparatus and system for the Java Virutual Machine to adapt itself with the available system resources by changing the current memory management architecture to On-Demand.
Publication Date: 2010-Aug-05
The IP.com Prior Art Database
The core problem addressed by this invention is how dynamically the memory for processing an application - in a JVM (Java Virtual Machine) - can be extended or increased. This on-demand 'extra' memory allocation will address many issues what people encounter in today's world. One such issues is the 'OutOfMemory' exception thrown by a Java applications when they are not able to complete the processing of a transaction due to insufficient memory being available. One preliminary way of addressing this issue is to 'configure' the heapsize at the time of JVM start-up thru appropriate parameters. However even this will not help at situations because the JVM has to be shutdown and restarted if we want to change the allotted heapsize. The other interesting problem this invention addresses is how physical resources can be maintained on the equilibrium state among the Java processes running parallel due to static heap's size management issue. To explain this further, first let us take a case study of FlatFile adapter - a sub-product of WebSphere family of products. All WebSphere Adapters support two modes of communications - Inbound & Outbound. Inbound allows adapters to poll the target EIS (or resource system) at predefined intervals; whereas in Outbound flow, clients external to the adapter will send the events to adapter and the adapter will update the corresponding records in the EIS (resource system) suitably. Same is depicted below. Incase of FlatFile adapter, the inbound mode can be configured to poll a set of directories for different file extensions. These files once processed by adapter are sent to the listening endpoints. However, when you are using a FlatFile adapter instance to poll a huge file, you have to set the -Xms value of the JVM appropriately before you start the Java processing because it is obvious that JVM needs enough memory (in proportional to the size of the file being polled). Once the FlatFiles adapter start processing the huge event file, it may encounter a MemoryOutOfBoundException when the configured JVM heap size is not sufficient to process the polled file. Also when you are running a Java application, the JVM the heapsize is to be fixed before we run the JVM. If flag -Xmx1g -Xms500m are set on the command line and there is 2 Gigabytes of physical memory available due to suspending of all the resources in later point of time, the VM cannot increase the maximum heap size to 2 Gigabytes just because what we entered at the time of JVM startup was -Xmx1g. What it means is, though you have enough memory on the system which is unused, there is no way we can utilize it to process more at the JVM level. Thus the problem is, in today's world, the heapsize is statically allocated, which creates problems like dynamically expanding the usage of the resources, provided and available in the Operating System are not used to 100% thus resulting in memory related issues.
Method, apparatus and system for the Java Virutual Machine to adapt itself with the
available system resources by changing the current memory management architecture
The code snippet below explains when we will get OutOfMemoryError from JVM (
Note: This is being run on Java1.6, under Win-XP Servicepack3 on CoreDuo processor I)
And the exception trace is,
And below is the working model of code snippet,
When we run this above sample in same above mentioned environment, the program executes
In the above example, we try to allocate an array with 61889325 boolean values. As single
boolean may be represented as at one byte, we can calculate the total amount of needed
RAM-Space as below:
61889325 =~ 60Mb
Thus we cannot allocate an array of size 60mb by default. However this situation can be
resolved by setting the Java heap-size values while starting the application like this
Thus the program run successfully by setting the Heap-value allocated to the JVM by the
operating system to be 65mbs
Options to set Java Heap :
Sets the initial size of the Java heap.
The default size is 2097152 (2MB).
The values must be a multiple of, and greater than, 1024 bytes(1kb)
Sets the initial Java heap size for the Eden generation.
The default value is 640K.
Sets the maximum size to which the Java heap can grow.
The default size is 64M.
Thus the problem here is, whenever there is a mismatch in the Heap size of the JVM and the
application executing on the JVM we get "Memory out of bound" exception despite there are
resources available on the system. (Example is a system having 2GB physical memory + 8GB
Note: The system is Win-XP Ultimate 64-bit running on a Core-Duo with 2GB RAM)
The JVM is not utilizing the hardware resources completely. The memory is allocated statically
at the starting of the application as specified by the Xmx/Xms/Xmn value to the JVM, thus JVM
has a constraint that the maximum memory allocation for the variables in the application should
not exceed this (Xmx) limit.
Thus the idea is to change the Initial memory allocation architecture to a on-demand based
memory allocation architecture.
The Memory Allocation is moved in to a Separate Module, lets call the module as
This module does the following tasks
1) Allocates memory from the OS
2) Deallocates memory from OS
3) Addressing the memory locations
4) Returning the memory addresses of the objects
5) Traversing the input-stream according to the pseudo addressing (
6) Storing the objects in the Heap
7) Maintains a pseudo address for the memory allocated from the OS for heap, as if the
memory is contiguous
8) Address mapping between JVMs program-counter and the Microprocessor for execution
Current JVM Architecture is like this
pseudo addressing is...