hello,

my situation:
SUSE 2.6.5-7.155.29-bigsmp
PAE enabled: cpu flags : fpu vme de pse tsc msr pae
no limit on user: virtual memory (kbytes, -v) unlimited
15Gb RAM (physical)
Mem: 14967976 (from free command).

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 4194303
max total shared memory (kbytes) = 13500000
min seg size (bytes) = 1

THEN
=================

1)the c program: malloc about 3.6Gb RAM. GREAT!
2)java -Xmx1950m is OK; WHILE from
3)java -Xmx1960m says
*** panic: JVMST062: Cannot allocate memory in initializeFRBits()

how can i increase contiguous mem size? (if this is the problem...)

any help!?!?!

r
michelangelo

That isn't all the CPU flags.

Do you really not have the lm flag or do you have some other reason to not switch to a 64 bit build of Linux?

Are you sure?

That means you have the build of Linux that I think is called "Hugemem" by old versions of RHEL that included it, that has kernel virtual memory separate from user virtual memory. That has a lot of overhead compared to a 64 bit build. That is a bad idea if you have a choice.

How high do you want to go?

I don't know Java memory issues, so maybe there is a fix for that problem and still fit in 32 bit virtual memory. But if you want to go far beyond that, you may need 64 bit.

Just to be clear - these are independent runs ?. The first just to very how much you can allocate, then the other two to show th point at which the error occurs ?.
If all that is true, try doing the last command immediately after a re-boot to get an indication if it is a contiguous problem.

The issue is contiguous virtual address space within the process started by that java command.

Having less than 2GB contiguous at startup seems a little strange, but it isn't implausible.

When you start java successfully with java -Xmx1950m do you do something to make that process stay around (preferably waiting for input or other event)? If so, you can find out its pid and the look in /proc/pid/maps to see the detailed layout of virtual memory. After the big chunk allocated for the heap there must be some other mappings (probably .so files) that fragment the virtual address space preventing a larger contiguous mapping. There are methods (I don't recall them, but they exist) to control the load address of all the .so files and maybe whatever else gets in before that contiguous mapping is attempted. You should be able to get everything that now loads near the middle of the 3 or 3.6 GB virtual space to load near the beginning or near the end.

Since it is the virtual address space of a new process created by the java command, not anything that needs to be physically contiguous, trying it right after a reboot should make no difference.

I'm not 100% sure about the rules for virtual load address of .so files. If a .so file is already loaded by something at some address convenient to the first process that loaded it, there would be some performance advantage to loading it at the same virtual address in another process that subsequently needs it, assuming that virtual address is available. I don't know whether Linux does that kind of optimization. If it does then use of some .so before the java command might influence the virtual layout and maybe your reboot idea could have some useful effect. But I'm not sure that is possible and if it is possible it is still a difficult indirect blind approach to an issue that can be viewed directly by looking in the process maps and then attacked directly.