All, We have 'org.vmmagic.unboxed' package (address arithmetic) support in both Jitrino.OPT and Jitrino.JET compilers today. So we can rewrite part of our VM helper's fast paths in Java and teach JIT compiler to inline it. The only thing is left to do is to get the answers to the following questions:
1) What is the default package for the fast path helpers? My proposal is 'org.harmony.vmhelper'. 2) How will JIT know if to use "magic" helpers? The one option is to pass cmd-line parameter, like - Djit.use_magic_vmhelpers=on. This option could be placed into the EM configuration file as any other JIT option. 3) How to call a slow native helper's version from the fast-path part of the helper written in Java? The proposal is to create package like 'org.harmony.vmhelper.native' with stub methods for all native helpers. Once such a method is called from Java, JIT will replace it with a real native helper call. In this case we need to have a mapping between "magic" and native helpers on JIT or VM side. 4) How to detect native helper calling convention? We can use one of the approaches JUnit uses: a) check the prefix for the method: stdcall_new(..), cdecl_new(): b) check the Java annotation for the method. I prefer to use approach a). But the only reason for that is that I'm not sure DRLVM has interface to access to the class annotations today. Could VM gurus correct me? 5) How to access to TLS data from Java? The last agreement was something like "public static Address TLS.getAddress()" method. We can put TLS class to the package with all of native VM helpers stubs (see item 3 for details) 6) Where to keep and which classloader to use to load "unboxed" + "helpers" Java code? Would it be part of the kernel classes and loaded by bootstrap classloader? I vote leave it outside of the kernel class. But this way could cause security problems in future. Any other opinion? All of the tasks above are rather easy to implement. But we have to come to the agreement before coding. Please, suggest your vision or ask me if something I wrote is unclear. + The first candidates for inlining are: allocation helpers, monitor helpers, write barriers. Any other ideas? -- Mikhail Fursov
