| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Which background process regulates amount of pga memory per session in 10g ? Thanks, rm.
On Tue, 06 Sep 2005 16:50:57 +0000, xhoster wrote:
> Yes, that is my impression. When Java performs garbage collection, the
> freed up memory is available for reuse only by that JVM (or, if one process
> serves as both the JVM and something else, then it might also be reused by
> that something else, if things are arranged properly) and not by the system
> at large.
Your impression is correct. Frequent calls to system services, like sbrk,
will cause many context switches ("change mode to kernel" is,actually, a
context switch, all registers have to be saved and OS has to go through
the whole 9 yards) and would adversely affect the entire system. System
software is written with that in mind.
Java VM is an interpreter, similar to perl and is written with numerous
assumptions in mind. One of the most basic is "if memory was allocated
once, let's keep it and reuse it, if necessary". The trick is to use
mremap(2), to change the address mapping and temporarily hide those
addresses from the interpreter. Let me give you an example. Consider the
following script (not Java, but another, fairly portable language):
#!/usr/bin/perl
my %A;
print STDERR "Allocate a hash\n";
foreach $i (1..1000) {
$A{"$i"}='Test';
}
print STDERR "Clean up the mess\n";
foreach $i (keys %A) {
delete $A{$i};
}
Let's execute this as follows:
$ strace -o /tmp/calls.out -f /tmp/ttt
Allocate a hash
Clean up the mess
What is in the "calls.out"? Here it is:
.......
7798 read(3, "#!/usr/bin/perl \nmy %A;\nprint ST"..., 4096) = 180
7798 read(3, "", 4096) = 0 7798 close(3) = 0 7798 write(2, "Allocate a hash\n", 16) = 16 7798 brk(0x88b8000) = 0x88b8000 7798 write(2, "Clean up the mess\n", 18) = 18 7798 exit_group(0) = ?(END) There is only one allocation (brk) and no de-allocations. If the original hash is expanded to contain 1000000 entries instead of 1000, the situation looks a bit different. Now, we can see de-allocations done with the mremap, while the actual allocation (values from brk) is actually growing.
7806 write(2, "Clean up the mess\n", 18) = 18 7806 mmap2(NULL, 4198400, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb594c000
7806 brk(0xdb84000) = 0xdb84000 7806 brk(0xdbb0000) = 0xdbb0000 7806 brk(0xdbdb000) = 0xdbdb000 7806 brk(0xdc15000) = 0xdc15000 7806 brk(0xdbfc000) = 0xdbfc000 7806 brk(0xdc1f000) = 0xdc1f0007806 mmap2(NULL, 155648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5926000
7806 mremap(0xb5926000, 155648, 159744, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 159744, 159744, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 159744, 163840, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 163840, 163840, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 163840, 167936, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 167936, 167936, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 167936, 172032, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 172032, 172032, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 172032, 176128, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 176128, 176128, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 176128, 180224, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 180224, 180224, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 180224, 184320, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 184320, 184320, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 184320, 188416, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 188416, 188416, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 188416, 192512, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 192512, 192512, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 192512, 196608, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 196608, 196608, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 196608, 200704, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 200704, 200704, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 200704, 204800, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 204800, 204800, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 204800, 208896, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 208896, 208896, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 208896, 212992, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 212992, 212992, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 212992, 217088, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 217088, 217088, MREMAP_MAYMOVE) = 0xb58ff000 7806 brk(0xdc40000) = 0xdc40000 7806 mremap(0xb58ff000, 217088, 221184, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 221184, 221184, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 221184, 225280, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 225280, 225280, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 225280, 229376, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 229376, 229376, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 229376, 233472, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 233472, 233472, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 233472, 237568, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 237568, 237568, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 237568, 241664, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 241664, 241664, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 241664, 245760, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 245760, 245760, MREMAP_MAYMOVE) = 0xb58ff0007806 mremap(0xb58ff000, 245760, 249856, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 249856, 249856, MREMAP_MAYMOVE) = 0xb58ff000
7806 brk(0xdc61000) = 0xdc61000 7806 mremap(0xb58ff000, 249856, 253952, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 253952, 253952, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 253952, 258048, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 258048, 258048, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 258048, 262144, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 262144, 262144, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 262144, 266240, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 266240, 266240, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 266240, 270336, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 270336, 270336, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 270336, 274432, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 274432, 274432, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 274432, 278528, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 278528, 278528, MREMAP_MAYMOVE) = 0xb58ff0007806 mremap(0xb58ff000, 278528, 282624, MREMAP_MAYMOVE) = 0xb58ff000 7806 mremap(0xb58ff000, 282624, 282624, MREMAP_MAYMOVE) = 0xb58ff000
7806 brk(0xdc82000) = 0xdc82000
At the end of the day, the total number of allocation/deallocation calls is much smaller then the expected 2,000,000:
$ grep brk /tmp/calls.out|wc -l
770
$
The interpreter allocates memory in big blocks and only rarely returns it to the OS. As a general rule, what is once acquired is usually kept for re-use. Of course, this wasn't done with Java interpreter, but with one of generally much higher quality. I am certain that the conclusions will hold water for JavaVM as well, but as I don't know Java, I cannot test.
-- http://www.mgogala.comReceived on Sat Sep 10 2005 - 14:56:34 CDT
 |
 |