[
https://issues.apache.org/jira/browse/FLINK-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952676#comment-16952676
]
Hao Dang commented on FLINK-14398:
----------------------------------
Totally agree on a proper design doc for scoping and planning as this is a
fundamental piece of the system. We are happy to help in anyway possible to
push the fix through, as we will be benefiting from it too.
For fixing 1.8.0, would it make sense for us to make a PR to start with? We
can go from there for further discussions. I haven't dig into versions newer
than 1.8.0, thus cannot say for sure if there will be more work needed for
fixing versions post 1.8.0 on top of our existing fix.
Also, excuse me for my greenness here: _what's the difference between the blink
planner vs. the old planner?_
> 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
> 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)
