Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: harmony-dev@incubator.apache.org
From: Alex Astapchuk <alex.astapchuk@gmail.com>
Subject: Re: [dlrvm] ClassCircularityError in recursive compilation (Was:
 Re: [drlvm] smoke test : gc PhantomReferenceQueueTest is really unstable)
Date: Tue, 24 Oct 2006 18:27:07 +0700
Lines: 90
Message-ID: <ehktac$tqs$1@sea.gmane.org>
References: <e0f125db0610110515t1f75e58ew979e49a8a5d853d6@mail.gmail.com>
	 <783bf8b0610240049p49ba8c97m7e206cec822db13b@mail.gmail.com>
	 <bc79dd600610240132x68d4b18ds95b6cd756ad84757@mail.gmail.com>
	 <200610241448.56263.gshimansky@gmail.com>
 <bc79dd600610240404o1a096161t9bb0c0a8e8710f8b@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
In-Reply-To: <bc79dd600610240404o1a096161t9bb0c0a8e8710f8b@mail.gmail.com>
Sender: news <news@sea.gmane.org>

 > I hope we all understand the same under "lazy resolution" but it would be
 >> better if you explained a bit how it is going to work.
 >>
 >
 > Let's ask Alex Astapchuk to describe it. He tried to do it in JET, so he
 > knows more nuances about implementation problems.
 >

Currently, both .opt and .jet use compile-time (eager) resolution.
When a JIT compiles a method and has a symbolic reference (e.g. a field, 
name or a method name, or a class name) it asks VM to resolve it.
For example, if it is a name of a static method, then the jit calls 
vm_resolve_static_method(). Then the jit calls 
method_get_indirect_address() and generates CALL instruction.

What we used to have in .jet, was a lazy (here: runtime) resolution 
instead of compile-time resolution.

We generated a code, that called the same resolve_{somethig}' during 
runtime.

For example, 'method_resolve_static_method' followed by 
method_get_indirect_address().
After successful resolution, we patched the code, to avoid too many 
calls to that resolve_{something} on already resolved items.

We did these experiments to check whether it improves a client apps 
startup time (no resolution during compilation => compilation gets 
faster => overall startup time decreases).
This did not show any benefit.

We also tried to resolve some deadlock issues we had that time with the 
lazy resolution.
But finally we came to the conclusion that lazy resolution does not help 
here again - there were lock issues in class loading and in jit support 
in VM.


-- 
Thanks,
   Alex


Mikhail Fursov wrote:
> On 10/24/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>>
>> On Tuesday 24 October 2006 12:32 Mikhail Fursov wrote:
>> > Pavel, thanks
>> > SUN passes both tests (with -Xcomp too), BEA(1.5) crashes as
>> expected.Our
>>
>> I wonder why it is expected :)
> 
> 
> I tried very similar test some time ago. So it's OK that the results are 
> the
> same with this test too.
> 
>> VM throws ClassCircularityError with both compilers and passes with
>> > interpreter.
>> > IMO we must add lazy resolution to both compilers in future. The 
>> reason:
>> to
>> > be able to run everything SUN runs.
>> > The question is when?
>> > My answer: H1 2007.
>>
>> It is cool that we finally have tests which show the problems with out
>> design
>> and we seem to agree that lazy resolution is the only right way to 
>> resolve
>> methods.
> 
> 
> Wait a while :) Lazy resolution support is really tough requirement from
> JIT. May be we can find another solutions soon?
> 
> 
> I hope we all understand the same under "lazy resolution" but it would be
>> better if you explained a bit how it is going to work.
>>
> 
> Let's ask Alex Astapchuk to describe it. He tried to do it in JET, so he
> knows more nuances about implementation problems.
> 


-- 
Thanks,
   Alex