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
 64.233.182.187 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=g47VeCtDayGZb4ev+fwn/0044K6ThvzEtomDOETVfQq6BBtP/7Th4FtGUbQGquNvsgZZs9YI5CDXKa3ITxejMbbOymmyMQzmRqVod4YNsDTr7IGCWiT0c6dyST3LopTsXNXTTteL+ZVYFZ6YHpDoaRyln06uL2iJ9oIrKyBSN1g=
Message-ID: <bc79dd600608160121g232824a1ua234fbe1eedc1d69@mail.gmail.com>
Date: Wed, 16 Aug 2006 15:21:01 +0700
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Helper inlining in JIT
In-Reply-To: <51d555c70608152216m2aacb358sf039b4c117e176ee@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_15303_32114499.1155716461559"
References: <bc79dd600608090726r475244d2tfa353132dbccfac8@mail.gmail.com>
	 <4dd1f3f00608091423v64d1a5cue389a2d8b4f9512d@mail.gmail.com>
	 <bc79dd600608110718w56ccbeeew3e6b0198b4425beb@mail.gmail.com>
	 <51d555c70608111850v2a437935h972f631efd8e19f3@mail.gmail.com>
	 <9623c9a50608130629n5dc4c229w97f4e9159713ad22@mail.gmail.com>
	 <51d555c70608152216m2aacb358sf039b4c117e176ee@mail.gmail.com>

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

Rana,

On 8/16/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
>
> Or whether there is a finite set of helpers/services fastpaths that one
> can teach the
> jit about, so that the jit knows a priori how to generate the code for
> these
> inline. As far as I know, several product implementations are OK with
> teaching the jit, and their performance is quite excellent.
>    This may not be "ideal" for modularity and openness, but is it as bad
> as
> it sounds? If you plugged a new gc into drlvm that introduced a completely
> new helper never used before, jitrino would need to know something about
> its
> semantics and when to call it. So the seperation is not as clean as one
> might think.


I also thought about it, the solution2 in initial letter is almost about the
same.
This solution requires modification of JIT every time you need new helper
implementation and  limits a developer. E.g. GC or ThreadManager developer
has to know JIT internals or depends on some JIT guru to add the fast-path
support to JIT.
When you have a several VM/GC/TM distributions JIT may become bloated with a
lot of helpers to support. Doing this way we share the code between JIT and
another component while we can avoid it and keep the fast-path version of
the helper near the helper itself but not in a separate component.
IMO the solution2 is good for conserved VMs like SUN's or BEA's but limits
Harmony. On the another hand the Solution1 allows you to write a whole
component (e.g. GC) in Java and communicate with it effectively.

The separation is not clean if there is a helper that we can't write in
Java. Once we added TLS and native calls support to Java I can't imagine
this helper today, but I'm still looking for it :)

   If I am overruled and we feel that a framework is absolutely necessary,


Not is absolutely necessary, but IMO is better by design. Once supported it
will make helper optimization easier.

what you are suggesting makes sense. We could have a 2 phased approach:-
>    1) We code some of the helpers in Java and jitrino can inline them. We
> code the rest(unsafe) in asm and invoke them as naked or frameless calls (
> not jni ). My experience is that the cost is not in the call/ret ( unless
> you mispredict the branch ), but in setting up and tearing down the
> prolog/epilog, aligning the frame etc. We could add a helper calling
> convention to the jit for efficient parameter passing.


Yes, this is a good point to start. The information about native method's
calling convention (slow helper)  can be stored as annotation for the
method. Here is an example from Xiao-Feng:

Reference object_alloc(int size, Address vtable ) {
      Reference result = ThreadLocalBlock().alloc(size) ;
      if( ! free.isNull() ){
           result.setAddressAtOffset(vtable, VTABLE_OFFSET_IN_OBJECT);
           return result;
      }
      //native slow path
      return object_alloc_slowpath(size, vtable);
}

and object_alloc_slowpath() is the native version of the slow helper.

We can add Java method to the same Java class:
private static Reference object_alloc_slowpath(int size, Address vtable)
and annotate it something like this
@NativeHelper{"helperName=slowAlloc", callingConvention="cdecl",
enumerationPoint="true"....}

The same could be done for JNI methods too, but JNI requires additional
support from VM.


   2) We develop the unsafe intrinsics and if using them we can get better
> performance we can use them to progressively replace the asm helpers.


What is the difference of unsafe intrinsic and asm helper?

  On a different topic, if we wanted to also optimize the JNI interface at
> some point, would we then develop a different framework for it :-) ?


AFAIU  it's  enough to annotate JNI method with calling convention details
and to support it in JIT and VM.  So I see no difference in implementation
with helper inlining here. Just an extension or another version of helper
inlining mechanism.
Am I missing something about JNI support?

AFAIK Weldon and Alex made a lot of work related to support of unboxed types
in DRLVM.
We can reuse their work to prototype the inlining of the first helper's fast
path in Jitrino.JET (it's easier) and after it succeed port the code to
Jitrino.OPT compiler.
Is new object allocation helper OK to start from? Any other ideas which
helper to use to start?


-- 
Mikhail Fursov

------=_Part_15303_32114499.1155716461559--