<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Feb 2015, at 18:07, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" class="">eliot.miranda@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">On Feb 23, 2015, at 7:50 AM, Thierry Goubier <<a href="mailto:thierry.goubier@gmail.com" class="">thierry.goubier@gmail.com</a>> wrote:</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2015-02-23 16:36 GMT+01:00 Eliot Miranda <span dir="ltr" class=""><<a href="mailto:eliot.miranda@gmail.com" target="_blank" class="">eliot.miranda@gmail.com</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Thierry,<br class="">
<br class="">
there's an unadvertised primitive called Context>>#xRay (or ContextPart>>#xRay) that answers these questions for tests. I'm away from the system right now but I'll get you the source soon. Also, the limit on jutting methods, 60 literals, is a default. There's a command line option -maxcoglits (IIRC) that you can change.<br class=""></blockquote><div class=""><br class=""></div><div class="">Thanks Eliot!<br class=""><br class=""></div><div class="">It's helping a lot to guide me, even if I have to work at the ast level and, as a result, I estimate the number of literals in the bytecode by counting the number of literal nodes in the AST, with the approximation that ~100 literal nodes will make it under the limit.<br class=""><br class=""></div><div class="">Making it under the limit shaves 30% of the execution time of a parse with SmaCC. And it avoids the too long methods as a side benefit.<br class=""><br class=""></div><div class="">I would dream of having precise ways of estimating things like that on the AST. It's interesting to hit those "I'd like to be able to predict the performance of that piece of code" issues.<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div>Alas two things other than the AST affect the number of literals. First is the specialSelectors; these are used for sends only. So if a method only sends one of the special selectors the selector will not occur in the method as a literal. Second is the bytecode set. While we only have one set now, Sista is introducing another, and Newspeak has its own. In the current set, -1, 0, 1 & 2 and true and false have bytecodes to push these literals, so they don't occur as literals in methods. In both 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); " class="">Sista</span> and 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); " class="">Newspeak sets there are bytecodes that encode a much wider range of integers and characters as bytecodes (a push literal bytecode takes 1 byte for the bytecode and 4 or 8 bytes for the literal; a bytecode for the 16-bit integer range takes 3 bytes). </span><div class=""><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);" class=""><br class=""></span></div><div class=""><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);" class="">Another thing that affects the number of literals is the compiler's decision to include selectors for optimized methods such as ifTrue: et al (which I think is a very good thing).</span></div><div class=""><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);" class=""><br class=""></span></div><div class=""><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);" class="">If you could ask the back end which literal would be encoded as a literal (and if course the question is asked when bytecode is generated) you could get a more accurate count.</span></div><div class=""><br class=""></div></div></div></blockquote><br class=""></div><div>Another thing that we use the literal array for is (will be) meta object… if you annotate an AST node or variable with a MetaLink, it stores that in the literal array.</div><div><br class=""></div><div>For example:</div><div><br class=""></div><div>link := MetaLink new</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>metaObject: Halt;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>selector: #now.</div><div><br class=""></div><div>then installing this on some AST node (or Slot) will lead to bytecode like</div><div><br class=""></div><div>...</div><div>pushLiteral: Halt</div><div>send: #now</div><div>...</div><div><br class=""></div><div><br class=""></div><div>This means that the meta object is stored in the literal frame of the compiledMethod (the Link itself is just an annotation on the structural element).</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Marcus</div><br class=""></body></html>