[ 
https://issues.apache.org/jira/browse/FLINK-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952771#comment-16952771
 ] 

Timo Walther commented on FLINK-14398:
--------------------------------------

I assigned it to you [~haodang]. It would be great to not introduce another 
config parameter and avoid splitting in most of the cases for performance 
reasons.

> Codegen produced larger-than-64kb method
> ----------------------------------------
>
>                 Key: FLINK-14398
>                 URL: https://issues.apache.org/jira/browse/FLINK-14398
>             Project: Flink
>          Issue Type: Bug
>          Components: Table SQL / Legacy Planner, Table SQL / Planner
>    Affects Versions: 1.8.0
>            Reporter: Hao Dang
>            Assignee: Hao Dang
>            Priority: Major
>         Attachments: codegen.example.txt
>
>
> In one of our production pipelines, we have a table with 1200+ columns.  At 
> runtime, it failed due to a method inside the generated code exceeding 64kb 
> when compiled to bytecode.
> After we investigated the generated code, it appeared that the *map* method 
> inside a generated *RichMapFunction* was too long. See attached file 
> (codegen.example.txt).
> In the problematic *map* method, *result setters* were correctly split into 
> individual methods and did not have the largest footprint.
> However, there were also 1000+ input unboxing expressions inside 
> *reusableInputUnboxingExprs*, which, individually were not trivial and when 
> flattened linearly in the *map* function 
> [here|https://github.com/apache/flink/blob/release-1.8.0/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/codegen/FunctionCodeGenerator.scala#L187],
>  pushed the method size beyond 64kb in bytecode.
> We think it is worthwhile to split these input unboxing code snippets into 
> individual methods.  We were able to verify, in our production environment, 
> that splitting input unboxing code snippets into individual methods resolves 
> the issue.  Would love to hear thoughts from the team and find the best path 
> to fix it.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to