Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #20521

Re: 32G ram

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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