DPS 6.x jvm memory heap size?

I am setting up directory proxy server 6.3 and have the java setting for memory heap size in my notes from testing last year. Is it important to set this? Is the argument as stated ok? And is 500 ok? Doubt anything has changed since last year, but want to be sure. Thanks.
dpadm set-flags /opt/dps jvm-args="-Xmx500M -Xms500M -XX:NewRatio=1"

crosspost

Similar Messages

Setting memory heap size

Hi,
I would like to know how to set the default memory
heap size to 128 MB while installing the Java Plugin
itself.
Is there any environment variable available for setting
this?
I dont want to use the Control Panel option for setting
it.
Thanks for your help.

Hey i have the same issue, how did you solve it?
Hi Gkumarc1,
Plugin 1.3.0 (and after) reads the property filein
.java directory of user's home directory. Java
runtime parameter is saved in the property file.Here
is an example of it:
# Java(TM) Plug-in Properties
# DO NOT EDIT THIS FILE. It is machine generated.
# Use the Activator Control Panel to editproperties.
javaplugin.jre.params=-Xmx 128m
Hope this helps.
Sun-DTSIs there a way to set the default heap size on the
fly? Meaning, we want to avoid the need for our
customers to go into their control panel and make
this setting. Instead, we would like to have the
applet load with our preferred default VM size. This
would allow us to change the preferred size during
some future performance enchancements without having
to contact all of our 2,000+ external customers. Is
there something that can be put in the PARAM tag
within the HTML that specifies the
preferred/recommended default size?
Any help would be greatly appreciated.

OJVM memory heap size

Is there a way to specify OJVM maximum memory ( memory heap )
for Oracle8i JServer? Oracle9i JServer?
How do I pass -Xmx parameter to OJVM?
Thanks

I played with JAVA_POOL_SIZE, JAVA_MAX_SESSIONSPACE_SIZE,
JAVA_SOFT_SESSIONSPACE_LIMIT and it seems that JServer just ignores them.
I use this Java function to get available space.
This function ALWAYS returns the same value ( about 120M for Oracle8i and 190M for 9i) in spite of init.ora parameters.
public static final int MEGABYTE = 1048576;
public static long testMemory(int maximumMegabytesToTest)
Object[] memoryHolder = new
Object[maximumMegabytesToTest];
int count = 0;
try
for (; count < memoryHolder.length; count++)
memoryHolder[count] = new byte[MEGABYTE];
catch(OutOfMemoryError bounded){}
long highWater = Runtime.getRuntime().totalMemory();
memoryHolder = null; //release for GC
System.out.println(highWater);
return count;
Please advise

How do define the limit of the max heap size?

Hi All,
I would like to know what should be the limit of the JVM max heap size.
What will happen if we will not define it?
What is the purpose of defining it from the technical point of view?
Thanks
Edited by: Anna78 on Jul 31, 2008 12:36 PM

Defining a max heap space too large can have the following effect:
If you create new objects, the VM may decide it is not worth getting rid of garbage-collectable ones, as there
is still plenty of space between the current heap size and the max allowed. The result will be that the
application will run faster and will consume more memory than it really needs.
If the heap size is too small, but still sufficient, the application will do a lot of garbage-collection and therefore
run slower. On the other hand, it will stay inside the tight space it has been allowed to use.
The speed difference may or may not be noticeable, while the difference between 256M and 512M may
or may not matter on today's computers.

Java Heap Sizes -Xms -Xmx

Gurus,
Could some body help me to understand the differentiate between heap size parameters -Xms and -Xmx ? I usually change both of them. One another is that, the maximum heap size we can use is total ram/2 ?
Thanks,

Text from the above link
==================
As part of the Best Practices, we know that we should be setting -Xms & -Xmx Java command line parameters. What are these settings and why is it required to set these.
As JAVA starts, it creates within the systems memory a Java Virtual Machine (JVM). JVM is where the complete processing of any Java program takes place. All JAVA applications (including IQv6) by default allocates & reserves up to 64 MB of memory resource pool from the system on which it is running.
The Xms is the initial / minimum Java memory (heap) size within the JVM. Setting the initial memory (heap) size higher can help in a couple of ways. First, it will allow garbage collection (GC) to work less which is more efficient. The higher initial memory value will cause the size of the memory (heap) not to have to grow as fast as a lower initial memory (heap) size, thereby saving the overhead of the Java VM asking the OS for more memory.
The Xmx is the maximum Java memory (heap) size within the Java Virtual Memory (JVM). As the JVM gets closer to fully utilizing the initial memory, it checks the Xmx settings to find out if it can draw more memory from the system resources. If can, it does so. For the JVM to allocate contiguous memory to itself is a very expensive operation. So as the JVM gets closer to the initial memory, the JVM will use aggressive garbage collection (to clean the memory and if possible avoid memory allocation), increasing the load on the system.
If JVM is in need of memory beyond the value set in Xmx, the JVM will not be able to draw more memory from system resource (even if available) and run out of memory. Hence, the -Xms and -Xmx memory parameters should be increased depending upon the demand estimation of the system. Ideally both same should be the same value (set at maximum possible as per demand estimation). This ensure that the maximum memory is allocated right at the start-up eliminating the need for extra memory allocation during program execution. We recommend aggressive maximum memory (heap) size of between 1/2 and 3/4 of physical memory.
Edited by: oracleSQR on Oct 7, 2009 10:38 AM

