Re: Better introspection for Frames, Thread, and enhancing binding.

Ryan Davis wrote:
> 
> On Dec 2, 2007, at 21:18 , Charles Oliver Nutter wrote:
> 
>> Ryan Davis wrote:
>>> On Dec 2, 2007, at 09:57 , Charles Oliver Nutter wrote:
>>>> Exposing call frames, scoping constructs, and so on prevents any 
>>>> implementation from minimizing or optimizing frames away.
>>> That's simply not true. Look at self, smalltalk, and many lisps for 
>>> counter-examples.
>>
>> Perhaps you could provide links to a concrete example showing those 
>> languages performing better than those that don't expose frames? Or 
>> demonstrate to me how user-level frame objects could be exposed in 
>> Ruby without a performance hit? Last time I checked, none of those 
>> languages were Ruby, and none were the fastest languages around. 
>> Faster than Ruby isn't the point, many things are faster than Ruby. 
>> But always-present frame objects will absolutely introduce overhead 
>> that wouldn't be there without them or if an optimizer has freedom to 
>> remove or omit them.
> 
> I'm pretty sure you can google with the best of them.
> 
> You made a claim that exposing call frames etc prevents _any_ 
> implementation from minimizing or optimizing frames away and I pointed 
> you to specific counter examples. I never said anything about 
> "always-present frame objects" and I never made a claim about "faster 
> than ruby" or "without a performance hit". Please don't put words in my 
> mouth or use these points as a straw man. None of them are relevant to 
> your original point or my counter-examples.

The point is, if user code can expect to grab a frame object at any 
time, you have to be prepared to present one and manage its lifecycle 
along with userspace objects. In languages where you can't access 
frames, you don't have that worry, and you are free to manage call 
information any way you see fit. Regardless of how many papers you point 
me toward, there's an immutable truth here: you can't omit something 
user code may expect in the unforeseeable future.

The exception I'll agree to is for JITting languages that run for a long 
  time before optimizing, which gives them the opportunity to detect 
whether frame objects will be needed in the code they're running. But 
even that runtime inspection has its limits when arbitrary code can be 
introduced with eval and friends. Perhaps it's better to say that 
user-level frame objects in the context of Ruby's feature set will 
introduce overhead, so neither of us has to hand-wave over this 
googlable paper or that.

eval is actually a good example of how to totally confound optimization, 
and in JRuby the presence of eval disables almost all optimizations.

> Self, given only one implementation (that I know of) should be concrete 
> enough. There are a lot of papers that came from Ungar, Chambers, and 
> cohorts that are readily available on the net or with an ACM digital 
> library membership. Ungar's SOAR is probably also a good source, tho I'm 
> not at home so I don't know if frame optimizations made it into SOAR or 
> not.

And since people seem to be unclear about my point, I'll state it directly:

Frame objects are a nice feature, and not particularly hard to support; 
but the availability of frame objects exposes details about a language 
or VM's implementation that complicate or make impossible certain 
optimizations. You can't have all things at once.

If Ruby exposes frame objects, JRuby will support it, as I said before.

- Charlie