Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #20521
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: 32G ram |
| Date | 2012-12-19 07:19 -0600 |
| Organization | albasani.net |
| Message-ID | <kasf3c$5ma$1@news.albasani.net> (permalink) |
| References | (1 earlier) <50ce8cd7$0$287$14726298@news.sunsite.dk> <sa23q9-rkb.ln1@tempest.fredriksson.dy.fi> <ajaqpnFttk0U1@mid.individual.net> <50d116bd$0$281$14726298@news.sunsite.dk> <ajdmnjFja9oU1@mid.individual.net> |
On 12/19/2012 5:28 AM, Nigel Wade wrote: > On 19/12/12 01:22, Arne Vajhøj wrote: >> On 12/18/2012 4:19 AM, Nigel Wade wrote: >>> On 17/12/12 08:39, Donkey Hottie wrote: >>>> 17.12.2012 05:09, Arne Vajhøj kirjoitti: >>>>> On 12/16/2012 10:05 PM, mcheung63@gmail.com wrote: >>>>>> i got 32GB ram, why i can't -Xmx2G, it got an error "Could not >>>>>> create the Java Virtual Machine" >>>>>> >>>>>> /root>free -m >>>>>> total used free shared buffers >>>>>> cached >>>>>> Mem: 32387 16973 15413 0 243 >>>>>> 11906 >>>>>> -/+ buffers/cache: 4823 27563 >>>>>> Swap: 1906 0 1906 >>>>>> /root>uname -a >>>>>> Linux localhost.localdomain 3.6.9-2.fc17.i686.PAE #1 SMP Tue Dec 4 >>>>>> 14:15:28 UTC 2012 i686 i686 i386 GNU/Linux >>>>> >>>>> 32 bit or 64 bit Java? >>>> >>>> Apparently 32 bit, as the i686 OS is 32 bit PAE too. >>> >>> 32bit Java on 32bit Linux should allow an application of up to 4GB. How >>> much can of that can be allocated to the heap depends on the particular >>> application. I've allocated more than 2G to heap on a 32bit Linux >>> system, see this old thread on Google Groups: >>> https://groups.google.com/forum/?hl=en-GB&fromgroups=#!topic/comp.lang.java.programmer/iGr3bxL9ZCA >>> >>> >> >> 32 bit Java can in theory use up to 3 GB on 32 bit OS on x86 if the >> border between process and system is changed (/3GB). But on Windows >> JRocket is supposedly the only Java that can do it. > > Sorry, yes, I had confused myself by thinking about PAE. For normal > 32bit systems this is true. > it is also true of systems using PAE. there is a way to get around the 3GB limit though, but it actually involves a different strategy: swapping out the page tables on transitions to/from kernel space. big downside: this is kind of slow... >> >> 32 bit Java can never use 4 GB on 32 bit OS on x86, because that >> does not leave any address space for the OS. > > However, the OP is using a PAE kernel. That should theoretically allow a > per-process limit of 4GB. I've never had the chance to use PAE kernels > on PAE supported hardware, but IIRC that's what PAE is for, isn't it? > no, PAE does not expand the size of the virtual address space, only the physical address space (mostly via making page-table entries bigger, and adding another page-table level): 4kB / 8 = 512 (2^9) 9*3 + 12 = 39 but, the top-level is only partially filled (4 entries), so: 9+9+2 + 12 = 32 vs (non-PAE): 4kB / 4 = 1024 (2^10) 10+10 + 12 = 32 the reason for expanding the page-table entry size is mostly so that they can refer to more pages (more bits allowing a larger physical address space). it means essentially that you can have 36-bits (or more) for the physical RAM, but still only 4GB per-process (apart from using ugly bank-switching nastiness). given that the kernel still needs to map into a 4GB space, there is little change from before (leaving a full 4GB for the app requiring an address-space switch). PAE is partly involved in x86-64 though. more levels of page-tables may be used: 4kB / 8 = 512 (2^9) 9*4 + 12 = 48 9*5 + 12 = 57 note that the size of the external (physical) address bus is independent of the size of the supported virtual address space, and depends some on the processor. note that, while 64 bit page-table entries would theoretically allow up to a full 64 bit physical address... AMD shaved off some of the high-order bits for use for more flags (like the NX bit). hence, there is currently a limit here of 56 bits. not like we will likely be seeing this much RAM anywhere in the near future though...
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
32G ram mcheung63@gmail.com - 2012-12-16 19:05 -0800
Re: 32G ram Arne Vajhøj <arne@vajhoej.dk> - 2012-12-16 22:09 -0500
Re: 32G ram Donkey Hottie <donkey@fredriksson.dy.fi> - 2012-12-17 10:39 +0200
Re: 32G ram Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 17:37 -0500
Re: 32G ram Lew <lewbloch@gmail.com> - 2012-12-17 15:38 -0800
Re: 32G ram Nigel Wade <nmw@ion.le.ac.uk> - 2012-12-18 09:19 +0000
Re: 32G ram BGB <cr88192@hotmail.com> - 2012-12-18 14:57 -0600
Re: 32G ram Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:22 -0500
Re: 32G ram Nigel Wade <nmw@ion.le.ac.uk> - 2012-12-19 11:28 +0000
Re: 32G ram BGB <cr88192@hotmail.com> - 2012-12-19 07:19 -0600
Re: 32G ram Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 09:17 -0500
Re: 32G ram Tim Slattery <Slattery_T@bls.gov> - 2012-12-19 12:51 -0500
Re: 32G ram Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 13:20 -0500
Re: 32G ram BGB <cr88192@hotmail.com> - 2012-12-19 12:40 -0600
Re: 32G ram Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 13:56 -0500
Re: 32G ram Roedy Green <see_website@mindprod.com.invalid> - 2012-12-17 00:31 -0800
Re: 32G ram Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 20:37 -0500
Re: 32G ram Sven Köhler <remove-sven.koehler@gmail.com> - 2012-12-19 20:40 +0100
csiph-web