[janino-dev] [jira] Created: (JANINO-115) Methods that compile to more than 32 KB of bytecode cannot be compiled

Methods that compile to more than 32 KB of bytecode cannot be compiled
----------------------------------------------------------------------

                 Key: JANINO-115
                 URL: http://jira.codehaus.org/browse/JANINO-115
             Project: Janino
          Issue Type: Bug
            Reporter: Matt Fowles
            Assignee: Arno Unkrig
         Attachments: wide-branches.patch

Methods that compile to more than 32 KB of bytecode cannot be compiled.

The attached patch both implements and tests this behavior.  The strategy is as follows:

When a branch requires >32K jump, it expands performing a negated jump as follows:
{code:title=Unexpanded}
[if cond offset]
{code}
expands to
{code:title=Expanded}
[if !cond skip_goto]
[GOTO_W offset]
{code}
\\
\\
\\
As a concrete example,

{code:title=Unexpanded}
IFGT offset
{code}

becomes

{code:title=Expanded}
IFLE 8
GOTO_W offset
{code}

This requires that branches be allowed to change the size of bytecode when relocate() is called.  To account for this, in CodeContext the methods fixup() and relocate() are made private, and a public method fixUpAndRelocate() is added.

The fixUpAndRelocate() method handles check calling fixUpAndRelocate() in a loop while the branches stabilize.  A loop is required because it is theoretically possible for the expansion of a later branch to push an earlier branch over the 32K limit and cause it to switch modes, which would then require it to grow, which could trigger an earlier branch to need to expand...  In practice, the loop will almost always run 1 or 2 iterations (depending on whether anything needed to grow at all).

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135793#action_135793 ]

Arno Unkrig commented on JANINO-115:
------------------------------------

Cool stuff! Will merge it in the next days.

Why do you change Offset.offset from SHORT to INT? We can't go beyond 64K, do we?


CU

Arno

> Methods that compile to more than 32 KB of bytecode cannot be compiled
> ----------------------------------------------------------------------
>
>                 Key: JANINO-115
>                 URL: http://jira.codehaus.org/browse/JANINO-115
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>         Attachments: wide-branches.patch
>
>
> Methods that compile to more than 32 KB of bytecode cannot be compiled.
> The attached patch both implements and tests this behavior.  The strategy is as follows:
> When a branch requires >32K jump, it expands performing a negated jump as follows:
> {code:title=Unexpanded}
> [if cond offset]
> {code}
> expands to
> {code:title=Expanded}
> [if !cond skip_goto]
> [GOTO_W offset]
> {code}
> \\
> \\
> \\
> As a concrete example,
> {code:title=Unexpanded}
> IFGT offset
> {code}
> becomes
> {code:title=Expanded}
> IFLE 8
> GOTO_W offset
> {code}
> This requires that branches be allowed to change the size of bytecode when relocate() is called.  To account for this, in CodeContext the methods fixup() and relocate() are made private, and a public method fixUpAndRelocate() is added.
> The fixUpAndRelocate() method handles check calling fixUpAndRelocate() in a loop while the branches stabilize.  A loop is required because it is theoretically possible for the expansion of a later branch to push an earlier branch over the 32K limit and cause it to switch modes, which would then require it to grow, which could trigger an earlier branch to need to expand...  In practice, the loop will almost always run 1 or 2 iterations (depending on whether anything needed to grow at all).

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135805#action_135805 ]

Matt Fowles commented on JANINO-115:
------------------------------------

You need to use an int so you can track positive values in the range [32K, 64K] and negative values in the range [-32k, -64k].  Also, it simplifies a bunch of code all over, as you don't have to mask off the sign bit everywhere.

