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

Refactor: BMI adapters' virtual destructor hierarchy and general cleanup #750

Merged
merged 16 commits into from
Mar 25, 2024

Conversation

program--
Copy link
Contributor

@program-- program-- commented Feb 29, 2024

This PR resolves #747 by pulling the virtual destructor hierarchy one level above AbstractCLibBmiAdapter, so that Bmi_Adapter defines a virtual destructor.

Moreover, this PR includes some additional cleanup of the BMI adapter classes and supporting files.

Additions

  • Adds a default virtual destructor to Bmi_Adapter.
  • Adds an overridden destructor to Bmi_Py_Adapter.
  • Adds source files for AbstractCLibBmiAdapter and Bmi_Adapter.

Changes

  • Reworks Bmi listfile to remove call to dynamically sourced library, and instead manually creates the CMake target to handle conditional compilation properly.
  • Replaces virtual destructor attribute with override in subclasses of Bmi_Adapter and AbstractCLibBmiAdapter.
  • Updates and sorts include directives in header and source files.

Checklist

  • PR has an informative and human-readable title
  • Changes are limited to a single goal (no scope creep)
  • Code can be automatically merged (no conflicts)
  • Code follows project standards (link if applicable)
  • Passes all existing automated tests
  • Any change in functionality is tested
  • New functions are documented (with a description, list of inputs, and expected output)
  • Placeholder code is flagged / future todos are captured in comments
  • Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
  • Reviewers requested with the Reviewers tool ➡️

Target Environment support

  • Linux
  • macOS

@program-- program-- added the bug Something isn't working label Feb 29, 2024
@program-- program-- self-assigned this Feb 29, 2024
@program-- program-- marked this pull request as ready for review February 29, 2024 18:38
Copy link
Contributor Author

@program-- program-- left a comment

Choose a reason for hiding this comment

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

Added some review comments to help guide review and clarify design decisions. 😄

include/bmi/AbstractCLibBmiAdapter.hpp Show resolved Hide resolved

private:

/** Path to the BMI shared library file, for dynamic linking. */
std::string bmi_lib_file;
/** Name of the function that registers BMI struct's function pointers to the right module functions. */
const std::string bmi_registration_function;
std::string bmi_registration_function;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed const specifier, since it isn't necessary here. Really, the getter for this should be const instead.

Copy link
Member

Choose a reason for hiding this comment

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

Agree the getter could be marked const, but that would prevent future code added to the class from trying to change the bmi_registration_function, perhaps even inadvertently, which could lead to unexpected behavior. I guess I'm trying to say, it doesn't hurt to be overly pedantic in these cases where we want the compiler to help with validation as much as possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted in 4f83059

include/bmi/Bmi_Adapter.hpp Outdated Show resolved Hide resolved
include/bmi/Bmi_Py_Adapter.hpp Show resolved Hide resolved
src/bmi/AbstractCLibBmiAdapter.cpp Outdated Show resolved Hide resolved
Comment on lines -1 to -2
include(${PROJECT_SOURCE_DIR}/cmake/dynamic_sourced_library.cmake)
dynamic_sourced_cxx_library(ngen_bmi "${CMAKE_CURRENT_SOURCE_DIR}")
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Dynamic sourcing is being removed because we should aim to eventually get rid of it completely. Conditional compilation is better managed by the build system rather than in the C++ files themselves, but this dynamic sourcing is preventing that from happening.

Comment on lines 195 to 205
inline void *dynamic_load_symbol(const std::string &symbol_name) {
return dynamic_load_symbol(symbol_name, false);
}
void *dynamic_load_symbol(const std::string &symbol_name);

inline const std::string &get_bmi_registration_function() {
return bmi_registration_function;
}
const std::string &get_bmi_registration_function();

inline const void *get_dyn_lib_handle() {
return dyn_lib_handle;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could've replaced inline with __attribute__((always_inline)) here instead to get the intended behavior, but opted to move definitions to a source file instead because it probably isn't worth it currently.

Copy link
Member

Choose a reason for hiding this comment

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

I would consider keeping at least these three small, simple functions in the header and marked inline. They are relatively simple wrapper functions which are used for each adapter and at scale (800k calls at initialization of conus) could save some overhead in intialization. The library load and load symbol functions are more complex, and inlining them would likely have some similar initializaiton optimizations avoiding additional function calls in setting up the adapters. I don't think these are called from many different places, so the resulting binary size and build times should be minimal.
We may want to at least profile some large init times and see what the overhead in intialization is from NOT inlining these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted in 7fc98b0

@PhilMiller
Copy link
Contributor

I'm trying to take a look at the ASan failure in the unit test. Needing to update some software locally to do that.

@PhilMiller
Copy link
Contributor

Ok, finally re-ran the tests locally with ASan, and didn't see the failure. Going to need some more investigation, I guess.

I may try backing out the very last commit, and see if that changes things

@program--
Copy link
Contributor Author

program-- commented Mar 15, 2024

Ok, finally re-ran the tests locally with ASan, and didn't see the failure. Going to need some more investigation, I guess.

I may try backing out the very last commit, and see if that changes things

I'm having the same experience. I don't get any ASan errors locally. As a note, it seems master is also experiencing the ASan issues (and PR #720).

@PhilMiller
Copy link
Contributor

The ASan failures may be a transient thing due to weird configuration on Github's CI runners. In particular, ASan functionally requires that ASLR not be disabled, because there's certain ELF loading behavior in the Linux kernel that only happens with ASLR enabled. I pushed on that getting fixed about a decade ago, for other reasons, but never got anywhere.

The upshot is that we may see the test start passing if we re-run it again tomorrow.

PhilMiller
PhilMiller previously approved these changes Mar 22, 2024
@PhilMiller PhilMiller assigned hellkite500 and unassigned program-- Mar 22, 2024
@hellkite500 hellkite500 merged commit 9758d43 into NOAA-OWP:master Mar 25, 2024
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BMI adapter destructors are not entirely virtual
3 participants