------ art_1834_29004918.1198290504493 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Dec 21, 2007 8:56 PM, Charles Oliver Nutter <charles.nutter / sun.com> wrote: > Rocky Bernstein wrote: > > I asked (or at least alluded to) this following question a while ago > > under the discussion of giving access to frames (even if at only the C > > API) at run time. I don't recall an answer. Given the above, how is > > caller() implemented in JRuby when procedures are expanded in-line? > > Actually, I have the same question for YARV in the face of > > tail-recursion removal? (I read somewhere on the net that 1.9 has > > tail recursion removal.) > > Currently we do not optimize away call frame information in most cases, Most cases? You wrote before Exposing call frames, scoping constructs, and so on prevents any implementation from minimizing or optimizing frames away. Many of the fastest language implementations and VMs (like the JVM, JRuby, and I believe Ruby 1.9) get that way because frames are not exposed and they can optimize them in different ways. which gave me the impression that "optimizing frames away" was important for JRuby. Nevertheless, unless this is the case that it can *never* happen when caller() is used, what in fact happens now? Personally, I don't see anything wrong clarifying the explanation of caller() to mean that it gives reports the frames it sees is currently there if that's in fact what's going on in the YARV and JRuby implementations. The other alternative of course is to have these implementations try to support caller as though no frames were removed. (N.B. David Flanagan, David Black, Dave Thomas and other Ruby 1.8/1.9 book authors might want to note of the answer :-) ------ art_1834_29004918.1198290504493 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <br><div class mail_quote">On Dec 21, 2007 8:56 PM, Charles Oliver Nutter <<a href ailto:charles.nutter / sun.com">charles.nutter / sun.com</a>> wrote:<br><blockquote class mail_quote" style order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class h2E3d">Rocky Bernstein wrote:<br>> I asked (or at least alluded to) this following question a while ago<br>> under the discussion of giving access to frames (even if at only the C<br>> API) at run time. I don't recall an answer. Given the above, how is <br>> caller() implemented in JRuby when procedures are expanded in-line?<br>> Actually, I have the same question for YARV in the face of<br>> tail-recursion removal? (I read somewhere on the net that 1.9 has <br>> tail recursion removal.)<br><br></div>Currently we do not optimize away call frame information in most cases,</blockquote><div><br>Most cases? You wrote before<br><pre>Exposing call frames, scoping constructs, and so on prevents any <br>implementation from minimizing or optimizing frames away. Many of the<br>fastest language implementations and VMs (like the JVM, JRuby, and I<br>believe Ruby 1.9) get that way because frames are not exposed and they<br> can optimize them in different ways. <br><br></pre>which gave me the impression that "optimizing frames away" was important for JRuby. <br><br>Nevertheless, unless this is the case that it can <i>never</i> happen when caller() is used, what in fact happens now? <br><br>Personally, I don't see anything wrong clarifying the explanation of caller() to mean that it gives reports the frames it sees is currently there if that's in fact what's going on in the YARV and JRuby implementations. The other alternative of course is to have these implementations try to support caller as though no frames were removed. <br><br>(N.B. David Flanagan, David Black, Dave Thomas and other Ruby 1.8/1.9 book authors might want to note of the answer :-)<br></div></div><br> ------ art_1834_29004918.1198290504493--