Windows 7 and all my Java stuff.
in [Java Programming]
|
From: Lew on 25 Nov 2009 14:19 According to Lew : >> I'm aware of no 32b JVM that can specify a heap over about 1.8 GB; >> most are lower. > Thomas Pornin wrote: > Sun's JVM can. Right now, with Sun's JDK 1.6.0_16, 32-bit version for > Linux, I can specify a 3.68 GB heap with '-Xmx3683m', and use it > (I made a simple Java code which successfully stored 3683 byte[], > each newly allocated of size 1048576, into an ArrayList). > > The trick here is that while the JDK is a 32-bit binary and runs > in a 32-bit system, the Linux kernel itself is a 64-bit kernel. The > Right to both of you. I should have specified that I meant a 32b JVM on a 32b OS. My mistake. -- Lew
From: Peter Duniho on 25 Nov 2009 14:52 Thomas Pornin wrote: > [...] When the kernel itself is a 64-bit kernel, > it can map the full 32-bit address space (4 GB) twice in its own, > much wider 64-bit address space; hence, application may then have > their (almost) full complement of 4 GB. > > As far as I know, this is also what happens when a 64-bit Windows > system runs a 32-bit application. I believe with would only happen for Windows applications marked as "LARGEADDRESSAWARE". Unfortunately, there are application developers out there who take an implementation detail like "all of your allocations will return an address from 0 to 2^31-1" and stick dependencies on that detail into their code. So Windows can't by default start handing out addresses in the upper 2GB of the 4GB address space, lest those applications stop working. But yes, with the "LARGEADDRESSAWARE" switch enabled for an executable, on 64-bit Windows, the OS can provide all of the 4GB address space a 32-bit application could theoretically use to that application, because it no longer needs any of the application's lower 4GB of 64-bit address space (the portion the 32-bit code can address) for its own needs. Pete
From: Peter Duniho on 25 Nov 2009 15:00 DuncanIdaho wrote: > [...] > Anyway, it will be interesting to see just how big the heap can be with > a 64bit JVM running on a 64bit system. Roll on delivery day. It will probably depend on the OS. But, for Windows and based on this MSDN article (http://support.microsoft.com/default.aspx?scid=889654), I would expect your 64-bit JVM process to max out at 8 terabytes (or just under), the maximum virtual address space for a 64-bit process on Windows. It's interesting to note that 64-bit Windows has essentially the same "half and half" virtual address space approach 32-bit Windows does. It's just that the numbers are bigger (16TB virtual address space, where 8TB is dedicated to the application). Anyway, with a theoretical 8TB limit on application allocations, unless you have some really huge disk or RAID volume, you'll run out of disk space before you can hit the actual theoretical limit. That is, observed behavior will be configuration-dependent. (But that's just for Windows...my understanding is that with most versions of Linux, for example, it will happily allow you to allocate as much memory is theoretically possible for the process, and only fail due to lack of system resources if your process actually tries to use the allocated memory). Pete
From: Thomas Pornin on 25 Nov 2009 16:31 According to Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com>: > my understanding is that with most versions of Linux, for example, it > will happily allow you to allocate as much memory is theoretically > possible for the process, and only fail due to lack of system > resources if your process actually tries to use the allocated memory It is called "overcommit". Any Linux from the last ten years or so can be configured to overcommit memory as you describe, but default behaviour on most Linux distributions is not to overcommit. Check the contents of /proc/sys/vm/overcommit_memory: if that's a 0, then you are not overcommitting. A very large FTP site from last century, called ftp.cdrom.com (yeah, that was before the DVD, when CDROMs where the quintessential hugeness) saw its maximum number of concurrently connected clients drop from 3000 to 700 when it switched OS, because the new OS did not overcommit by default, whereas the old one was overcommitting (the FTP server allocated much more RAM per connected client than what it was actually using). Hence there are situations where overcommitting is good. However, the notion of overcommit tends to trigger irrational prophecies of doom, hence it is deactivated by default. For most people, oveercommitting makes no difference whatsoever: in order to hit the point where an overcommitted page turns out not to be present, one must first exhaust the whole swap space, a slow and painful process, especially for a desktop system, in a typical configuration. To sum up, overcommit is there but not used by default, and it does not usually matter anyway. --Thomas Pornin
From: Nigel Wade on 26 Nov 2009 04:13
On Wed, 25 Nov 2009 11:19:21 -0800, Lew wrote: > According to Lew : >>> I'm aware of no 32b JVM that can specify a heap over about 1.8 GB; >>> most are lower. >> >> > Thomas Pornin wrote: >> Sun's JVM can. Right now, with Sun's JDK 1.6.0_16, 32-bit version for >> Linux, I can specify a 3.68 GB heap with '-Xmx3683m', and use it (I >> made a simple Java code which successfully stored 3683 byte[], each >> newly allocated of size 1048576, into an ArrayList). >> >> The trick here is that while the JDK is a 32-bit binary and runs in a >> 32-bit system, the Linux kernel itself is a 64-bit kernel. The >> >> > Right to both of you. I should have specified that I meant a 32b JVM on > a 32b OS. My mistake. Ok, on a 32bit machine: $ java -Xmx2700m ParseTime Thu Jan 01 08:00:00 GMT 1970 .... $ java -Xmx2800m ParseTime Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. So, here I'm limited to 2.7GB on a stock openSUSE desktop with 3GB RAM and 4GB swap, running: $ java -version java version "1.6.0_15" I thought you used Linux. What distro and memory configuration has limited you to 1.8GB? -- Nigel Wade |