<div dir="ltr"><div>Thanks, Carl. </div><div><br></div>This bit of code certainly exhibits the surprising property that some runs unpredictably stall for a very long time. Further, it seems that this stall time can be made arbitrarily large by increasing the number of nodes generated (== more data in the old generation == more stuff to traverse if lots of garbage is generated and survives the young generation?). As a user of an incremental garbage collector, I would expect that there are pauses due to GC, but that these are predictable and small. <div>
<br></div><div>I tried running </div><div><br></div><div><font face="courier new, monospace">PYPY_GC_NURSERY=2000M pypy ./mem.py 10000000</font></div><div><br></div><div>but that seemed to have no effect. </div><div><br></div>
<div>I'm looking forward to the results of the Software Transactional Memory, btw :)</div><div><br></div><div>/Martin</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 9:47 AM, Carl Friedrich Bolz <span dir="ltr"><<a href="mailto:cfbolz@gmx.de" target="_blank">cfbolz@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 17/03/14 20:04, Martin Koch wrote:<br>
> Well, it would appear that we have the problem because we're generating<br>
> a lot of garbage in the young generation, just like we're doing in the<br>
> example we've been studying here.<br>
<br>
</div>No, I think it's because your generating a lot of garbage in the *old*<br>
generation. Meaning objects which survive one minor collection but then<br>
die.<br>
<div class=""><br>
> I'm unsure how we can avoid that in<br>
> our real implementation. Can we force gc of the young generation? Either<br>
> by gc.collect() or implcitly somehow (does the gc e.g. kick in across<br>
> function calls?).<br>
<br>
</div>That would make matters worse, because increasing the frequency of<br>
minor collects means *more* objects get moved to the old generation<br>
(where they cause problems). So indeed, maybe in your case making the<br>
new generation bigger might help. This can be done using<br>
PYPY_GC_NURSERY, I think (nursery is the space reserved for young<br>
objects). The risk is that minor collections become unreasonably slow.<br>
<br>
Anyway, if the example code you gave us also shows the problem I think<br>
we should eventually look into it. It's not really fair to say "but<br>
you're allocating too much!" to explain why the GC takes a lot of time.<br>
<br>
Cheers,<br>
<br>
Carl Friedrich<br>
_______________________________________________<br>
pypy-dev mailing list<br>
<a href="mailto:pypy-dev@python.org">pypy-dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/pypy-dev" target="_blank">https://mail.python.org/mailman/listinfo/pypy-dev</a><br>
</blockquote></div><br></div>