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
-~----------~----~----~----~------~----~------~--~---

Reply via email to