Re: Compile Ruby Code?

There are a few major issues with compilation:

1. Ruby dynamically dispatches to all methods, where Java wants to
statically bind to a class or interface. To make matters worst, almost
everything not a keyword in Ruby is a method call, and a bare
identifier can alternately refer to a variable or a method name. Since
Java method dispatching does not work this way, some level of
interpretation will always be required.
2. Continuations. The ability to callcc in Ruby is a major stumbling
block for any sort of compilation. In order to save the current
continuation and return to it later, we obviously can't directly call
through Java methods using the Java stack. There's no longjmp in Java,
and so we can never easily escape the stack. This is being addressed
in JRuby today by building a stackless interpreter engine, so that at
any point during the code execution can be paused or memoized. However
continuations mean that we can never fully compile down to Java code.
3. Ruby threading model is quite different from Java's threading
model, primarily because Ruby threads are "green" and all threads,
including the thread scheduler, act as a single operating system
thread. Because of this, Ruby can support thread semantics such as
stop and kill that would be "unsafe" in native threading environments.
Since Java threads do not support these semantics, JRuby will live
somewhere between the two worlds using an m:n threading model. In
other words, Ruby threads will be "green", but backed by n native
threads, allowing us to handle Ruby's threading requirements while
scaling to multiple native threads on multiple processors. It will
hopefully provide the best of both worlds, but it provides another
example where Ruby can't be compiled directly to Java.

In the code example you sent, I see the following methods invoked: <,
puts, and +. In most scenarios the = and the = in the += will be
turned into simple variable assignments. while and end are keywords
and handled by the parser. Finally, i, 0 and 5 are a variable and two
literals, also handled by the parser. So a rough compiled output might
be:

IRubyObject var_i = new RubyFixnum(0)
IRubyObject literal5 = new RubyFixnum(5)
IRubyObject literal1 = new RubyFixnum(1)
while (i.invoke("<", literal5).isTrue()) {
  var_i = i.invoke("+", literal1)
  Object.invoke("puts", var_i)
}

Of course there's obvious simplification here, but the idea is that
anything we can do directly in Java, like while loops, tests
(if/then), variable assignment, and so on could be compiled down to
Java code. Where the original interpreter would have to traverse as
many as 11 operations, it would now have a single piece of Java code
to do most of that work.

