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 mike.fursov@gmail.com designates
 66.249.92.174 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:mime-version:content-type;
        b=OndEt6DeEAGUq+eywzcQNBpuYA+cz4hNWeOUCA1Qq1k/y2+WSEVG4jV1lT50u9ZEXAxBbFutCZpCnU510y3X5agfVYzJb48L2ySI2hWkfaJ52gOv4t1f1ajLKYoS2qOhEy4f96tweHO99Kq6OCRJy8vD/UCL5GjCOAA0kK3ktp8=
Message-ID: <bc79dd600610090719y3caf93d8n6a69845d573f4c47@mail.gmail.com>
Date: Mon, 9 Oct 2006 21:19:08 +0700
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: =?WINDOWS-1252?Q?[drlvm]_Extending_=91org.vmmagic.unboxed=92_?=
 =?WINDOWS-1252?Q?package_with_native_calls_and_TLS_access?=
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_53665_18097992.1160403548071"

------=_Part_53665_18097992.1160403548071
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_53665_18097992.1160403548071--