drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jinfengni <...@git.apache.org>
Subject [GitHub] drill pull request #818: DRILL-5140: Fix CompileException in run-time genera...
Date Fri, 19 May 2017 20:57:47 GMT
Github user jinfengni commented on a diff in the pull request:

    https://github.com/apache/drill/pull/818#discussion_r117573874
  
    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/expr/ClassGenerator.java
---
    @@ -77,10 +81,43 @@
       private final CodeGenerator<T> codeGenerator;
     
       public final JDefinedClass clazz;
    -  private final LinkedList<SizedJBlock>[] blocks;
    +
       private final JCodeModel model;
       private final OptionSet optionManager;
     
    +  private ClassGenerator<T> innerClassGenerator;
    +  private LinkedList<SizedJBlock>[] blocks;
    +  private LinkedList<SizedJBlock>[] oldBlocks;
    +
    +  /**
    +   * Assumed that field has 3 indexes within the constant pull: index of the CONSTANT_Fieldref_info
+
    --- End diff --
    
    I'm not entirely sure the calculation is correct, in terms of # of entries per field in
constant pool of a class. 
    
    Per JVM spec, each class field has CONSTANT_Fieldref_info (1 entry), which has class_index
and name_and_type_index. The class_index points CONSTANT_Class_info, which is shared by across
all the class fields. The second points to CONSTANT_NameAndType_info (1 entry), which points
to name (1 entry) and descriptor (1 entry). Therefore, for each class field, at least 4 entries
are required in constant pool.  Similarly, we could get 4 entries for each method.
    
    Besides fields and methods, we also have to take constant literal into account, like int,
float , string ... constant. For constant literals, since we apply source-code copy for build-in-function
/udf, it's hard to figure out exactly how many constants are used in the generated class.
    
    Given the above reasons, I'm not sure whether it makes sense to try to come up with a
formula to estimate the maximum # of fields a  generated class could have. If the estimation
is not accurate, then what if we just provides a ballpark estimation and put some 'magic'
number here?   


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message