Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <1479262829.1205833644329.JavaMail.jira@brutus>
Date: Tue, 18 Mar 2008 02:47:24 -0700 (PDT)
From: "Mikhail Fursov (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-5322) [drlvm] Lazy resolution in JET
 needs to be implemented on x86_64
In-Reply-To: <23207797.1197974983220.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HARMONY-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579783#action_12579783 ] 

Mikhail Fursov commented on HARMONY-5322:
-----------------------------------------

What is the current state of this issue?

> [drlvm] Lazy resolution in JET needs to be implemented on x86_64
> ----------------------------------------------------------------
>
>                 Key: HARMONY-5322
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5322
>             Project: Harmony
>          Issue Type: Sub-task
>          Components: DRLVM
>         Environment: All x86_64
>            Reporter: Gregory Shimansky
>            Priority: Minor
>         Attachments: lazy-whole-gen_invoke.patch, lazy.patch, lazy.patch, lazy.patch, StepIntoSelectionClass.java
>
>
> This is a subtask for HARMONY-5305 because this bug is not related to the bug in JIT that makes EUT to go into infinite loop. 
> Test application is attached. Test scenario is the following:
> 1. Set breakpoint on line 22
> 2. Select method step
> 3. Press Ctrl-F5 or select Step Into Selection in context menu
> When this is done debugger should step into method step. But instead it continues program execution until function detach is called which happens at the end of execution of function main. The bug seems to be in JDWP agent because it ignores a single step event for method step. This event is actually reported to it with JVMTI.
> The bug with test testStepIntoSourceMethod seems to happen because on x86_64 JET doesn't have lazy resolution. When invokevirtual for method step is executed, it compiles the method first. This leads to calls for VM.intern and ClassLoader.load class Java calls that are reported by JVMTI to the agent. Only after these several java calls does JVMTI report single step for method step itself. But when this happens this event is not received by eclipse for some reason, single step is turned off and execution continues uninterrupted until the program ends.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.