-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug](udaf) fix memory leak in the java udaf #32630
Conversation
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
run buildall |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
~AggregateJavaUdafData() { | ||
~AggregateJavaUdafData() = default; | ||
|
||
Status close_and_delete_object() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
warning: method 'close_and_delete_object' can be made static [readability-convert-member-functions-to-static]
Status close_and_delete_object() { | |
static Status close_and_delete_object() { |
TPC-H: Total hot run time: 37798 ms
|
TeamCity be ut coverage result: |
TPC-DS: Total hot run time: 180165 ms
|
Load test result on machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
|
run buildall |
TPC-H: Total hot run time: 38070 ms
|
TeamCity be ut coverage result: |
TPC-DS: Total hot run time: 181824 ms
|
Load test result on machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
fix memory leak in the java udaf
fix memory leak in the java udaf
Proposed changes
before:
if someone call destroy function with place,
when place != _exec_place maybe do nothing ,
when place == _exec_place, do destroy of all place,
as we not want call JNI every times, so will destroy all place at once.
but not call this->data(place).~Data(); this maybe not release the use memory of std::string serialize_data.
Issue Number: close #xxx
Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...