[
https://issues.apache.org/jira/browse/FLINK-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jark Wu resolved FLINK-14398.
-----------------------------
Fix Version/s: 1.9.2
1.8.3
1.10.0
Resolution: Fixed
1.10.0: 4c87259c1b931318a917eba665a219b63788a735
1.9.2: 7fbada04fdafeb37bb6dc3e023ee502892e2e046
1.8.3: f6b855d9894bc783c760570053719b7a0c830ebb
> Further split input unboxing code into separate methods
> -------------------------------------------------------
>
> 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
> Labels: pull-request-available
> Fix For: 1.10.0, 1.8.3, 1.9.2
>
> Attachments: codegen.example.txt
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> 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)
