<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 15, 2017 at 8:35 AM, Ryan Macnak <span dir="ltr"><<a href="mailto:rmacnak@gmail.com" target="_blank">rmacnak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div dir="auto">Why is filling the remembered set fatal? It's possible to empty the remembered set by promoting everything in new space.</div><div class="gmail_extra"><br></div></div></blockquote><div>Usually we do a tenure to shrink the remembered table. Normally it should not be fatal. It's a bug.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Oct 9, 2017 10:12 PM, "Clément Bera" <<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_5146475749948283158m_5211357176391306754quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi,<div><br></div><div>This is another limit than the out of memory error. Too many references from old objects to young objects. The limit cannot be changed directly from the image. However, if using Spur, you can try to change the young space size, which also changes the remembered table size and might fix your problem. To do so you can do:</div><div><font face="monospace, monospace">Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4.</font> And then <b>restart the image.</b><div>Check <a href="https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/" target="_blank">here</a> section TUNING NEW SPACE SIZE for more info about that.</div></div><div><br></div><div>If you are using Spur, could you send us the image (if it is 500Mb could you put it to download on dropbox or something like that ?) ? That way we can reproduce and see what is possible. Normally in Spur if the remembered table grows too big a tenure to shrink the remembered table happens, so that error should not happen. Eliot is currently moving to another place, so he might be busy. If he is available to answer, I guess he will have a look, if he is not, I can have a look today or thursday. However I am not interested in fixing pre-Spur VMs.</div><div><br></div><div>Regards,</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 9, 2017 at 11:57 PM, Phil B <span dir="ltr"><<a href="mailto:pbpublist@gmail.com" target="_blank">pbpublist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="auto">Is this effectively an out of memory error or am I hitting some other internal VM limit?  (I.e. can the limit be increased or is  it a hard limit?) I'm running into this when using the reference finder tool in a Cuis image.  (It's a moderately large image at ~500 meg)</div>
<br></blockquote></div><br></div>
<br></blockquote></div><br></div>
</div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="font-size:12.8px">Clément Béra</span><div style="font-size:12.8px">Pharo consortium engineer</div><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.com/</a><br></div><div style="font-size:12.8px"><span style="line-height:16px">Bâtiment B 40, avenue Halley 59650 </span><span style="font-weight:bold;line-height:16px">Villeneuve d'Ascq</span></div></div></div>
</div></div>