How to set the Heap size for JAVA

I am facing the memory out of space problem:
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Could anyone suggest me a solution to solve the problem ?
increase the heap size ?
anyway to increase the heap size in the program by default without additional setup?
Thank you.

How to determine the program must handled with increase heap size ?
could I know any method to know whether the program is memory leaking or need large memory heap size?

Massive memory hemorrhage; heap size to go from about 64mb, to 1.3gb usage

**[SOLVED]**
Note: I posted this on stackoverflow as well, but a solution was not found.
Here's the problem:
[1] http://i.stack.imgur.com/sqqtS.png
As you can see, the memory usage balloons out of control! I've had to add arguments to the JVM to increase the heapsize just to avoid out of memory errors while I figure out what's going on. Not good!
##Basic Application Summary (for context)
This application is (eventually) going to be used for basic on screen CV and template matching type things for automation purposes. I want to achieve as high of a frame rate as possible for watching the screen, and handle all of the processing via a series of separate consumer threads.
I quickly found out that the stock Robot class is really terrible speed wise, so I opened up the source, took out all of the duplicated effort and wasted overhead, and rebuilt it as my own class called FastRobot.
##The Class' Code:
    public class FastRobot {
         private Rectangle screenRect;
         private GraphicsDevice screen;
         private final Toolkit toolkit;
         private final Robot elRoboto;
         private final RobotPeer peer;
         private final Point gdloc;
         private final DirectColorModel screenCapCM;
         private final int[] bandmasks;
         public FastRobot() throws HeadlessException, AWTException {
              this.screenRect = new Rectangle(Toolkit.getDefaultToolkit().getScreenSize());
              this.screen = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
              toolkit = Toolkit.getDefaultToolkit();
              elRoboto = new Robot();
              peer = ((ComponentFactory)toolkit).createRobot(elRoboto, screen);
              gdloc = screen.getDefaultConfiguration().getBounds().getLocation();
              this.screenRect.translate(gdloc.x, gdloc.y);
              screenCapCM = new DirectColorModel(24,
                        /* red mask */    0x00FF0000,
                        /* green mask */ 0x0000FF00,
                        /* blue mask */   0x000000FF);
              bandmasks = new int[3];
              bandmasks[0] = screenCapCM.getRedMask();
              bandmasks[1] = screenCapCM.getGreenMask();
              bandmasks[2] = screenCapCM.getBlueMask();
              Toolkit.getDefaultToolkit().sync();
         public void autoResetGraphicsEnv() {
              this.screenRect = new Rectangle(Toolkit.getDefaultToolkit().getScreenSize());
              this.screen = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
         public void manuallySetGraphicsEnv(Rectangle screenRect, GraphicsDevice screen) {
              this.screenRect = screenRect;
              this.screen = screen;
         public BufferedImage createBufferedScreenCapture(int pixels[]) throws HeadlessException, AWTException {
    //          BufferedImage image;
            DataBufferInt buffer;
            WritableRaster raster;
              pixels = peer.getRGBPixels(screenRect);
              buffer = new DataBufferInt(pixels, pixels.length);
              raster = Raster.createPackedRaster(buffer, screenRect.width, screenRect.height, screenRect.width, bandmasks, null);
              return new BufferedImage(screenCapCM, raster, false, null);
         public int[] createArrayScreenCapture() throws HeadlessException, AWTException {
                   return peer.getRGBPixels(screenRect);
         public WritableRaster createRasterScreenCapture(int pixels[]) throws HeadlessException, AWTException {
         //     BufferedImage image;
             DataBufferInt buffer;
             WritableRaster raster;
              pixels = peer.getRGBPixels(screenRect);
              buffer = new DataBufferInt(pixels, pixels.length);
              raster = Raster.createPackedRaster(buffer, screenRect.width, screenRect.height, screenRect.width, bandmasks, null);
         //     SunWritableRaster.makeTrackable(buffer);
              return raster;
    }In essence, all I've changed from the original is moving many of the allocations from function bodies, and set them as attributes of the class so they're not called every time. Doing this actually had a significant affect on frame rate. Even on my severely under powered laptop, it went from ~4 fps with the stock Robot class, to ~30fps with my FastRobot class.
##First Test:
When I started outofmemory errors in my main program, I set up this very simple test to keep an eye on the FastRobot. Note: this is the code which produced the heap profile above.
    public class TestFBot {
         public static void main(String[] args) {
              try {
                   FastRobot fbot = new FastRobot();
                   double startTime = System.currentTimeMillis();
                   for (int i=0; i < 1000; i++)
                        fbot.createArrayScreenCapture();
                   System.out.println("Time taken: " + (System.currentTimeMillis() - startTime)/1000.);
              } catch (AWTException e) {
                   e.printStackTrace();
    }##Examined:
It doesn't do this every time, which is really strange (and frustrating!). In fact, it rarely does it at all with the above code. However, the memory issue becomes easily reproducible if I have multiple for loops back to back.
#Test 2
    public class TestFBot {
         public static void main(String[] args) {
              try {
                   FastRobot fbot = new FastRobot();
                   double startTime = System.currentTimeMillis();
                   for (int i=0; i < 1000; i++)
                        fbot.createArrayScreenCapture();
                   System.out.println("Time taken: " + (System.currentTimeMillis() - startTime)/1000.);
                   startTime = System.currentTimeMillis();
                   for (int i=0; i < 500; i++)
                        fbot.createArrayScreenCapture();
                   System.out.println("Time taken: " + (System.currentTimeMillis() - startTime)/1000.);
                   startTime = System.currentTimeMillis();
                   for (int i=0; i < 200; i++)
                        fbot.createArrayScreenCapture();
                   System.out.println("Time taken: " + (System.currentTimeMillis() - startTime)/1000.);
                   startTime = System.currentTimeMillis();
                   for (int i=0; i < 1500; i++)
                        fbot.createArrayScreenCapture();
                   System.out.println("Time taken: " + (System.currentTimeMillis() - startTime)/1000.);
              } catch (AWTException e) {
                   e.printStackTrace();
    }##Examined
The out of control heap is now reproducible I'd say about 80% of the time. I've looked all though the profiler, and the thing of most note (I think) is that the garbage collector seemingly stops right as the fourth and final loop begins.
The output form the above code gave the following times:
Time taken: 24.282 //Loop1
Time taken: 11.294 //Loop2
Time taken: 7.1 //Loop3
Time taken: 70.739 //Loop4
Now, if you sum the first three loops, it adds up to 42.676, which suspiciously corresponds to the exact time that the garbage collector stops, and the memory spikes.
[2] http://i.stack.imgur.com/fSTOs.png
Now, this is my first rodeo with profiling, not to mention the first time I've ever even thought about garbage collection -- it was always something that just kind of worked magically in the background -- so, I'm unsure what, if anything, I've found out.
##Additional Profile Information
[3] http://i.stack.imgur.com/ENocy.png
Augusto suggested looking at the memory profile. There are 1500+ `int[]` that are listed as "unreachable, but not yet collected." These are surely the `int[]` arrays that the `peer.getRGBPixels()` creates, but for some reason they're not being destroyed. This additional info, unfortunately, only adds to my confusion, as I'm not sure why the GC wouldn't be collecting them
##Profile using small heap argument -Xmx256m:
At irreputable and Hot Licks suggestion I set the max heap size to something significantly smaller. While this does prevent it from making the 1gb jump in memory usage, it still doesn't explain why the program is ballooning to its max heap size upon entering the 4th iteration.
[4] http://i.stack.imgur.com/bR3NP.png
As you can see, the exact issue still exists, it's just been made smaller. ;) The issue with this solution is that the program, for some reason, is still eating through all of the memory it can -- there is also a marked change in fps performance from the first the iterations, which consume very little memory, and the final iteration, which consumes as much memory as it can.
The question remains why is it ballooning at all?
##Results after hitting "Force Garbage Collection" button:
At jtahlborn's suggestion, I hit the Force Garbage Collection button. It worked beautifully. It goes from 1gb of memory usage, down to the basline of 60mb or so.
[5] http://i.stack.imgur.com/x4282.png
So, this seems to be the cure. The question now is, how do I pro grammatically force the GC to do this?
##Results after adding local Peer to function's scope:
At David Waters suggestion, I modified the `createArrayCapture()` function so that it holds a local `Peer` object.
Unfortunately no change in the memory usage pattern.
[6] http://i.stack.imgur.com/Ky5vb.png
Still gets huge on the 3rd or 4th iteration.
#Memory Pool Analysis:
###ScreenShots from the different memory pools
##All pools:
[7] http://i.stack.imgur.com/nXXeo.png
##Eden Pool:
[8] http://i.stack.imgur.com/R4ZHG.png
##Old Gen:
[9] http://i.stack.imgur.com/gmfe2.png
Just about all of the memory usage seems to fall in this pool.
Note: PS Survivor Space had (apparently) 0 usage
##I'm left with several questions:
(a) does the Garbage Profiler graph mean what I think it means? Or am I confusing correlation with causation? As I said, I'm in an unknown area with these issues.
(b) If it is the garbage collector... what do I do about it..? Why is it stopping altogether, and then running at a reduced rate for the remainder of the program?
(c) How do I fix this?
Does anyone have any idea what's going on here?
[1]: http://i.stack.imgur.com/sqqtS.png
[2]: http://i.stack.imgur.com/fSTOs.png
[3]: http://i.stack.imgur.com/ENocy.png
[4]: http://i.stack.imgur.com/bR3NP.png
[5]: http://i.stack.imgur.com/x4282.png
[6]: http://i.stack.imgur.com/Ky5vb.png
[7]: http://i.stack.imgur.com/nXXeo.png
[8]: http://i.stack.imgur.com/R4ZHG.png
[9]: http://i.stack.imgur.com/gmfe2.png
Edited by: 991051 on Feb 28, 2013 11:30 AM
Edited by: 991051 on Feb 28, 2013 11:35 AM
Edited by: 991051 on Feb 28, 2013 11:36 AM
Edited by: 991051 on Mar 1, 2013 9:44 AM

SO came through.
Turns out this issue was directly related to the garbage collector. The default one, for whatever reason, would get behind on its collection at points, and thus the memory would balloon out of control, which then, once allocated, became the new normal for the GC to operate at.
Manually setting the GC to ConcurrentMarkSweep solved this issue completely. After numerous tests, I have been unable to reproduce the memory issue. The garbage collector does an excellent job of keeping on top of these minor collections.

Large JVM heap sizes under windows xp?

I have a windows XP Pro SP1 box with 2 GB of physical RAM. I am using the latest jdk, 1.4.2_05.
I understand that 32 bit windows by default allows 2 GB address space for each application, permanently reserving 2 GB for the OS. (There are also apparently special builds going back to win2k which have a special mode where applications can address 3 GB and the OS addresses 1 GB; if anyone knows how to turn this mode on under win xp please let me know.)
So, I should be able to allocate ~2 GB to the JVM (the number is slightly less than 2 GB due to overhead associated with each process in windows) using something like
     -Xms1900m -Xmx1900m
as command line args to the java command.
But when I try the above it crashes with the error
     Error occurred during initialization of VM
     Could not reserve enough space for object heap
Experimentally, I found that the maximum value which works on my box is
     -Xms1200m -Xmx1200m
which seems way smaller than it ought to be.
Doing a forum search, I found others who report similar issues, e.g.
     http://forum.java.sun.com/thread.jsp?forum=136&thread=522506
But I did not find a decent solution or up to date discusssion.
Does anyone know with windows xp pro what the jvm memory limit is?
As part of my sun search, I came across the following old (circa 2000) but interesting bug report:
     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4358809
I have never heard of the rebase program before. Is it built into windows? Is it safe to use? Anyone ever try the command as described there?

In addition to this forum posting, I got in email communication with Peter Kessler, the technical lead for the garbage collector in the HotSpot(TM) virtual machine). Below are snippets from some of his emails to me.
#1:
I haven't tried pushing Windohs XP to see how big I could get the
heap. I'm pretty sure you don't want to get try to get it to 1.9GB,
since that wouldn't leave much room for DLL's, JVM data structures
outside the heap, thread stacks, I/O buffers, etc.
I don't know what the library C:\WINDOWS\System32\LPK.DLL is, or if
you could successfully rebase it closer to 0x76000000. The issue
with rebasing DLL's is that people have sometimes given thought to
where they should be, given other libraries they are typically used
with. (If a DLL can't be loaded at its default base address, it
gets relocated dynamically. That slows down program startup; and
often means that the library can't be shared with other applications
running on the same machine, increasing your need for swap file
space.)
It does seem weird that we would make the default base for jvm.dll
be 0x08000000, but the base of hpi.dll at 0x10000000. [See email #3 below]
The jvm.dll isn't going to get that much larger any time soon. I'll ask around
about that one. (The library bases for JDK-1.4.2 are different
from those reported in bug id 4358809 for because we periodically
reconsider where to base the libraries, given the other libraries
on a particular release of Windohs.)
So, I don't have any great advice on how to squeeze another 400MB of
heap out of your machine. I suppose it's fruitless to ask if you
could squeeze 400MB of data structures out of your application?
Have you run an allocation profiler on it?
Since you are willing to switch operating systems, you can download
a copy of Solaris 10 for x86 platforms (for free) from
http://wwws.sun.com/software/solaris/10/
I just tried a Solaris 10 x86 box, and could get a -Xmx2900m jvm to
start. But without your application it's hard to know if it would
run well with that size heap (e.g., if it would have room for thread
stacks, file buffers, etc.), so your milage may vary, but 2.9GB is
larger than you say you need. There are lots of other benefits of
running Solaris. I don't know about making you a poster child, but
I could ask about that, too.
#2:
I'm told that some of the popular distibutions of Linux ship with
a "4GB" kernel, which allows one to get 3GB (2.4 kernels?) or almost
4GB (2.6 kernels?) of address space for user processes. I haven't
used those kernels myself. Among the reasons the 4GB kernel isn't
the standard kernel is that some user programs are surprised (in a
bad way) by finding their code or data in the "negative" part of
the address space, or crossing the "sign-bit" boundary. (Of course,
all addressing arithmetic should be done as unsigned quantities!)
Our Java virtual machine shouldn't have those problems, so that
kernel might work for you.
#3:
Ah. It looks like in JDK-1.4.2 (and earlier) we forgot to
explicitly set the base for hpi.dll, so it got the default
base of 0x10000000. (Don't we love learning these details
about Windohs?) As I said, we periodically reconsider the
bases for the libraries. We seem to have done that, more
thoroughly, for JDK-1.5.0:
Base Size Version Path
0x00400000 0xc000 1.05.0000.0000 C:\pbk\deployed\JDK-1.5.0\bin\java.EXE
0x77f80000 0x7d000 5.00.2195.6899 C:\WINNT\system32\ntdll.dll
0x7c2d0000 0x62000 5.00.2195.6876 C:\WINNT\system32\ADVAPI32.dll
0x7c570000 0xb8000 5.00.2195.6897 C:\WINNT\system32\KERNEL32.DLL
0x77d30000 0x71000 5.00.2195.6904 C:\WINNT\system32\RPCRT4.DLL
0x78000000 0x45000 6.01.9844.0000 C:\WINNT\system32\MSVCRT.dll
0x6d6b0000 0x185000 1.05.0000.0000 C:\pbk\deployed\JDK-1.5.0\jre\bin\client\jvm.dll
0x77e10000 0x65000 5.00.2195.6897 C:\WINNT\system32\USER32.dll
0x77f40000 0x3e000 5.00.2195.6898 C:\WINNT\system32\GDI32.DLL
0x77570000 0x30000 5.00.2161.0001 C:\WINNT\system32\WINMM.dll
0x6d2f0000 0x8000 1.05.0000.0000 C:\pbk\deployed\JDK-1.5.0\jre\bin\hpi.dll
0x690a0000 0xb000 5.00.2134.0001 C:\WINNT\system32\PSAPI.DLL
0x6d680000 0xc000 1.05.0000.0000 C:\pbk\deployed\JDK-1.5.0\jre\bin\verify.dll
0x6d370000 0x1d000 1.05.0000.0000 C:\pbk\deployed\JDK-1.5.0\jre\bin\java.dll
0x6d6a0000 0xf000 1.05.0000.0000 C:\pbk\deployed\JDK-1.5.0\jre\bin\zip.dll
You might want to try the "release candidate" (i.e., what we
hope will be the final bits) of JDK-1.5.0 from
http://java.sun.com/j2se/1.5.0/download.jsp
and see if it helps.

JVM heap size limit under Windows

Hi,
I'm looking either for some help with a workaround, or
confirmation that the information I've found is still the case for the
current state of Java.
Development machine is Win XP Pro, 2G RAM.
Biggest heap I can allocate is about 1.6G, and that is not large enough for this
app.
I have a Swing application that
1) must run on Win XP, 32 bit
2) must implement an editor (similar to Excel but with fewer features) to handle large csv files
( up to about 800Mb).
3) Strong preference for Java 5, though higher could conceivably be supported.
Research so far tells me that this is the result of process memory limitations
of Windows and the JVM, and that I might be able to squeeze a little more heap with
Windows' rebase command, but probably not enough and I would start running the
risk of conflicts with other applications on my users' systems. Ugh.
Also I read of the Windows /3GB switch, but posts say that the JDK's available are not
built to be able to use that feature. I havent had a chance to add memory to
test that yet. However, I'm also under the impression that I should be able to
allocate a heap larger than physical RAM ... except for that process size limit.
So ... my information is basically that I'm stuck with a limit of about 1.6G for
heap size, regardless of the RAM on my computer.
Can anyone confirm whether that is still correct, preferably with a pointer to some
official reference ?
Or better yet, point me toward a workaround?
Thanks!
-tom

>
Some bookmarks I have on this topic.
http://sinewalker.wordpress.com/2007/03/04/32-bit-windows-and-jvm-virtual-memory-limit/
http://stackoverflow.com/questions/171205/java-maximum-memory-on-windows-xp
The first link pulled together what I found in lots of bits and pieces elsewhere, nice to have a coherent summary :)
The second link offered a bit of insight into the jvm that I hadn't seen yet .
Thanks!

Maximum heap size for 64bit JVM

Hi,
I am trying to set the maximum heap size for a java process in a 64bit JVM . I am not able to set more then 3G
command line config:
java -Xms64m -Xmx3g -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=8000 com.superpages.puboptions.CampaignFeedStarter >> publisher.out 2>&1 &
Hardware / software configs
*$uname -a*
SunOS labsbear 5.9 Generic_122300-19 sun4u sparc SUNW,Sun-Fire-V440
*16GB total physical memory*
*4 processor machine*
*64 bit JVM*
JDK1.6
where is this limitation coming from. How to set the heap size to 6g.
Thanks for your time
Meena

You need to use the -d64 switch to request the 64-bit JVM. E.g.,$ java -showversion -Xmx6g HelloWorld
Invalid maximum heap size: -Xmx6g
The specified size exceeds the maximum representable size.
Could not create the Java virtual machine.
$ java -showversion -d64 -Xmx6g HelloWorld
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b04)
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
Hello world!

Upto how much I can set maximum Heap size for jvm?

I am running application on 8GB RAM Windows 64 bits machine.
I am running out of OutOfMemory (Heap Space). I want to increase the Heap Size for my jvm.
But can anybody please tell me what is the limit by which I can set the maximum size for heap?
Thanks in Advance,
Jenish

Max allowed memory per process is 2 raised to the 64th power. What maximum memory you can set depends on the memory available
for your application. You may be able to set more than 8GB ram then it will use the swap space and it will slow down your application
performance. So try different memory size and see which one works best for your application.

Memory Usage in WinTaskManger vs heap size

hello,
I have exactly the same problem as in the topic "Windows Task Manager vs. Heap", posted at Dec 10, 2004 5:17 AM, by jorgeHX.
Here are the symptoms:
1) My application starts at 20MB seen by windows task manager
2) I use profiler to monitor the heap. Heap is always working very healthly - heap size in the profiler increases by a minimum until the gc comes around so that the used heap size drops down again.
3) However, after doing a relatively memory-consuming operation (loop of String indexing, patterning ..etc.), the memory usage in windows task manager goes up couple of MBs but never drops down.
4) Then I go manually free the heap (System.gc()), I can see GC is freeing heap. However, the memory in windows task manager remains no change, no matter how many times I force the garbabge collection.
This is a bad thing - if my application keeps doing that memory-consuming operation again and again, the memory seen in the windows task manager will be growing and growing to hundreds of MBs until the windows alerts "low on virtual memory".
I tried everything already. I set every instance = null at the end, I delete every reference but the memory just keeps increasing! WHY?????
Anyone can help me charactorize the problem? I am so in dark!!
Ryan-Chi

I guess my problem can also be interpretated as
"Why doesn't JVM return memory to OS?"
It does, depending on the setting of the -XX:MaxHeapFreeRatio option. "Normal" operation using the default setting does not usually cause memory to be returned to the os.
Search for this option term for explanations.

Mapping set heap sizes to used memory

Hi all,
I've got a question about the parameters used to control your java process' heap sizes: "-Xms128m -Xmx256m" etc.
Let's say I set my min and max to 2Gb, just for a simplistic example.
If I then look at the linux server my process is running on, I may see a top screen like so:
PID USER      PR NI VIRT RES SHR S %CPU %MEM    TIME+ COMMAND
10647 javaprog 20   0 2180m 1.9g 18m S 1.3 3.7   1:57.02 javaWhat I'm trying to understand is what relationship - if any - there is between these arguments and the figures I see within top. One thing in particular that I'm interested in is the fact that I occasionally see a RES (or more commonly a VIRT) size higher than the maximum that I have provided to Java. Naively I would assume that therefore there isn't a relationship between the two... but I wouldn't mind someone clarifiying this for me.
Any resources on the matter would be appreciated, and I apologise if this question is outside the realms of this particular subforum.
Dave.

Peter Lawrey wrote:
user5287726 wrote:
Peter Lawrey wrote:
It will always reserve this much virtual memory, plus. In term of resident memory, even the minimum is not guarenteed to be used. The minimum specifies at what point it will make little effort to recycle memory. i.e. it grows to the minimum size freely, but a "Hello World" program still won't use the minimum size.No, Linux does not reserve virtual memory. Just Google "Linux memory overcommit". Out-of-the-box, every Linux distro I'm aware of will just keep returning virtual memory to processes until things fall apart and the kernel starts killing processes that are using lots of memory - like your database server, web server, or application-critical JVMs. You know - the very processes you built and deployed the machine to run. Just Google "Linux OOM killer".Thats not the behaviour I see. When I start a process which busy waits, but doesn't create any objects, the virtual memory sized used is based on the -mx option, not how much is used. Given virtual memeory is largely free, why would an OS only give virtual memory on an as needs basis.
Busy looping process which does nothing.
In each case the resident size is 16m
option       virtual size
-mx100m      368m = 100m + 268m
-mx250m      517m = 250m + 267m
-mx500m      769m = 500m + 269m
-mx1g        1294m = 1024m + 270m
-mx2g        2321m = 2048m + 273mTo me it appears that the maximum size you ask is immediately added to the virtual memory size, even if its not used (plus an overhead) i.e. the resident size is only 16m.Yes, it's only using 16m. And its virtual size may very well be what you see. But that doesn't mean the OS actually has enough RAM + swap the hold what it tells all running processes they can have.
How much RAM + swap does your machine have? Say it's 4 GB. You can probably run 10 or 20 JVMs simultaneously with the "-mx2g" option. Imagine what happens, though, if they actually try and use that memory - that the OS said they could have, but which doesn't all exist.
What happens?
The OOM killer fires up and starts killing processes. Which ones? Gee, it's a "standard election procedure". Which on a server that's actually doing something tend to be the processes actually doing something, like your DBMS or web server or JVM. Or maybe it's your backups that get whacked because they're "newly started" and got promised access to memory that doesn't exist.
Memory overcommit on a server with availability and reliability requirements more stringent than risible is indefensible.

Heap size memory error on WebI Reports

Hello,
I'm developping my own JDBC driver to report specific data in Business Objects. I've actually an universe build on this driver and a web intelligence report. When I try to request I've an heap size error due to the size of my jvm. My JBDC driver is deployed thanks to a jar file. Normally I can increase jvm size with the argument -Xmx256M in command-line.
I tried several things :
I modified register HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Session Manager/Subsystems, SharedSection to 1024,3072,1024
I passed Tomcat's memory to 1024, I can't more because I'm on 32 bits on Windows Server 2003.
I tried to add MAX_HEAP_SIZE=1024000000 on webi.properties in c:\programfiles\Tomcat\webapps\businessobjects\enterprise115\desktoplaunch\WEB-INF\classes\, as explained on a post,but this directory doesn't exist, but there is 4 different webi.properties files one in C:\Program Files\Business Objects\Tomcat55\webapps\PerformanceManagement\WEB-INF\lib so I added max heap size parameter in this one.
I improved my JDBC-driver to avoid memory leak, and BO requests to limit results.
But I still have an heap size error.
Some people have other ideas to solve my problem ?
Best regards.
BO XI 3.1 Service Pack 2 HotFix 1
Tomcat 5.5 : 1024Mo memory allocation
Windows Server 2003 32bits

Hi Hizam,
1. Go to universe and click on View--> Structure
2. Check objects and Conditions.
3. If you found any changes then re-export your universe and run queries.
Once everything goes fine then Schedule the report.
Hope it helps you....!!
Thank You!

How to increase JVM Heap Size

Hi all,
Our Environment
===============
OS - Windows XP Service Pack 3
Oracle Developer Suite - 10.1.2.3.0
Oracle Forms & Reports Service 10.1.2.3.0
Oracle Database 10.2.0.1.0
JDK 1.5
Jinitiator 1.3.1.30
Apache POI 3.5
From forms we are writing to excel files after copying XL template using Apache POI 3.5 and JDK 1.5. This XL template file has got lot of macros.
We have imported the Java class files into form as pl/sql library. We are able to write upto 7Mb size of XL file. Beyond that size it comes with the error Ora-105101.
We tried to increase the JVM Heap Size to 640M by setting values -Xmx640M everywhere in OC4J_BI_FORMS/Server Properties/Java Options, Home/Server Properties/Java Options through Enterprise Manager console. Also manually set the values in OPMN.XML and reloaded the same. Also set -Xmx640M in Jinitiator 1.3.1.30 Java Runtime Parameters. Also set in Java console. All settings have no effect.
We have written a small program to display the run time memory from forms, which displays only maximum memory 63M all the time.
PACKAGE BODY HeapSize IS
-- DO NOT EDIT THIS FILE - it is machine generated!
args JNI.ARGLIST;
-- Constructor for signature ()V
FUNCTION new RETURN ORA_JAVA.JOBJECT IS
BEGIN
args := NULL;
RETURN (JNI.NEW_OBJECT('HeapSize', '()V', args));
END;
-- Method: getTotalMemory ()D
FUNCTION getTotalMemory(
obj ORA_JAVA.JOBJECT) RETURN NUMBER IS
BEGIN
args := NULL;
RETURN JNI.CALL_DOUBLE_METHOD(FALSE, obj, 'HeapSize', 'getTotalMemory', '()D', args);
END;
-- Method: getMaxMemory ()D
FUNCTION getMaxMemory(
obj ORA_JAVA.JOBJECT) RETURN NUMBER IS
BEGIN
args := NULL;
RETURN JNI.CALL_DOUBLE_METHOD(FALSE, obj, 'HeapSize', 'getMaxMemory', '()D', args);
END;
BEGIN
NULL;
END;
declare
obj ORA_JAVA.JOBJECT;
BEGIN
obj:=HeapSize.new;
message('Total memory '||HeapSize.getTotalMemory(obj));
message('Max memory '||HeapSize.getMaxMemory(obj));
END;
Below procedure is for writing to Excel file.
============================================
PACKAGE BODY UWWriteExcel IS
-- DO NOT EDIT THIS FILE - it is machine generated!
args JNI.ARGLIST;
-- Constructor for signature ()V
FUNCTION new RETURN ORA_JAVA.JOBJECT IS
BEGIN
args := NULL;
RETURN (JNI.NEW_OBJECT('UWWriteExcel', '()V', args));
END;
-- Method: copyExcel (Ljava/lang/String;Ljava/lang/String;)V
PROCEDURE copyExcel(
obj ORA_JAVA.JOBJECT,
a0 VARCHAR2,
a1 VARCHAR2) IS
BEGIN
args := JNI.CREATE_ARG_LIST(2);
JNI.ADD_STRING_ARG(args, a0);
JNI.ADD_STRING_ARG(args, a1);
JNI.CALL_VOID_METHOD(FALSE, obj, 'UWWriteExcel', 'copyExcel', '(Ljava/lang/String;Ljava/lang/String;)V', args);
END;
-- Method: getSpreadSheetPara (Ljava/lang/String;)V
PROCEDURE getSpreadSheetPara(
obj ORA_JAVA.JOBJECT,
a0 VARCHAR2) IS
BEGIN
args := JNI.CREATE_ARG_LIST(1);
JNI.ADD_STRING_ARG(args, a0);
JNI.CALL_VOID_METHOD(FALSE, obj, 'UWWriteExcel', 'getSpreadSheetPara', '(Ljava/lang/String;)V', args);
END;
-- Method: openSheet (I)V
PROCEDURE openSheet(
obj ORA_JAVA.JOBJECT,
a0 NUMBER) IS
BEGIN
args := JNI.CREATE_ARG_LIST(1);
JNI.ADD_INT_ARG(args, a0);
JNI.CALL_VOID_METHOD(FALSE, obj, 'UWWriteExcel', 'openSheet', '(I)V', args);
END;
-- Method: getCellValues (IID)V
PROCEDURE getCellValues(
obj ORA_JAVA.JOBJECT,
a0 NUMBER,
a1 NUMBER,
a2 NUMBER) IS
BEGIN
args := JNI.CREATE_ARG_LIST(3);
JNI.ADD_INT_ARG(args, a0);
JNI.ADD_INT_ARG(args, a1);
JNI.ADD_DOUBLE_ARG(args, a2);
JNI.CALL_VOID_METHOD(FALSE, obj, 'UWWriteExcel', 'getCellValues', '(IID)V', args);
END;
-- Method: getCellValues (IILjava/lang/String;)V
PROCEDURE getCellValues(
obj ORA_JAVA.JOBJECT,
a0 NUMBER,
a1 NUMBER,
a2 VARCHAR2) IS
BEGIN
args := JNI.CREATE_ARG_LIST(3);
JNI.ADD_INT_ARG(args, a0);
JNI.ADD_INT_ARG(args, a1);
JNI.ADD_STRING_ARG(args, a2);
JNI.CALL_VOID_METHOD(FALSE, obj, 'UWWriteExcel', 'getCellValues', '(IILjava/lang/String;)V', args);
END;
-- Method: exportExcel ()V
PROCEDURE exportExcel(
obj ORA_JAVA.JOBJECT) IS
BEGIN
args := NULL;
JNI.CALL_VOID_METHOD(FALSE, obj, 'UWWriteExcel', 'exportExcel', '()V', args);
END;
-- Method: copy (Ljava/lang/String;Ljava/lang/String;)V
PROCEDURE copy(
a0 VARCHAR2,
a1 VARCHAR2) IS
BEGIN
args := JNI.CREATE_ARG_LIST(2);
JNI.ADD_STRING_ARG(args, a0);
JNI.ADD_STRING_ARG(args, a1);
JNI.CALL_VOID_METHOD(TRUE, NULL, 'UWWriteExcel', 'copy', '(Ljava/lang/String;Ljava/lang/String;)V', args);
END;
BEGIN
NULL;
END;
declare
obj ORA_JAVA.JOBJECT;
BEGIN
message('-1');pause;
obj:=UWWriteExcel.new;
message('0');pause;
UWWriteExcel.copyExcel(obj,'C:\\excel\\CAT2009WS.XLS','C:\\excel\\CAT2009WS.XLS');
message('1');pause;
UWWriteExcel.openSheet(obj,0);
message('2');pause;
UWWriteExcel.getCellValues(obj,6,2,900);
message('3');pause;
UWWriteExcel.getCellValues(obj,7,2,911);
message('4');pause;
UWWriteExcel.exportExcel(obj);
END;
When the size of XL is more than 7Mb, after message(0) it will be display oracle error.
From command prompt if we run the same java class file by passing -Xmx256m parameter we are able to write to big XL file.
Can anyone tell me where I am wrong... Can we increase the JVM Heap Size from forms...

I have a simular problem.
Via Forms I call a Java class (import Java class -> PL/SQL class java method).
For this specific process I need to set the Xmx java option...
How do I do this ?
Changing the java option for the Forms-OC4J in the EM doesn't help.
Is there an other level where I can modify this ?
Does the java process of the forms is the single process that exists ? How does he handles such java calls?
Are that separed java processes ? threads ? ....
Thanks !!!

DPS 6.x jvm memory heap size?

Similar Messages

Maybe you are looking for