> Methods that compile to more than 32 KB of bytecode cannot be compiled
> ----------------------------------------------------------------------
>
>                 Key: JANINO-115
>                 URL: http://jira.codehaus.org/browse/JANINO-115
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>         Attachments: wide-branches.patch
>
>
> Methods that compile to more than 32 KB of bytecode cannot be compiled.
> The attached patch both implements and tests this behavior.  The strategy is as follows:
> When a branch requires >32K jump, it expands performing a negated jump as follows:
> {code:title=Unexpanded}
> [if cond offset]
> {code}
> expands to
> {code:title=Expanded}
> [if !cond skip_goto]
> [GOTO_W offset]
> {code}
> \\
> \\
> \\
> As a concrete example,
> {code:title=Unexpanded}
> IFGT offset
> {code}
> becomes
> {code:title=Expanded}
> IFLE 8
> GOTO_W offset
> {code}
> This requires that branches be allowed to change the size of bytecode when relocate() is called.  To account for this, in CodeContext the methods fixup() and relocate() are made private, and a public method fixUpAndRelocate() is added.
> The fixUpAndRelocate() method handles check calling fixUpAndRelocate() in a loop while the branches stabilize.  A loop is required because it is theoretically possible for the expansion of a later branch to push an earlier branch over the 32K limit and cause it to switch modes, which would then require it to grow, which could trigger an earlier branch to need to expand...  In practice, the loop will almost always run 1 or 2 iterations (depending on whether anything needed to grow at all).

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136095#action_136095 ]

Arno Unkrig commented on JANINO-115:
------------------------------------

Ah yes, you're right. Actually, code attributes could grow up to 2G, with the restriction that no exception table entries (TRY CATCH FINALLY, SYNCHRONIZED) must appear beyond offset 64K, and no line number info and local variable info can be given after offset 64K.

> Methods that compile to more than 32 KB of bytecode cannot be compiled
> ----------------------------------------------------------------------
>
>                 Key: JANINO-115
>                 URL: http://jira.codehaus.org/browse/JANINO-115
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>         Attachments: wide-branches.patch
>
>
> Methods that compile to more than 32 KB of bytecode cannot be compiled.
> The attached patch both implements and tests this behavior.  The strategy is as follows:
> When a branch requires >32K jump, it expands performing a negated jump as follows:
> {code:title=Unexpanded}
> [if cond offset]
> {code}
> expands to
> {code:title=Expanded}
> [if !cond skip_goto]
> [GOTO_W offset]
> {code}
> \\
> \\
> \\
> As a concrete example,
> {code:title=Unexpanded}
> IFGT offset
> {code}
> becomes
> {code:title=Expanded}
> IFLE 8
> GOTO_W offset
> {code}
> This requires that branches be allowed to change the size of bytecode when relocate() is called.  To account for this, in CodeContext the methods fixup() and relocate() are made private, and a public method fixUpAndRelocate() is added.
> The fixUpAndRelocate() method handles check calling fixUpAndRelocate() in a loop while the branches stabilize.  A loop is required because it is theoretically possible for the expansion of a later branch to push an earlier branch over the 32K limit and cause it to switch modes, which would then require it to grow, which could trigger an earlier branch to need to expand...  In practice, the loop will almost always run 1 or 2 iterations (depending on whether anything needed to grow at all).

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136096#action_136096 ]

Arno Unkrig commented on JANINO-115:
------------------------------------

Will go into the next version of JANINO.

> Methods that compile to more than 32 KB of bytecode cannot be compiled
> ----------------------------------------------------------------------
>
>                 Key: JANINO-115
>                 URL: http://jira.codehaus.org/browse/JANINO-115
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>         Attachments: wide-branches.patch
>
>
> Methods that compile to more than 32 KB of bytecode cannot be compiled.
> The attached patch both implements and tests this behavior.  The strategy is as follows:
> When a branch requires >32K jump, it expands performing a negated jump as follows:
> {code:title=Unexpanded}
> [if cond offset]
> {code}
> expands to
> {code:title=Expanded}
> [if !cond skip_goto]
> [GOTO_W offset]
> {code}
> \\
> \\
> \\
> As a concrete example,
> {code:title=Unexpanded}
> IFGT offset
> {code}
> becomes
> {code:title=Expanded}
> IFLE 8
> GOTO_W offset
> {code}
> This requires that branches be allowed to change the size of bytecode when relocate() is called.  To account for this, in CodeContext the methods fixup() and relocate() are made private, and a public method fixUpAndRelocate() is added.
> The fixUpAndRelocate() method handles check calling fixUpAndRelocate() in a loop while the branches stabilize.  A loop is required because it is theoretically possible for the expansion of a later branch to push an earlier branch over the 32K limit and cause it to switch modes, which would then require it to grow, which could trigger an earlier branch to need to expand...  In practice, the loop will almost always run 1 or 2 iterations (depending on whether anything needed to grow at all).

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://jira.codehaus.org/browse/JANINO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles resolved JANINO-115.
--------------------------------

    Resolution: Fixed

> Methods that compile to more than 32 KB of bytecode cannot be compiled
> ----------------------------------------------------------------------
>
>                 Key: JANINO-115
>                 URL: http://jira.codehaus.org/browse/JANINO-115
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>         Attachments: wide-branches.patch
>
>
> Methods that compile to more than 32 KB of bytecode cannot be compiled.
> The attached patch both implements and tests this behavior.  The strategy is as follows:
> When a branch requires >32K jump, it expands performing a negated jump as follows:
> {code:title=Unexpanded}
> [if cond offset]
> {code}
> expands to
> {code:title=Expanded}
> [if !cond skip_goto]
> [GOTO_W offset]
> {code}
> \\
> \\
> \\
> As a concrete example,
> {code:title=Unexpanded}
> IFGT offset
> {code}
> becomes
> {code:title=Expanded}
> IFLE 8
> GOTO_W offset
> {code}
> This requires that branches be allowed to change the size of bytecode when relocate() is called.  To account for this, in CodeContext the methods fixup() and relocate() are made private, and a public method fixUpAndRelocate() is added.
> The fixUpAndRelocate() method handles check calling fixUpAndRelocate() in a loop while the branches stabilize.  A loop is required because it is theoretically possible for the expansion of a later branch to push an earlier branch over the 32K limit and cause it to switch modes, which would then require it to grow, which could trigger an earlier branch to need to expand...  In practice, the loop will almost always run 1 or 2 iterations (depending on whether anything needed to grow at all).

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

    [ http://jira.codehaus.org/browse/JANINO-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138757#action_138757 ]

Matt Fowles commented on JANINO-115:
------------------------------------

Arno, I do not have the ability to close this issue.  I think my login to Jira does not have the power.  You can consider this closed.

> Methods that compile to more than 32 KB of bytecode cannot be compiled
> ----------------------------------------------------------------------
>
>                 Key: JANINO-115
>                 URL: http://jira.codehaus.org/browse/JANINO-115
>             Project: Janino
>          Issue Type: Bug
>            Reporter: Matt Fowles
>            Assignee: Arno Unkrig
>         Attachments: wide-branches.patch
>
>
> Methods that compile to more than 32 KB of bytecode cannot be compiled.
> The attached patch both implements and tests this behavior.  The strategy is as follows:
> When a branch requires >32K jump, it expands performing a negated jump as follows:
> {code:title=Unexpanded}
> [if cond offset]
> {code}
> expands to
> {code:title=Expanded}
> [if !cond skip_goto]
> [GOTO_W offset]
> {code}
> \\
> \\
> \\
> As a concrete example,
> {code:title=Unexpanded}
> IFGT offset
> {code}
> becomes
> {code:title=Expanded}
> IFLE 8
> GOTO_W offset
> {code}
> This requires that branches be allowed to change the size of bytecode when relocate() is called.  To account for this, in CodeContext the methods fixup() and relocate() are made private, and a public method fixUpAndRelocate() is added.
> The fixUpAndRelocate() method handles check calling fixUpAndRelocate() in a loop while the branches stabilize.  A loop is required because it is theoretically possible for the expansion of a later branch to push an earlier branch over the 32K limit and cause it to switch modes, which would then require it to grow, which could trigger an earlier branch to need to expand...  In practice, the loop will almost always run 1 or 2 iterations (depending on whether anything needed to grow at all).

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email