harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Extending ‘org.vmmagic.unboxed’ package with native calls and TLS access
Date Wed, 11 Oct 2006 06:09:53 GMT
Mikhail,
It all seems reasonable.  Regarding #6.  Maybe I misunderstand what you are
saying but it seems best to put the java vmhelpers in the same isolation as
other security sensitive kernel classes.


On 10/10/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> Mikhail,
>
>     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
> >
> >
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

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