In developing JRuby, studying IronPython and IronRuby's commit logs, and 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---