<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-05-08 11:31 GMT+02:00 Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>On 08.05.2015, at 08:43, Norbert Hartl <<a href="mailto:norbert@hartl.name">norbert@hartl.name</a>> wrote:<br>
> I would assume that an object needs to stay connected 60 seconds until it gets tenured. But all of the objects in the request don't live that long.<br>
<br>
The object memory does not track how long an object was alive, or even how many incremental GCs it survived. Once the tenuring threshold is reached (after X allocations), all objects alive in new space at that point get tenured.<br>
<br>
This is how it worked before Spur, anyway. Not sure what the tenuring policy is in Spur?<br>
<br></blockquote><div>As far as I understood (Eliot correct me if I am wrong): </div><div><br></div><div>In spur, when scavenging, if an object survives and has already survived a certain number of scavenges (I think currently 5), it is tenured instead of being moved to the future survivor space.</div><div><br></div><div>In addition, when scavenging, if the future survivor space gets almost full (I think currently at least 90% full), all objects surviving the current scavenge, starting from the point where the new survivor space reached the limit, are tenured.</div><div><br></div><div>So the policy depends on the number of scavenges survived by the object and the overall number of objects surviving the scavenges.</div><div><br></div><div>I don't know though how many objects will make it to the old space in your requests, but most probably less than currently.</div><div><br></div><div>Clement</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Bert -<br>
<br>
<br></blockquote></div><br></div></div>