<div dir="ltr">Hi Tom,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 23, 2017 at 1:35 AM, Tom Beckmann <span dir="ltr"><<a href="mailto:tomjonabc@gmail.com" target="_blank">tomjonabc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Dear VM devs,<br><br>I'm trying to allocate a Bitmap of around 16MB size in a plugin via `interpreterProxy instantiateClass: interpreterProxy classBitmap indexableSize: size`.<br>However, I always get NULL back. I already tried wrapping the primitive call in `retryWithGC:until:`, with the same effect. Running a normal `Bitmap new: 16000000` from a workspace works flawlessly.<br><br>I'm on a Ubuntu 16.04 64bit, running a squeak 32bit built from trunk.<br><br>Is there anything to watch out for? More precisely, I'm trying to copy the contents of an image buffer generated from a pdf via libpoppler at 144dpi to a new bitmap in squeak. The primitive and how I invoke it can be seen here: <a href="https://pastebin.com/9NCdnx2J" target="_blank">https://pastebin.com/9NCdnx2J</a> (line 50 is the call in question)<br><br>Thanks in advance for any pointers!<br></div></blockquote><div><br></div><div>I want to endorse what Bert said; allocating in the image is a much better approach. But I did want to explain what you're seeing, assuming you're using Spur (Squeak 5.x, Pharo 6).</div><div><br></div><div>The Spur old space heap is segmented. It grows in increments defined by vm parameter 25 (Smalltalk vmParameterAt:[put:]), and shrinks whenever free memory is above parameter 24 and GC empties one or more segments. It will not grow memory beyond parameter 67, if that parameter is non-zero:</div><div><br></div><div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>24<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>memory threshold above which to shrink object memory (read-write)</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>25<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>memory headroom when growing object memory (read-write)</div></div><div></div></div><div class="gmail_extra"><span style="white-space:pre"> </span>67<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>the maximum allowed size of old space in bytes, 0 implies no internal limit (Spur only).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Parmeter 25 defaults to 16Mb (grow in increments of 16Mb) and 24 to 32 Mb (only shrink while 32Mb or more of empty segments exist).</div><div class="gmail_extra"><br></div>Currently memory will /only/ grow in these circumstances</div><div class="gmail_extra">- under image control via growMemoryByAtLeast:</div><div class="gmail_extra">- when scavenging tenures sufficient objects to old space that old space must grow</div><div class="gmail_extra">- when a fullGC fails to ensure there is at least vm parameter 25's worth of free space</div><div class="gmail_extra">- when an allObjects or allInstances primitive needs more room to answer its result</div><div class="gmail_extra"><br></div><div class="gmail_extra">The current allocator does /not/ try and grow memory in the allocation routines (which are accessed in plugins via <span style="color:rgb(0,0,0);font-size:12.800000190734863px">instantiateClass:indexableSize: and in the image via new: basicNew: et al), failing instead. This gives the image the chance to mediate GC and heap growth (see e.g. Behavior>>handleFailing[Failing]BasicNew:).</span></div><div class="gmail_extra"><font color="#000000"><span style="font-size:12.800000190734863px"><br></span></font></div><div class="gmail_extra"><font color="#000000"><span style="font-size:12.800000190734863px">Perhaps </span></font><span style="color:rgb(0,0,0);font-size:12.800000190734863px">instantiateClass:indexableSize: /should/ allow growth but I prefer it remaining the same. You would then rewrite your primitive to</span></div><div class="gmail_extra"><font color="#000000"><span style="font-size:12.800000190734863px">- when it fails to allocate memory via </span></font><span style="color:rgb(0,0,0);font-size:12.800000190734863px">instantiateClass:indexableSize: fail with interpreterProxy primitiveFailFor: PrimErrNoMemory</span></div><div class="gmail_extra"><font color="#000000"><span style="font-size:12.800000190734863px">- have the Smalltalk primitive failure code check the primitive error code (see senders of </span></font>primitive:module:error:) and if the failure code is #'insufficient object memory' grow memory by the necessary amount and retry the primitive (a la handleFailingBasicNew:)</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">To the general audience, I think information like the above is key to being able to understand and exploit the system effectively, but where should it reside? Clearly "in my head" is not satisfactory. It belongs somewhere in the image, but it needs to be somewhere where people can find it and/or will look. Suggestions for an "architectural information" documentation section gratefully received. Object class>>whatIsAPrimitive might perhaps work or perhaps be overloaded.</div><div class="gmail_extra"><br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>