harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-5016) [drlvm][jit][opt] code patching may corrupt calls to helpers on x86-64 in OPT mode
Date Thu, 25 Oct 2007 13:50:50 GMT

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

Alexey Varlamov updated HARMONY-5016:

    Summary: [drlvm][jit][opt] code patching may corrupt calls to helpers on x86-64 in OPT
mode  (was: [jit][opt] Incorrect JITed code generates in OPT mode with large heap on Linux

Simple workaround is possible, always reserve space for direct call patching (currently it
is not done for helper calls). Apparent drawback is increased code size, more accurate solution
requires pre-calculating size of emitted code and making direct/indirect call decision during
main emission pass.

> [drlvm][jit][opt] code patching may corrupt calls to helpers on x86-64 in OPT mode
> ----------------------------------------------------------------------------------
>                 Key: HARMONY-5016
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5016
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux x86-64
>            Reporter: Pavel Afremov
>            Assignee: Alexey Varlamov
>            Priority: Critical
> On Linux x86-64, DRL VM crashed by assert of null allocation handler (second parametr)
in fast_gc_alloc.
> It called from JITed code 
> at org.apache.harmony.kernel.vm.VM.<clinit>
>  ...\drlvm\vm\vmcore\src\kernel_classes\javasrc\org\apache\harmony\kernel\vm\VM.java
ln 120
> internedStrings = new InternMap(32768);
> The source of the bug is in folowing:
> 1.	If ofset between callee and caller fits in 32 bits signed value, OPT generates following
> 0x00002aab0b490000:     push   %rbx
> 0x00002aab0b490001:     mov    $0x90edf5,%rbx
> 0x00002aab0b49000b:     movb   $0x0,(%rbx)
> 0x00002aab0b49000e:     mov    $0x90edf4,%rbx
> 0x00002aab0b490018:     movb   $0x0,(%rbx)
> 0x00002aab0b49001b:     mov    $0x20,%edi
> 0x00002aab0b490020:     mov    $0x2c68,%rsi
> 0x00002aab0b49002a:     callq  0x2aaaac2bf950
> 2.	If offset more then 32 bits signed value OPT generates following code:
> 0x00002aab49c90000:     push   %rbx
> 0x00002aab49c90001:     mov    $0x9665e5,%rbx
> 0x00002aab49c9000b:     movb   $0x0,(%rbx)
> 0x00002aab49c9000e:     mov    $0x9665e4,%rbx
> 0x00002aab49c90018:     movb   $0x0,(%rbx)
> 0x00002aab49c9001b:     mov    $0x20,%edi
> 0x00002aab49c90020:     mov    $0x2aaaac2bf950,%r11
> 0x00002aab49c9002a:     data16
> 0x00002aab49c9002b:     nop
> 0x00002aab49c9002c:     rex64Z callq  *%r11
> In this code second parameter is missed, rsi is not initialized, and fast_gc_alloc  asserts
by this reason.
> I think that this bug can be reproduced on any x86-64 platform, both Linux and Windows.
> But I can reproduce it on Linux x86-64 machine only.
> To reproduce the bug, run any class or test in OPT mode with large heap on Linux x86-64
debug build, like in following command:
> .../jdk/jre/bin/java -Xem:opt -Xmx3500m Hi
> DRLVM in JET mode works OK.

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

View raw message