DRILL-7372: MethodAnalyzer consumes too much memory #1887
Conversation
vvysotskyi
force-pushed
the
DRILL-7372
branch
from
5154c99
to
dbf5680
Compare
vvysotskyi
changed the title
|
|
||
| @Override | ||
| public void clearStack() { | ||
| super.clearStack(); |
There was a problem hiding this comment.
Consider nullification or empty collections re-assignement
vvysotskyi
force-pushed
the
DRILL-7372
branch
from
dbf5680
to
01b3e19
Compare
There was a problem hiding this comment.
@arina-ielchiieva, thanks for the review, I have addressed your comment.
|
|
||
| @Override | ||
| public void clearStack() { | ||
| super.clearStack(); |
|
+1, LGTM. |
|
Just a thought: we proved a couple of years back that the modern JVM does a perfectly fine job of scalar replacement. We also found performance benefits from using "plain Java" without class merging. As a result, our byte code analysis is no longer needed. Just flip one option and we can completely remove this code instead of continuing to maintain it. |
|
@paul-rogers, unfortunately, I didn't see the results of these performance measurements, but I believe that there are some corner cases where our byte code analysis will bring some benefit, for example, when the generated method is too large for JVM optimizations and general time for query execution is much larger compared to the time required for producing scalar replacement and classes merging. |
Jira: DRILL-7372.
Set<Integer>withBitSet- it allowed to reduce heap usage significantly.localVariablesSetandlabelsStackfrom the source frame when a new frame is created since the branch-sensitive analysis was already done for a source frame.