<div dir="auto"><div><span style="font-family:sans-serif">Clément,</span><br><div class="gmail_extra"><br><div class="gmail_quote">On Oct 11, 2017 4:09 AM, "Clément Bera" <<a href="mailto:bera.clement@gmail.com">bera.clement@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr">Hi,<div><br></div><div>Without a way to reproduce, it is difficult to deal with the problem.</div><div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I managed to get a reproducible example... Will post details shortly.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I had reports also from the Pharo community with some problems when scaling up, but it seems most of that noise is gone since Spur has a new compactor. There are still some issues, such as GC pauses, that we are trying to deal with. I wrote this post <a href="https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/" target="_blank">here</a> to help people dealing with larger images (couple Gbs). There are things that you can change from the image, with the vm parameters, that are recommended for larger images. For example in Java for a couple Gb heap the VM scales up automatically young space size to 200Mb, in our case the default is set to 4Mb and you need to use vm parameters to set it up. </div><div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Funny you mention that post as it might have some bearing on the issue 😀</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>The thing with an image-side exception is that it will execute additional code and allocate new objects. To do that, we need first to deal with the problem. For example we could do a scavenge to try to decrease the number of RT entries, but maybe the overflow happened in a specific execution state where a scavenge is not possible. The command line error messages don't have this kind of problems. We could try to do something along those lines but it is not that simple.</div><div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">What I had in mind was something along the lines of an optional check *before* hitting an absolute resource limit that would raise an exception.</div><div dir="auto"><br></div><div dir="auto">For example, let's say we had:</div><div dir="auto">Smalltalk vmParameterAt: X put: 95. "A VM parameter which doesn't currently exist accepting a small int in the range of 0-99 where 0 represents don't warn and any other value represents the warning threshold as a percentage.  Just to keep things simple, use a single setting as the warning threshold for all scare resources that we know the upper bounds for"</div><div dir="auto"><br></div><div dir="auto">So at some point you run some code that crosses threshold for some scarce/fixed resource... maybe it's stack pages, maybe semaphores.. whatever.  Then the VM could raise a VMThresholdExceeded exception (or whatever it made sense to call it) in the process that triggered it with a message string indicating what limit got hit.  This would most likely need to be a resettable one-shot trigger to be useful (I.e. to ensure that it doesn't trigger a cascade of exceptions).  That would be a much nicer troubleshooting starting point than a stack trace at the command line.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards,</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 10, 2017 at 9:58 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="auto"><div><span style="font-family:sans-serif">Clément,</span></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">Thanks for the info.  This is a Spur image.  Unfortunately it has some sensitive information so I'll have to see if I can reproduce the issue in one I can share.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">On a related note, I seem to be running into more of these kinds of VM issues as I'm attempting to scale up my image sizes (I can only imagine the fun I'll be having with multi GB images) and am thinking it would be helpful if the VM had the ability (even if it requires some sort of debug build) to raise an exception in the image when a fixed resource exceeded X% of it's maximum value.  Has a capability along those lines been considered?</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">Thanks,</font></div><div dir="auto"><font face="sans-serif">Phil<br></font><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Oct 10, 2017 1:12 AM, "Clément Bera" <<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_-2924436820571376663gmail-m_7531201594848998947m_4692957519215618769quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-2924436820571376663gmail_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.<wbr>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></div>
<br></blockquote></div><br></div></div></div>