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 rdasgupt@gmail.com designates
 64.233.182.188 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=j9qPYftWrVj/hKPjIVtkxItSoWX2SsyqCMvQ9YOBvPUu5Xw77Jo7C2Ek5+xamSpdMxKMtAkIBvkV7j6jFxLUpGQg7dNgtU/BOhrzW8xmKvEyljLAx7NWECBj3b8VK+ebJ3rYyIb635W9zs/u8lcHxBDhdLxN26+dcFGTpUKML7A=
Message-ID: <51d555c70608111850v2a437935h972f631efd8e19f3@mail.gmail.com>
Date: Fri, 11 Aug 2006 18:50:59 -0700
From: "Rana Dasgupta" <rdasgupt@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] Helper inlining in JIT
In-Reply-To: <bc79dd600608110718w56ccbeeew3e6b0198b4425beb@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_17565_32391908.1155347459231"
References: <bc79dd600608090726r475244d2tfa353132dbccfac8@mail.gmail.com>
	 <4dd1f3f00608091423v64d1a5cue389a2d8b4f9512d@mail.gmail.com>
	 <bc79dd600608110718w56ccbeeew3e6b0198b4425beb@mail.gmail.com>

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

MIkhail,
  I have some questions, or just arguments :-) First, though it is nice to
talk of an open helper inlining framework to call VM/GC helpers, isn't the
set of helpers used in  JVM's more or less well known and standardized? In
other words, is a framework absolutely necessary, can't the jit just
generate code inline for the known fastpath of the helper algorithm? For
example if we replaced the DRLVM gc with gc_new , how many new helpers do
you think we would introduce?

Also, please see below for some inline comments...


On 8/11/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>
>
> >Even this simple helper reveals a lot of features to support:
>
> >1) Access to TLS is required. It could be fs:[14h] on Windows or helper
> call
> >on Linux (depends on kernel (?) ). Even if we have an access to TLS we
> need
> >to know the offsets of our slots: 'current' and 'ceiling' in example.
> >So we need to have a way to pass these values to JIT. May be a 'private
> >static final' variables in the helper's class with special runtime
> >annotations could be used to pass the values to JIT?


So basically, every new VM would need to implement the helper in an almost
identical way or at least using identical final variables...I wonder how
much flexibility that leaves ..

>2) Calls support is needed. Both for "slow" helper version and to access
> >TLS.
> >This means also that calling convention support is needed. Runtime level
> >annotations for helper calls could be used here. E.g. create a magic
> method
> >'slow_alloc' and teach JIT to call real helper instead of it. Get the
> >calling convention info from annotation (?)


Is it not possible for the fastpath helper to just return a failure so that
the jit generated conventional helper callpath can kick in. In other words,
does the slow helper have to be called from the fast helper?


>3) Do we really want to expose native regs to Java: EAX, ECX... I vote do
> >not to use them when writing helpers in Java and to allow to JIT to
> optimize
> >unboxed operations (allocate registers by itself)


This again goes back to my original question...if the JIT knew the standard
fastpath, it could generate code optimally for it anyway with the best use
of registers?

These are just arguments before we set off developing a framework. I would
like to know if helpers vary a lot across VM implementations, seems to me
they need to do the same old things. Even if a framework is needed, it seems
that we will land up inventing a language with unboxed primitives,  virtual
register access and special calling conventions for it to work optimally.
And then we want every VM to use this language to code fastpath helpers and
also to code the slower helpers in the conventional way. Maybe we should ask
VM developers to vote on how open this is....

Thanks,
Rana

------=_Part_17565_32391908.1155347459231--