> 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 <[EMAIL PROTECTED]> 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
