[jira] Updated: (HARMONY-5322) [drlvm][jvmti] Workaround for absence of lazy resolution should be removed when it is implemented on x86_64

["Gregory Shimansky (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gregory Shimansky updated HARMONY-5322:
---------------------------------------

    Attachment: lazy.patch

First step to implement lazy resolution on x86_64.

First part of the patch fixes VM helpers for compressed references mode. NULL check should be done against managed_null, not against NULL pointer.

Second part of the patch

1. removes unbalanced runlock statements because otherwise they fire an assertion that register is not locked
2. Implemented is a pass for x86_64 copy of arguments for call_va
3. Switches default resolution mode to lazy

Now there is a remaining bug for calling lazy resolution helpers from gen_invoke. This function first locks "thiz" in some register, which may be required for passing arguments to the resolution helpers helpers that require "this" argument, such is invokevirtual resolution helper. In this case this argument may be overwritten by other arguments.

I didn't start to modify the function to lock CallSig for helper before "thiz" because the whole function has too many branches to follow. Maybe it needs some restructuring.

> [drlvm][jvmti] Workaround for absence of lazy resolution should be removed when it is 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.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.