A better solution for artificial call frames?
Charles Oliver Nutter
talking with the Jython guys it's becoming more and more apparent that
non-JVM-based languages ported to JVM are always incurring a lot of
framing cost.
In JRuby, we need to allocate frames to present a Ruby stack trace
through interpreted code, as well as to hold per-call metadata that must
be present across e.g. closure calls. In Jython, the situation is worse,
since almost all Python-based debugging tools directly inspect the call
stack. IronPython (used to?) omit frame objects entirely in an attempt
to improve performance. And JRuby has an optional property you can set
to turn off Ruby framing, resulting in performance improving substantially.
It seems like something's missing here.
In addition to the ability to attach arbitrary runtime metadata to a
given class, it seems like several of the languages we want to support
on JVM could benefit from efficient mechanisms for attaching metadata to
Java threads and call frames.
I know in JRuby, the ability to tag a given call frame as a "Ruby frame"
would solve almost all use cases for frame objects in JRuby. For Jython,
I expect they might have to attach more data, but at least the
management of that data would be tied to the JVM's call frame management
rather than written by hand.
A few down sides I can see:
1. it could cause JVM frame optimizations (reuse, omission?) to be
turned off for the frames in question. However that penalty would
probably be greatly outweighed by the ability to avoid allocating
userspace frame objects.
2. some API, bytecode would be necessary since the frame contents may
vary at runtime (i.e. an annotation isn't good enough, since it's
static). And of course getting such things through the system is hard.
The bottom line here though is that we won't ever get these languages to
the level of performance we want (while keeping them feature-complete)
without some way to leverage the JVM's framing logic for each language.
Thoughts?
- Charlie
Kresten Krab Thorup
source which is not accessible by reflection. Having some kind of
reflective access to this would allow several new behaviors in the
meta layers.
I've done a lot of work in pushing reflection to the limit, and being
able to scan and mutate the stack would be absolutely awesome. With
this, e.g. Ruby's object space would be implementable in plain Java,
as would Smalltalk's become:.
Kresten
Don Schwarz
>
> Another aspect is, that frames are the only kind of object reference
> source which is not accessible by reflection. Having some kind of
> reflective access to this would allow several new behaviors in the
> meta layers.
>
Even just being able to get a stack of Method objects for a thread
would be useful in many situations, especially when tied to reflection
of Method annotations.
Ted Neward
you the Method that was invoked....
I take it you want *mutable* access to the stack?
Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.17.13/1214 - Release Date:
> 1/8/2008 1:38 PM
>
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.17.13/1214 - Release Date: 1/8/2008
1:38 PM
Attila Szegedi
You'd need a class loader to resolve these into a
java.lang.reflect.Method object... Oh, and a method signature in case
the method name is overloaded, as there's no reflection API for method
lookup by line number.
So, it's unfortunately not too helpful for this use...
Attila.
Ted Neward
returned a Method object corresponding to that information. Not sure where I
got that from, might have been from the CLR, I don't remember. Sorry....
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.17.13/1214 - Release Date:
> 1/8/2008 1:38 PM
>
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.0/1218 - Release Date: 1/10/2008
1:32 PM
Kelly Nawrocke
Spec. Its optional for ES4 implementations but the semantics could be
useful for this discussion:
http://wiki.ecmascript.org/doku.php?id=proposals:stack_inspection
The above is based on the Doctoral Thesis of John Clements which is
located here:
http://www.csc.calpoly.edu/~clements/papers/dissertation.pdf
I don't currently have enough time to write up a nickel tour of the
ideas in the above docs but maybe this weekend.
Kelly
--
Like the fella says, in Italy for 30 years under the Borgias they had
warfare, terror, murder, and bloodshed, but they produced
Michelangelo, Leonardo da Vinci, and the Renaissance. In Switzerland
they had brotherly love - they had 500 years of democracy and peace,
and what did that produce? The cuckoo clock.
-- Orson Welles