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

Cleanup up and Fixing component creation and deletion #2998

Merged
merged 3 commits into from Nov 22, 2017

Conversation

sithhell
Copy link
Member

This patch contains various fixes related to component registration, creation
and deletion.

The main motivation was to allow direct creation of components without going
through a factory function, disallowing perfect forwarding for local component
creation.

The component registration has been cleaned up, the factory class for creation
and deletion of components has been removed, and the component type registration
has been moved to the component_registry.

The component deletion has been moved out of the runtime_support server, since
no factory is required anymore.

Various other cleanups have been performed leading to an overall reduction in
binary size and removal of various different duplicate code while preserving
existing functionality.

Fixes include:

  • The functionality of component instance counters has been fixed for
    local_new
  • The deletion of components now correctly takes migrated components
    into account
  • The component heap instances are now ensured to live in single module only
    avoiding freeing memory that has been allocated by a different module.

Other flyby changes include some cleanup of the runtime_support server and the component interfaces.

Thomas Heller added 2 commits November 12, 2017 09:43
 - removing operator new/delete overloads
 - removing functions to retreive component types
//
// return type;
// }
// }
Copy link
Member

Choose a reason for hiding this comment

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

Can this be removed?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes.

inline component_type get_component_type()
{
// return detail::get_component_type_impl<
// typename hpx::util::decay<Component>::type>(nullptr);
Copy link
Member

Choose a reason for hiding this comment

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

Can this be removed?

HPX_THROW_EXCEPTION(hpx::unknown_component_address,
"create<Component>",
"can't assign global id");
void *storage = component_heap<Component>().alloc(1);
Copy link
Member

Choose a reason for hiding this comment

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

Does this throw if it fails to allocate memory?

Copy link
Member Author

Choose a reason for hiding this comment

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

It might throw. In the case of an exception, it is propagated up to the caller. This is the same behavior as when the Component ctor throws.

throw;
return naming::invalid_gid;
Copy link
Member

Choose a reason for hiding this comment

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

Why do you need the return?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch.

throw;
return naming::invalid_gid;
Copy link
Member

Choose a reason for hiding this comment

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

Why do you need the return?

{
HPX_ASSERT(parcels_.size() == handlers_.size());
for(std::size_t i = 0; i < parcels_.size(); ++i)
{
handlers_[i](e, parcels_[i]);
handlers_[i].reset();
}
Copy link
Member

Choose a reason for hiding this comment

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

Is this change related to this PR?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not directly... Not sure why I included it. Potentially, it leads to resources being freed in a timelier fashion. I could add it in a different PR if you wish.

}
type = derived_component_type(type, base_type);
// components::enabled(components::get_derived_type(type)) = enabled;
// components::enabled(components::get_base_type(type)) = enabled;
Copy link
Member

Choose a reason for hiding this comment

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

Can this be removed?

using components::stubs::runtime_support;
agas::gva g (addr.locality_, addr.type_, 1, addr.address_);
runtime_support::free_component_sync(g, gid, 1);
naming::address addr(addr_);
Copy link
Member

Choose a reason for hiding this comment

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

Why do you need a local copy?

Copy link
Member Author

Choose a reason for hiding this comment

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

The local copy is needed because agas::is_local_address_cached requires an lvalue.

This patch contains various fixes related to component registration, creation
and deletion.

The main motivation was to allow direct creation of components without going
through a factory function, disallowing perfect forwarding for local component
creation.

The component registration has been cleaned up, the factory class for creation
and deletion of components has been removed, and the component type registration
has been moved to the component_registry.

The component deletion has been moved out of the runtime_support server, since
no factory is required anymore.

Various other cleanups have been performed leading to an overall reduction in
binary size and removal of various different duplicate code while preserving
existing functionality.

Fixes include:
    - The functionality of component instance counters has been fixed for
      local_new
    - The deletion of components now correctly takes migrated components
      into account
    - The component heap instances are now ensured to live in single module only
      avoiding freeing memory that has been allocated by a different module.
@sithhell
Copy link
Member Author

The comments have been addressed.

Copy link
Member

@hkaiser hkaiser left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@sithhell sithhell merged commit ef0d2ab into master Nov 22, 2017
@sithhell sithhell deleted the remove_component_factory branch November 22, 2017 05:19
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.

None yet

2 participants