-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mikolaj,
On 12/1/11 6:38 AM, Mikolaj Rydzewski wrote: > On Thu, 1 Dec 2011 12:29:14 +0100, Casper Wandahl Schmidt wrote: > >> That didn't quite help me understand, because how can the OS map >> from ie. 0-4GB to 4-8GB (the window is moved) when it can only >> use a 32bit register to tell the machine where to look in the >> psysical memory, that is where my knowledge ends :) So I read >> about PAE and found out that it uses 2 registers (36 bits due to >> some bits being used as flags) and that makes good sense, but how >> can the cpu calculate an address without overflow and send a >> command to the bus containing a 36bit address (or whatever >> fetches the bits from RAM)? That is where I'm puzzled but I guess >> it is because I'm not at all into ISA-level and below :) > > Well, it's rather out of the scope of this list. > > On the other hand, increasing java heap size is not always the > best option. It heavily depends on memory usage pattern in your > application. In general: the bigger heap, the longer GC will run. That's a rather sweeping generalization. The heap size doesn't matter directly.. it's the number of objects being managed within that heap that matters. Of course, with a larger heap, you can fit more objects into it before a major collection is required. Generational heap strategies are fairly efficient, and performance depends upon the number of LIVE objects, not just the total number of objects. Oddly enough, most "garbage collection" is really collecting non-garbage and ignoring the actual garbage. It's a bit like moving to a different house when yours gets too cluttered: you just take the things you want to keep and leave everything else behind. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7YK88ACgkQ9CaO5/Lv0PDzdACgmYJEuWHFNkFyEVWRcucJo4Yu 6uwAoK2JWcjX0SRY6PPIWwd1m7Fhx+f8 =XY04 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
