harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] Extending ‘org.vmmagic.unboxed’ package with native calls and TLS access
Date Tue, 10 Oct 2006 20:06:58 GMT

     Please see inline.

On 10/9/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >All,
> >We have 'org.vmmagic.unboxed' package (address arithmetic) support in
> both
> J>itrino.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'.

>>> Sounds reasonable

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

>>> Could use both ?

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

>>> This is a good idea. I think the VM needs to do this housekeeping, since
it provides the stubs of regular helpers to the JIT anyway

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

>>> We had discussed this elsewhere and annotations look cleaner.
Annotations should be obtainable via reflection methods
get/resolve_annotations() on the class, but Alexey V could confirm. We could
have a default like cdecl and even use this exclusively initially, unless
you want to use a custom platform independent JIT calling convention

 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?

>>> I did not really understand why you are recommending leaving them out of
the boot loader set.

 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