harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Rebriy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5322) [drlvm] Lazy resolution in JET needs to be implemented on x86_64
Date Fri, 18 Apr 2008 09:08:21 GMT

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

Pavel Rebriy commented on HARMONY-5322:
---------------------------------------

I've investigated the Eclipse crash and found an error. The following patch fixes it and enables
lazy resolution on Linux x86_64.


> [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.


Mime
View raw message