Maxim Kizub wrote: | >This is also known as "fat binaries". | >The main problem with that is that the quality of the resulting code is | >as low as the quality of the code produced by kaffe's translator. | | BTW - why? | I can think only about one way a jit may produce a better code, then | compiler - it knows the runtime information - method's and field's | offsets in virtual table and class. That depends on the quality of the JIT engine. The main goal of a JIT engine is to translate bytecode into machine code, so that it will run 5-10x faster. Since the speedup is so marked, you don't have to put a lot of work into code quality to get it. However, code quality does take time - have you ever run "gcc -O6"? It's very slow, although the results are often worth it. Since JIT is run every time a class is loaded for the first time, your users have to sit through the compile time. For this reasom, JITs tend to be lean and mean, generating non necessarily optimal code, but "good enough", and doing it quickly. | BTW, can someone explaine me how kaffe produces code for | fields access and method calls for not loaded classes? Trying to | do this by looking at kaffe's code is as easy as for egcs code ;-) The only entity that can access a field is a method in the class or a subclass. That requires that the class be loaded. No problem there. As for calling methods in unloaded classes (presumably constructors or static methods), kaffe uses "trampolines": - A class must be loaded before any of its constructors or methods can be called, since Java must perform a type check. - However, the JIT need not be run right away. Instead, in the method dispatch table for the class, all of the method pointers are initialized to point to a default routine. - When a program calls a method that hasn't been JITted yet, the default routine is invoked. It figures out what method was requested, JITs it, and replaces the entry in the method table with a pointer to the new code. It then jumps to the new code. - The next time the method is called, its code is executed directly. | >> I'd rather not delve into the bowels of ecgs - trying to figure out | something | >> by looking at that code is not easy. Well, kaffevm is only 33384 lines of code and gcc is only 305068, so kaffe is a little easier to understand. ;-)