Skip to content
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

[DS-108][DS-109] Cache object code on memory and enable memory tracking #6

Open
wants to merge 32 commits into
base: master
Choose a base branch
from

Conversation

augustoasilva
Copy link

The task DS-108 and DS-109 was pushed together because they complement each other

cpp/src/gandiva/base_cache_key.h Outdated Show resolved Hide resolved
cpp/src/gandiva/base_cache_key.h Outdated Show resolved Hide resolved
cpp/src/gandiva/base_cache_key.h Outdated Show resolved Hide resolved
cpp/src/gandiva/base_cache_key.h Outdated Show resolved Hide resolved
cpp/src/gandiva/cache.cc Outdated Show resolved Hide resolved
cpp/src/gandiva/tests/projector_test.cc Outdated Show resolved Hide resolved
cpp/src/gandiva/tests/projector_test.cc Outdated Show resolved Hide resolved
cpp/src/gandiva/tests/projector_test.cc Outdated Show resolved Hide resolved
cpp/src/gandiva/tests/projector_test.cc Outdated Show resolved Hide resolved
cpp/src/gandiva/tests/projector_test.cc Outdated Show resolved Hide resolved
@anthonylouisbsb
Copy link

I noticed that you changed some asserts in existing tests, but I did not see any new tests. The existing ones already cover all changes you made?

@anthonylouisbsb
Copy link

Also, I noticed some formatting errors in your code, do not forget to run the cpp code formatted before open the PR to the main repository

@augustoasilva augustoasilva force-pushed the feature/cache-object-code-on-memory-and-enable-memory-tracking branch from e9505c3 to 6474465 Compare September 1, 2021 22:48
@augustoasilva augustoasilva force-pushed the feature/cache-object-code-on-memory-and-enable-memory-tracking branch from 7a65334 to c6ed351 Compare September 2, 2021 23:53
@@ -18,7 +18,7 @@
# workaround for https://issues.apache.org/jira/browse/ARROW-13134
aws-sdk-cpp<1.9
benchmark>=1.5.4
boost-cpp>=1.68.0
boost-cpp>=1.68.0,<1.77.0
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this change required?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because in one of the builds, the version 1.77 will break as some of the boost libs on v1.77 will use C++17.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should fix the build. This change won't be allowed in master i think. and there are plans to move to c++17 anyway

Copy link
Author

@augustoasilva augustoasilva Sep 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@projjal the error was:

 /opt/conda/envs/arrow/include/boost/process/detail/traits/wchar_t.hpp: In static member function 'static std::vector<std::__cxx11::basic_string<wchar_t> > boost::process::detail::char_converter<wchar_t, std::vector<std::__cxx11::basic_string<char> > >::conv(const std::vector<std::__cxx11::basic_string<char> >&)':
/opt/conda/envs/arrow/include/boost/process/detail/traits/wchar_t.hpp:150:14: error: 'transform' is not a member of 'std'
  150 |         std::transform(in.begin(), in.end(), ret.begin(),

You can see it here: https://github.com/s1mbi0se/arrow/runs/3500727130

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doesn't the failure look like something to do with arrow-flight?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, but when I was searching about the error itself and the transform in the STL, I discovered that the cause of this issue was about the C++17 version, and looking at the Cmake files I saw that arrow fully support by default the C++11.

Also, limiting the maximum boost version to up to 1.76 version does not appear to me to be a big issue.

So, what approach do you recomed to do?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't change these settings without a proper reasoning. The run you linked runs with c++17 so i believe its expected to pass with c++17. For now first find the root cause why its failing. If it is not related to this pr then it should fail in master too

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@projjal I updated again with master, and this error was gone, so I changed back this file to the master version

@@ -138,6 +168,8 @@ class GANDIVA_EXPORT Projector {
SchemaPtr schema_;
FieldVector output_fields_;
std::shared_ptr<Configuration> configuration_;
bool compiled_from_cache_;
static size_t used_cache_size_;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is it static?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is static so all the projector will use the same var to keep track of all projectors' memory consumption. But now, I'm thinking to remove it and only keep tracking of the global used memory by the cache, instead of both tracking.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed it as it will no longer be used.

@@ -110,6 +114,25 @@ class GreedyDualSizeCache {
}
}

void InsertObjectCode(const Key& key, const ValueCacheObject<Value>& value) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are you adding these new methods?

Copy link
Author

@augustoasilva augustoasilva Sep 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These methods was added just to preserve the old ones so I can benchmak switching between them instead of switching the project branchs, I plan to change the old ones when moving the poc to the arrow PR.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remove them now since you already benchmarked?

const char* env_cache_size = std::getenv("GANDIVA_CACHE_SIZE");
if (env_cache_size != nullptr) {
capacity = std::atoi(env_cache_size);
capacity = std::stoul(env_cache_size);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this change required?

Copy link
Author

@augustoasilva augustoasilva Sep 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In atoi, if no conversion happens, because of an invalid argument or it falls out of range, the value will assume the zero value, in stoul if there is a problem it will throw an excpetion leading to a better error management.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

atoi was specifically added because it doesn't throw exception. The zero case is handled in next line.
Also in this change you are not catching the exception so the change is incorrect. Better just undo this change.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I changed it back.

#include "gandiva/llvm_generator.h"

namespace gandiva {

class ProjectorCacheKey {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason why moved this class to projector.h?

Copy link
Author

@augustoasilva augustoasilva Sep 8, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it was giving me some circular dependency error, so to avoid it I moved it to the projector.h. The FilterCacheKey also is in the filter.h, so I thought it was no issue to move ProjectorCacheKey to projector.h

The circular error was, when using the ProjectorCacheKey into BaseCacheKey, and them using the BaseCacheKey into Projector, as ProjectorCacheKey was in the projector.cc file it became a circular dependency when I called to import projector.cc into base_cache_key, and the in projector.cc import the base_cache_key file

ARROW_LOG(WARNING) << "[OBJ-CACHE-LOG][ERROR]: "
<< execution_engine_->getErrorMessage();
module_finalized_ = false;
return Status::OK();
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why return status::OK in case of error?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My mistake, sorry, I will fix that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it.

#include <arrow/util/hash_util.h>
#include <stddef.h>

#include <boost/lexical_cast.hpp>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is it needed here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not, I was trying an approach to use boost::any for the cache, and forgot to clean this one to. I already fixed.

@augustoasilva augustoasilva force-pushed the feature/cache-object-code-on-memory-and-enable-memory-tracking branch from 61aadbc to 553e86c Compare September 8, 2021 23:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants