The last time I used JET was 18 months ago, so this is not definitive. However, this is how it roughly works:
The tool takes in a set of JARs (or classpaths), and attempt to compile all class files into some kind of native version. On deployment run, the JET virtual machine loads the native version whenever a class is loaded. Essentially, think of it as JIT cache for hotspot (but it isn't hotspot) that persists across run. For optimization, you can run the app in profile mode, where the profiler outputs information that the compiler can use to optimize the compilation globally. For dynamic code, there is also a JIT built into the runtime, so that even natively-compiled app can load dynamic java bytecode. However, the compilation is obviously not ahead-of-time. A similar process works for most obfuscators (which has value not only to obfuscate, but also to optimize class files). I applaud the desire to maintain the right semantics, but I think there is much to gain by pretending our JRuby-compiled files are Java class files. In fact, as much as it pains me to not maintain the right semantics, I would make the further argument to compile the ruby code to conventional Java names, so that maximum capability can be maintained (you never know which byte code tools makes assumption about CamelCaseNames). For proper semantics, we can hide the classes under a org.jruby.compiled.module.foo.bar namespace, to signal that it should not be touched directly. Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Oliver Nutter Sent: Friday, October 19, 2007 5:45 PM To: [email protected] Subject: Re: [jruby-dev] Compile to .rbj instead of .class? Peter K Chan wrote: > Well, you could, couldn't you? > > The output is a legal Java class files, so you are free to load it up > and use it safely in your Java class. You may need to initialize some > JRuby constructs before you call the method on that class, but how is > this different from any other API? Would you go around and arbitrarily > instantiate any Java objects you find in the class path, without looking > at the Javadoc first? This isn't entirely true. the methods in the class are not directly callable; they expect you to set up call frames, variable scopes (and you can't know which kind they need from outside), push and pop various elements on the ThreadContext, and so on. Beyond that, there's no way anyone could ever guess or compile Java code that would call most of the methods on the class, since they have names like __file__ and foo_1 and __rescue_47. The exceptions, however, are that there's three entry-point methods: - a static main method which spins up a JRuby instance and runs the compiled script - a run method used by the JIT, which expects that all framing/scoping has been done and then runs the script - a load method which does the framing and scoping necessary to call a given script, and then runs the script But these are pretty limited, and only give you the ability to launch the script as a whole, not call any methods defined within it. > Let me add a specific, technical problem with using custom extension: > consider the JET compiler, which compiles java .class to native code. If > we leverage that to compile JRuby-compiled code, we can have (as far as > I know) the first native compiler for Ruby. I can see it compiling a > foo_bar.class into a foo_bar.obj, which, when > Class.forName("foo/bar.rb"), will load the native code version. If we > require a custom classloader, "foo/bar.rb" cannot be precompiled AOT > [1]. I'd like to see if this is a real limitation; how do you specify the file to compile with this tool? Does the file have to end in .class? I appreciate your concerns, really. It's unfortunate that so many tools and libraries expect .class, but that's the way it is. I'm still on the fence. - Charlie --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
