Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sun, 28 Oct 2007 11:36:34 -0400 Nathan Meyers <[hidden email]> wrote: > The heap load I mention is an artifact of pointer size - "some extra > memory" can add up. I have a dual-boot box with 32- and 64-bit Gentoo > installations. The 64-bit is mainly for smoke testing - with 1G of > physical memory, it's not really worth much :-). But I can tell you that > some memory-intensive Java activities that manage to fit in physical > memory in 32 bits send the system into paging hell in 64 bits. I'm > certainly not disputing the value of a 64-bit address space, just > pointing out that it adds costs of its own. This is true. Since pointers are 64-bits in 64-bit models (LP64) that can increase memory. There are some other additional memory issues, as I alluded to, such as fillers or holes. C, C++ and other systems align objects on natural boundaries. Pointers and long integers must align to 64-bits. In a 32-bit system, these align on 32-bit boundaries. Structures also align on these boundaries. Different JVMs tend to manage memory differently. In Tru64 Linux, our teams rewrote the memory manager because the default Sun memory manager was inefficient, at least in a 64-bit model. You probably can use a 32-bit JVM on a 64-bit x86-64 system, but I can't confirm that. -- Jerry Feldman <[hidden email]> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |