drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Rogers (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (DRILL-5070) Code gen: create methods in fixed order to allow test verification
Date Mon, 28 Nov 2016 15:27:58 GMT

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

Paul Rogers updated DRILL-5070:
    Comment: was deleted

(was: Analysis of impact. Method order is random. If a generated class has n method, then
there are n! possible orderings, and the cache holds up to n! different variations when one
would do. Reduction in each size for various method counts (assuming each variation ends up
being cached):

* 2 methods: 1/2
* 3 methods: 1/6
* 4 methods: 1/24

That is, a class with 3 methods will store 1/6 the number of variations after the fix as before.

Since the cache is cluttered with fewer functionally duplicate classes, more room will be
available to preserve other classes, potentially further reducing the amount of compilation

> Code gen: create methods in fixed order to allow test verification
> ------------------------------------------------------------------
>                 Key: DRILL-5070
>                 URL: https://issues.apache.org/jira/browse/DRILL-5070
>             Project: Apache Drill
>          Issue Type: Bug
>    Affects Versions: 1.8.0
>            Reporter: Paul Rogers
>            Priority: Minor
> A handy technique in testing is to compare generated code against a "golden" copy that
defines the expected results. However, at present, Drill generates code using the method order
returned by {{Class.getDeclaredMethods}}, but this method makes no guarantee about the order
of the methods. The order varies from one run to the next. There is some evidence [this link|http://stackoverflow.com/questions/28585843/java-reflection-getdeclaredmethods-in-declared-order-strange-behaviour]
that order can vary even within a single run, though a quick test was unable to reproduce
this case.
> If method order does indeed vary within a single run, then the order can impact the Drill
code cache since it compares the sources from two different generation events to detect duplicate
> This issue appeared when attempting to modify tests to capture generated code for comparison
to future results. Even a simple generated case from {{ExpressionTest.testBasicExpression()}}
that generates {{if(true) then 1 else 0 end}} (all constants) produced methods in different
orders on each test run.
> The fix is simple, in the {{SignatureHolder}} constructor, sort methods by name after
retrieving them from the class. The sort ensures that method order is deterministic. Fortunately,
the number of methods is small, so the sort step adds little cost.

This message was sent by Atlassian JIRA

View raw message