On Tue, 11 Jul 2006, Charles O Nutter defenestrated me:
> 
>    Been thinking through compilation a bit more. Here's a little
>    pseudo-bytecode for the fib function.
>    def fib: arity 1
>        PUSH local var 2
>        PUSH literal 2
>        CALL '<' arity 1
>        JMP_FALSE to XX
>        PUSH local var 2
>        RETURN
>    XX: PUSH local var 2
>        PUSH literal 2
>        CALL '-' arity 1
>        FCALL 'fib' arity 1
>        PUSH local var 2
>        PUSH literal 1
>        CALL '-' arity 1
>        FCALL 'fib'
>        CALL '+'
>        RETURN
>    end
>    It's obviously modeling a stack-based machine rather than
>    register-based, which makes sense since we'll be running on a Java VM.
>    It's also not far off from what the actual Java bytecodes would look
>    like; the big difference is the calls for <, -, + and so on (which
>    really just increases the number of calls) and the fact that there's
>    no typing (which just means everything is an IRubyObject, i.e. a Java
>    reference type). Coming up with the bytecode isn't really the hard
>    part though...it's properly traversing the AST to execute in the
>    proper order. For example, we can't do any of the calls before we
>    determine the receiver and the arguments, but the call nodes are
>    encountered first. The current interpreter recurses to handle that,
>    traversing the receiver and arg nodes before returning to make the
>    call, but the compiler will want to receive the nodes serially.
>    For those of you keeping score, the ruby "bytecodes" CALL and FCALL
>    above could eventually translate to INVOKEDYNAMIC JVM calls. The
>    trouble with INVOKEDYNAMIC is that you still need to have the method
>    on a Java class somewhere, and you can't move methods around once the
>    class is generated. It might, however, be possible to replace old
>    classes with new when they're modified ( i.e. for every reopening of a
>    class), but it would be VERY important to keep that class churn to a
>    minimum. The dynamic-invoked classes would have to just be method bags
>    though, since you can't change the type of an instantiated object (and
>    therefore couldn't associate it with the new generated class).

  During Gilad's JSR292 talk at JavaOne he mentioned the idea that a special
flag could be added to a class definition so it is marked as dynamic.
This would allow replacement/addition/removal of methods.  The extra flag 
would be a cue that all this crazy stuff can happen in that particular class.
He stated this is only a wild idea he has not put much thought into.  

  He also mentioned allowing a low level handler to be invokable when
method_missing happens.

-Tom

-- 
+ http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+
| Thomas E Enebo, Protagonist  | "Luck favors the prepared    |
|                              |  mind." -Louis Pasteur       |


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel

Reply via email to