Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <2012703533.1219725224365.JavaMail.jira@brutus>
Date: Mon, 25 Aug 2008 21:33:44 -0700 (PDT)
From: "George Timoshenko (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-5602) [drlvm][jit][opt][performance]
 nullcheck for a field of boolean type
In-Reply-To: <1097338528.1205383066251.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-5602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625622#action_12625622 ] 

George Timoshenko commented on HARMONY-5602:
--------------------------------------------

Hi,

the idea implemented more or less correctly.
I do not see any obvious lack.

Have you measure the performance effect?
Do I understand correctly, that the optimization works at the first run of peephole that is before the regalloc/spillgen pass?


> [drlvm][jit][opt][performance] nullcheck for a field of boolean type
> --------------------------------------------------------------------
>
>                 Key: HARMONY-5602
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5602
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>            Reporter: George Timoshenko
>            Assignee: Mikhail Fursov
>            Priority: Minor
>         Attachments: movx.patch
>
>
> The problem is reproducible at least for java_lang_ThreadGroup.remove(Ljava_lang_Thread;)V method.
> It contains the following byte codes:
> BYTECODE: GETFIELD        bc-offset=7 (java/lang/ThreadGroup::destroyed)
> BYTECODE: IFEQ        bc-offset=10
> HIR for these two bytecodes is:
> I27:ldflda    [t1.java/lang/ThreadGroup::destroyed] -) t12:ref:bool
> I28:ldind.unc:b   [t12] ((t10,t11)) -) t13:int32
> I29:ldci4     #0 -) t14:int32
> I30:if ceq.i4  t13, t14 goto L4
> As you can see bool value is extended to 32-bit integer type type. (The reason is: 3.3.4 of JVM spec.http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#22909)
> But in the case there are no any other usage of t13. So the comparison can be performed without loading the field from memory to a register.
> (there is no copy propagation because of MOVZX not just a MOV for loading from memory)
> The same problem may persist for all integer fields of less than 32 bits size.

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