<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Clément,</div><div><br>On Apr 24, 2015, at 1:19 AM, Clément Bera <<a href="mailto:bera.clement@gmail.com">bera.clement@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr">I think what you want Eliot is not necessarily related to frameless methods.<div><br></div><div>I think what you want is that if there are several storeChecks in the same object in-between two interrupt points, which could be several inst var store or several inlined at: put: on the same object, you want to merge the storeCheck logic so it's done in one place instead of multiple.</div><div><br></div><div>In the case of frameless methods, there are no interrupt points, so it works for the whole method. However, I don't see why the technique would not apply if you write code such as:</div><div><br></div><div>foo: arg1</div><div> "any code here that may include sends or anything"</div><div> instVar1 := 1.</div><div> instVar2 := arg1.</div><div> instVar3 := #bar.</div><div> "any code here that may include sends or anything"</div><div><br></div><div>In this case you can merge the store check for the 3 inst var as it's done in between two interrupt points.</div><div><br></div><div>Currently, for each instVar store, the process is:</div><div>- is the value stored a immediate ?</div><div>- is the object holding the instVar young ?</div><div>- is the value stored old ?</div><div>- is the object holding the instVar already remembered ?</div><div>If all 4 are false, the object holding the instVar needs to be added in the remembered table.</div><div><br></div><div>And I guess the 2 tests on the object holding the inst var, 2 out of 4, could be done only once.</div><div><br></div><div>In the future I guess that the write barrier will be more important because of the tricolor marking GC. As far as I understood, we'll have to check in addition if the object and the value are not black & white or white & black, in which case we need to color one of the operands to gray. So I guess an improvement there may be valuable.</div></div></div></blockquote><div><br></div><div><br></div>True, but I thought it would be harder for the Cogit to notice in the general case. I think I'm wrong. But the <span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">Cogit would have to look ahead whenever it saw an inst var write to look for immediately following writes and then generate the specialized sequence. Indeed that would be better. So the challenge is to share the store check amongst any number of consequent inst var stores.</span><div><br></div><div><br><blockquote type="cite"><div><div dir="ltr"><div>2015-04-24 8:05 GMT+02:00 stephane ducasse <span dir="ltr"><<a href="mailto:stephane.ducasse@gmail.com" target="_blank">stephane.ducasse@gmail.com</a>></span>:</div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi eliot<br>
<br>
<br>
> Hi All,<br>
><br>
> here's a challenge. Currently the JIT is naive about a sequence of inst var assignments. It treats assignment separately, each getting its own copy of the store check. For example when initializing an Interval via:<br>
><br>
> setFrom: startInteger to: stopInteger by: stepInteger<br>
><br>
> start := startInteger.<br>
> stop := stopInteger.<br>
> step := stepInteger<br>
<br>
<br>
Is this pattern frequent?<br>
Because it was proposed by K. Beck but do people use it?<br>
Especially now with automatic invocation of initialize, we often have<br>
<br>
start := startInteger.<br>
> stop := stopInteger.<br>
> step := stepInteger<br>
self do.</blockquote></div><br></div>
</div></blockquote></div></body></html>