harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject [drlvm] Extending ‘org.vmmagic.unboxed’ package with native calls and TLS access
Date Mon, 09 Oct 2006 14:19:08 GMT
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

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
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
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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message