On 2/22/06, Yemi D. Bedu <yemi@xxxxxxxxxxxx> wrote:
> Hello,
>  Ok. So for compilation, how much source code would actually get
> compiled. If I am using libraries, will this all be embedded in one
> large java file. Would any of the code be able to benefit from a mix
> mode compile (execute a ruby loop in java in holds to the bounds that
> java can handle). That would somewhat have parts of Ruby running on the
> VM. An example:
>
> i = 0; while i < 5; puts i+=1; end
>
> could be compiled to java source of:
>
> int Ruby_internal_var_i = 0; while(Ruby_internal_var_i < 5){
> System.out.println(Ruby_internal_var_i +=1); }
>
> The "i = 0;" would have been detected as a fixnum and the body "DO NOT"
> have to be parsed/translated/compiled on the java side. So another way:
>
> int Ruby_internal_var_i = 0; while(Ruby_internal_var_i < 5){
> Ruby_internal_var_i = ruby_inter.parse("puts i+=1"); }
>
> Just throwing some stuff out there to see if it will float. Good day.
>
> Yemi Bedu
>
> P&R Fasteners
> 325 Pierce St
> Somerset, NJ 08873
> 732-302-3600
>
> -----Original Message-----
> From: jruby-user-admin@xxxxxxxxxxxxxxxxxxxxx
> [mailto:jruby-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Charles O
> Nutter
> Sent: Wednesday, February 22, 2006 3:50 PM
> To: jruby-user@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Jruby-user] Compile Ruby Code?
>
> I certainly agree with the "easier to sell Java". That's one of the
> founding principals of my work personally on JRuby...trying to subvert
> the system and make Ruby possible within the Java world.
>
> There is a short-term "compilation" option I have been considering
> that perhaps you might have an opinion on. In the absence of a real
> compiler, there is some value in being able to turn Ruby scripts into
> Java class files, even if there's little actual compilation being
> done. What we could do is simply serialize or embed the Ruby script
> into a class file along with wrapper code to handle JRuby specifics.
> What you would essentially have is a class that could be classloaded
> as normal, and that loading process would prime JRuby with appropriate
> Ruby definitions. Ultimately what happens behind the scenes is just
> that the class itself calls out to JRuby or JRuby is made aware of the
> class, and from there the normal Ruby script parsing happens.
>
> Ultimately, since Ruby is far more dynamic a language (not just
> dynamically typed, but really "dynamic"), we'll have to do something
> like this anyway...there's just no way on current JVMs that Ruby code
> can be run directly.
>
> What this gets you is a way to make Ruby feel a bit more like Java
> code, and a minimal obfuscation of Ruby script code within a class
> file. Would something like this provide any value?
>
> On 2/22/06, Kris Leech <krisleech@xxxxxxxxxxxxxxx> wrote:
> > Thanks for your comments Charles. I interested in JRuby for two
> reasons,
> > both of almost equal weight, firstly to allow ruby code to be deployed
> > to servers without ruby installed. This is often the case in the
> public
> > sector and secondly as a layer of protection for Intellectual
> Property.
> > I think the combination of bytecode and obfuscation would be enough to
> > make reverse engineering the code more costly than writing it from
> > scratch :)
> >
> > I am aware of one company writing an obfuscator, but they only
> answered
> > one email I sent so I dont know if it is due any time soon. However I
> > guess it would not be very difficult to write one. It would just be a
> > fancy find and replace on the source code.
> >
> > Am I right in thinking JRuby can be used in two ways, firstly it can
> be
> > used to run ruby code using java (java interpreter) and secondly it
> > allows ruby code to be embedded in Java applications?
> >
> > If ruby code can be put inside a Java applications not only can we run
> > our code on Java but we can actually distribute a java application
> (with
> > the ruby hidden inside). At the moment in certain sectors its easier
> to
> > sell java.
> >
> > Many Thanks, K.
> >
> >
> >
> > Charles O Nutter wrote:
> >
> > >Unless (or until) a reverse-compiler were created (which probably
> > >would not be a high priority at first) there wouldn't be an easy way
> > >to reverse it. However, Java bytecode isn't terribly complicated, and
> > >the source for the compiler would be open, so eventually someone
> would
> > >be able to reverse the process.
> > >
> > >If you are looking to protect Ruby code this way, an additional
> > >obfuscation step might be your best bet, so that even if the code
> were
> > >decompiled it would be unreadable. An obfuscator that takes existing
> > >Java classes and mutilates them might also be an option. This would
> > >obviously make debugging more difficult, and we do not have plans to
> > >write an obfuscator at this time.
> > >
> > >- Charlie
> > >
> > >On 2/20/06, Kris Leech <krisleech@xxxxxxxxxxxxxxx> wrote:
> > >
> > >
> > >>Thanks Tom for the swift reply, can ByteCode be easily transformed
> back
> > >>in to ruby code?
> > >>
> > >>
> > >>Thomas E Enebo wrote:
> > >>
> > >>
> > >>
> > >>>On Mon, 20 Feb 2006, Kris Leech defenestrated me:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>Great work with JRuby and the opening up of platform coverage. I
> was
> > >>>>looking at JRuby as a means of protecting Intellectual Property
> ie.
> > >>>>distributing compiled or byte code instead of source code. But it
> > >>>>appears that JRuby is an interpretor only, at the moment anyway.
> > >>>>
> > >>>>Are there any plans to create a ruby bytecode pre-compiler?
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>> Yes, but not in the immediate future.  Charles Nutter has been in
> > >>>the progress of converting the evaluation part of JRuby to be
> iterative
> > >>>instead of recursive.  An iterative evaluation model should be
> fairly
> > >>>straight-forward to translate into instructions.  So once that is
> done
> > >>>we will look at compilation.
> > >>>
> > >>>-Tom
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>-------------------------------------------------------
> > >>This SF.net email is sponsored by: Splunk Inc. Do you grep through
> log files
> > >>for problems?  Stop!  Download the new AJAX search engine that makes
> > >>searching your log files as easy as surfing the  web.  DOWNLOAD
> SPLUNK!
> >
> >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=1216
> 42
> > >>_______________________________________________
> > >>Jruby-user mailing list
> > >>Jruby-user@xxxxxxxxxxxxxxxxxxxxx
> > >>https://lists.sourceforge.net/lists/listinfo/jruby-user
> > >>
> > >>
> > >>
> > >
> > >
> > >--
> > >Charles Oliver Nutter @ headius.blogspot.com
> > >JRuby Developer @ jruby.sourceforge.net
> > >Application Architect @ www.ventera.com
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.net email is sponsored by: Splunk Inc. Do you grep through
> log files
> > >for problems?  Stop!  Download the new AJAX search engine that makes
> > >searching your log files as easy as surfing the  web.  DOWNLOAD
> SPLUNK!
> > >http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
> > >_______________________________________________
> > >Jruby-user mailing list
> > >Jruby-user@xxxxxxxxxxxxxxxxxxxxx
> > >https://lists.sourceforge.net/lists/listinfo/jruby-user
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD
> SPLUNK!
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > _______________________________________________
> > Jruby-user mailing list
> > Jruby-user@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/jruby-user
> >
>
>
> --
> Charles Oliver Nutter @ headius.blogspot.com
> JRuby Developer @ jruby.sourceforge.net
> Application Architect @ www.ventera.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
> _______________________________________________
> Jruby-user mailing list
> Jruby-user@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/jruby-user
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Jruby-user mailing list
> Jruby-user@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/jruby-user
>


--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642