Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of weldonwjw@gmail.com designates
 64.233.182.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=fccoeS9/g1tfiyYZyxPBVUZ2dAIgEkXRVOxuKdTMY0JtdAuzHn9gxj1z7T3g8N+eFiRDLtIFR8c+u28NyNF2UABQBz3deHole9xim9XgIefpMTCLjZS6puZ/+3D8kbgjorJ+FVtZ74B9D2zlOHt4boW5p+V/QINhqG54KgllC7Q=
Message-ID: <4dd1f3f00610102309x3969d468s75e2363feff91463@mail.gmail.com>
Date: Tue, 10 Oct 2006 23:09:53 -0700
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: =?UTF-8?Q?Re:_[drlvm]_Extending_=E2=80=98org.vmmagic.unboxed?=
 =?UTF-8?Q?=E2=80=99_package_with_native_calls_and_TLS_access?=
In-Reply-To: <51d555c70610101306hca28ccfo751a3b021ba50a6e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9114_18691089.1160546993000"
References: <bc79dd600610090719y3caf93d8n6a69845d573f4c47@mail.gmail.com>
	 <51d555c70610101306hca28ccfo751a3b021ba50a6e@mail.gmail.com>

------=_Part_9114_18691089.1160546993000
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_9114_18691089.1160546993000--