<div dir="ltr">Hi Chris,<div><br></div><div> it depends... </div><div><br></div><div>First of all, 32-bit linux only provides 3Gb of address space to user processes, the upper quarter being used to map the kernel into the user's address space. Look at the stack pointer and you'll see it starts at 0xbfffxxxx, not 0xffffxxxx. Apparently there are ways around this but I can't find good references for this. e.g. this is an unhelpful page, talking about total system address space, not per-process address space: <a href="http://en.wikipedia.org/wiki/3_GB_barrier" target="_blank">http://en.wikipedia.org/wiki/3_GB_barrier</a>.</div><div><br></div><div>Second of all, the VM shares the address space with other components in the program, especially X11 which uses a lot of address space. Running headless should allow you to gro a little bit more.</div><div><br></div><div>In my recent experience on linux one can indeed start Cog V3 with about 1.9Gb. Spur can grow to about 2.9Gb. The V3 memory manager requires a contiguous heap, which forces preallocation. This is a serious problem, but one that Spur solves. Spur has a segmented memory model, and so can grow the heap dynamically. But the fundamental problem is that linux only provides 3Gb per process. So until one has a 64-bit Spur heap size will be limited to 2.9Gb or there abouts on linux.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Is this clear enough?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">For more, see my message announcing the availability of the 3018 VMs. From that message I wrote:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span class="Apple-style-span" style="border-collapse:collapse;font-family:arial,sans-serif;font-size:14px;color:rgb(0,0,0)"><div>Here's my test script:</div><div><div>| them |<br></div><div>them := OrderedCollection new.</div><div>[[them addLast: (ByteArray new: 16000000).</div><div> Transcript cr; print: (Smalltalk vmParameterAt: 3) / (1024*1024.0) maxDecimalPlaces: 1; flush] repeat]</div><div><span style="white-space:pre-wrap"> </span>on: OutOfMemory</div><div><span style="white-space:pre-wrap"> </span>do: [:ex| 2 to: them size by: 2 do: [:i| them at: i put: nil. Smalltalk garbageCollect]].</div><div>Transcript cr; print: (Smalltalk vmParameterAt: 3) / (1024*1024.0) maxDecimalPlaces: 1; flush.</div><div>them := nil.</div><div>Smalltalk garbageCollect.</div><div>Transcript cr; print: (Smalltalk vmParameterAt: 3) / (1024*1024.0) maxDecimalPlaces: 1; flush</div></div><div><br></div><div><br></div></span><div class="gmail_quote">On Thu, Sep 25, 2014 at 12:55 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have a need for an image larger than 2GB. Eliot, I thought I<br>
remember this subject coming up recently that, for Linux, the limit<br>
was increased to 3GB or 4GB or was I just dreaming? I can't seem to<br>
find the thread and my own experiements with -mmap seem to cap at<br>
2000m..<br>
<br>
Maybe it was a new Spur-specific capability?<br></blockquote><div> <br></div></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>