impl/lola: Added shm-size calculation by analysis for DATA/CONTROL by crimson11 · Pull Request #760 · eclipse-score/communication

crimson11 · 2026-07-23T20:12:00Z

Currently we determine shm-sizes of the
CTRL and DATA shm-objects by a simulation run.
I.e. we initialize the content of both section
1st within a heap-allocated resource. At the end
we use the sizes to correctly size the shm-objects. This "SIMULATION" method is exact but has high runtime costs and might consume lots of memory during startup.

This change now redesigns the containers/dynamic data types being used within the DATA section, to use only classes, which we are in control of and where we exactly know based on our configuration, who much size they will need. Thus the whole simulation canbe skipped and we calculate the size correctly from the configuration settins for the service instance.

We re-introduce therefore the ESTIMATION mode in parallel to the SIMULATION mode.

Tackles issue #761

castler · 2026-07-24T07:20:32Z

 enum class ShmSizeCalculationMode : std::uint8_t
 {
    kSimulation,
+    kEstimation,


This is no longer an estimation - this is now an calculation! We should be clear in the wording.

bemerybmw · 2026-07-28T14:51:09Z

+/// \brief A fixed-capacity, associative container with a std::map-like interface backed by a contiguous array.
+///
+/// \details LinearSearchMap replaces the previously used std::map / boost::interprocess::map inside the shared-memory
+/// data structures (e.g. ServiceDataStorage). Those map-types allocate memory dynamically on each insertion which makes


Suggested change

/// data structures (e.g. ServiceDataStorage). Those map-types allocate memory dynamically on each insertion which makes

/// data structures (e.g. ServiceDataStorage). Those map-types allocate memory dynamically on each insertion (the exact amount depends on the implementation) which makes

bemerybmw · 2026-07-28T14:54:52Z

+template <typename Key,
+          typename MappedType,
+          typename KeyEqual = std::equal_to<Key>,
+          typename Allocator = memory::shared::PolymorphicOffsetPtrAllocator<std::pair<Key, MappedType>>>


Should have scoped_allocator_adaptor?

bemerybmw · 2026-07-28T14:56:33Z

+        return key_equal_;
+    }
+
+    mapped_type& at(const Key& key)


Suggested change

mapped_type& at(const Key& key)

mapped_type& at(const Key& key)&

I think this should have the trailing & so that it can't be called on a temporary(would lead to a dangling reference).

Hm. I'm not convinced ;) Why?

we resemble a std::map interface here! map doesn't lvalue qualify at() neither. This confuses imho.

then I would need to be consistent! Also would have to add it o plenty of other methods! Like begin()/end() etc. they are all returning iterators/pointers which may be dangling in case of a temporary ...

bemerybmw · 2026-07-28T14:57:53Z

+    /// \param max_number_of_elements maximum number of elements the map can hold (its fixed capacity).
+    /// \param resource memory resource used to allocate the underlying storage.
+    /// \param key_equal binary predicate used to compare keys for equality.
+    LinearSearchMap(const size_type max_number_of_elements,


IMO, the definition of these functions should all be below. The declaration of the class should ideally fit in one screen (or a little bit of scrolling). But as it is now, it's quite hard to read the interface of this class.

bemerybmw · 2026-07-28T14:59:47Z

+    {
+    }
+
+    iterator begin() noexcept


Shouldn't be noexcept (unless this is about be compliant with some standard container specification)

At least map/unordered_map have noexcept spec ... so I took it over.

bemerybmw · 2026-07-29T07:12:28Z

      storage_{nullptr},
      control_qm_{nullptr},
      control_asil_b_{nullptr},
+      number_of_service_elements_{0U},


This should be a std::optional to ensure that we don't access it before it's set in CreateSharedMemory

bemerybmw · 2026-07-29T07:16:53Z

    return ShmResourceStorageSizes{control_data_size, control_qm_size, control_asil_b_size};
 }

+namespace


The anonymous namespace should go at the top of the file (to match the rest of the code base)

bemerybmw · 2026-07-29T07:19:07Z

+// alignof(std::max_align_t) we keep the running offset max-aligned and therefore obtain a size that is guaranteed to be
+// sufficient (it is exact whenever the allocated sizes are multiples of the involved alignment, which is the common
+// case).
+constexpr std::size_t RoundUpToMaxAlign(const std::size_t size) noexcept


This is a duplicate of CalculateAlignedSize?

Yes! Somewhat! I repaced with CalculateAlignedSize(size, kMaxAlignedSize)

bemerybmw · 2026-07-29T07:22:44Z

+    {
+        const auto field_it = lola_service_instance_deployment_.fields_.find(name);
+        SCORE_LANGUAGE_FUTURECPP_ASSERT_PRD_MESSAGE(field_it != lola_service_instance_deployment_.fields_.cend(),
+                                                    "Could not find field in deployment configuration.");


The message should not just be repeating what the check is in words. It should either be explaining why the assertion is checked / expected or just omit it. It's not adding any new information here. Same for the other assertions

bemerybmw · 2026-07-29T07:29:56Z

+    return total_size;
+}
+
+std::size_t SkeletonMemoryManager::GetNumberOfSampleSlotsFromConfig(const std::string_view service_element_name,


What about something like this to avoid code duplication?

template <ServiceElementType ServiceElementType> std::size_t SkeletonMemoryManager::GetNumberOfSampleSlotsFromConfig(const std::string_view service_element_name) const { SCORE_LANGUAGE_FUTURECPP_PRECONDITION(ServiceElementType == ServiceElementType::EVENT || ServiceElementType == ServiceElementType::FIELD); const auto& lola_service_element_deployment = [this, service_element_name]() { if constexpr (ServiceElementType == ServiceElementType::EVENT) { return lola_service_instance_deployment_.events_.at(std::string{service_element_name}); } else { return lola_service_instance_deployment_.fields_.at(std::string{service_element_name}) .lola_event_instance_deployment_; } }(); const std::string name{service_element_name}; const auto field_it = lola_service_element_deployment.fields_.find(name); SCORE_LANGUAGE_FUTURECPP_ASSERT_PRD_MESSAGE(field_it != lola_service_instance_deployment_.fields_.cend(), "Could not find field in deployment configuration."); const auto number_of_slots = field_it->second.lola_event_instance_deployment_.GetNumberOfSampleSlots(); SCORE_LANGUAGE_FUTURECPP_ASSERT_PRD_MESSAGE(number_of_slots.has_value(), "Number of sample slots not specified for field."); return number_of_slots.value(); }

Same for GetMaxSubscribersFromConfig

Hm. I'm not convinced. Just compare the src-code sizes. It is not really much less source-code and the original was also "easy" to grasp imho. Now you are templating it and in reality we will have larger code-size, because we have now the impl. instantiated twice ... and as I said - the new impl. still has a cosnstexpr if-else, which makes the code not really simpler?

If you still insist -> I can change ;)

The type DataTypeMetaInfo, which we use on our public interface is too weak! It doesn't assure invariants on size/alignment, which C++ demands: size has to be always a power of two and be an integer multiple of tzhe alignment. This commit switches to internal use of memory::DataTypeSizeInfo which forces this. On the public interface we keep the weak DataTypeMetaInfo for now to avoid a breaking change! In the public layer we transform DataTypeMetaInfo to DataTypeSizeInfo. In case this isn't possible because DataTypeMetaInfo is invalid, we return an error in the public API.

Currently we determine shm-sizes of the CTRL and DATA shm-objects by a simulation run. I.e. we initialize the content of both section 1st within a heap-allocated resource. At the end we use the sizes to correctly size the shm-objects. This "SIMULATION" method is exact but has high runtime costs and might consume lots of memory during startup. This change now redesigns the containers/dynamic data types being used within the DATA section, to use only classes, which we are in control of and where we exactly know based on our configuration, who much size they will need. Thus the whole simulation canbe skipped and we calculate the size correctly from the configuration settins for the service instance. We re-introduce therefore the ESTIMATION mode in parallel to the SIMULATION mode.

Added analytical estimate/ANALYSIS mode for the shm-size calculation for the CONTROL section.

Adapted signature of LinearSearchMap to support custom KeqEqual just like std::unordered_map.

In the skeleton component tests we were testing the lola::Skeleton with a event and field service element. But we only provided the config/ deployment info for these elements, but did never register them at their parent Skeleton. Thus, essential tests checking the shm-size calculation were off! The tests now correctly register the elements.

Fixed review comments for ne ANALYSIS based size calculations. Added unit test for parsing of new ANALYSIS mode.

Moved the shm-size calc for ServiceDataStorage and ServiceDataControl out of SkeletonMemoryManager to the correspoinding data structures itself.

crimson11 requested review from LittleHuba, bemerybmw, castler, hoe-jo and limdor as code owners July 23, 2026 20:12

github-project-automation Bot added this to COM - Communication FT Jul 23, 2026

github-project-automation Bot moved this to Backlog in COM - Communication FT Jul 23, 2026

crimson11 force-pushed the mf_new_shm_size_calculation branch from c72a678 to a090932 Compare July 23, 2026 21:01

crimson11 changed the title ~~impl/lola: Added shm-size calc for CTRL~~ impl/lola: Added shm-size calc by estimation for DATA/CONTROL Jul 23, 2026

crimson11 force-pushed the mf_new_shm_size_calculation branch from a090932 to 59cd98d Compare July 23, 2026 21:24

castler reviewed Jul 24, 2026

View reviewed changes

crimson11 force-pushed the mf_new_shm_size_calculation branch from 59cd98d to e088dba Compare July 24, 2026 09:46

crimson11 requested a review from castler July 24, 2026 09:57

castler changed the title ~~impl/lola: Added shm-size calc by estimation for DATA/CONTROL~~ impl/lola: Added shm-size calculation for DATA/CONTROL Jul 27, 2026

castler changed the title ~~impl/lola: Added shm-size calculation for DATA/CONTROL~~ impl/lola: Added shm-size calculation by analysis for DATA/CONTROL Jul 27, 2026

anmittag assigned crimson11 Jul 29, 2026

bemerybmw requested changes Jul 29, 2026

View reviewed changes

bemerybmw self-assigned this Jul 29, 2026

crimson11 added 7 commits July 30, 2026 16:10

impl/lola: Added shm-size calc for CTRL

5b79779

Added analytical estimate/ANALYSIS mode for the shm-size calculation for the CONTROL section.

impl/lola: Refine LinearSearchMap

40b40c8

Adapted signature of LinearSearchMap to support custom KeqEqual just like std::unordered_map.

impl/lola: Fixed review comments

78ae66d

Fixed review comments for ne ANALYSIS based size calculations. Added unit test for parsing of new ANALYSIS mode.

com/impl/lola: Refactor shm-size-calc

4c24cbc

Moved the shm-size calc for ServiceDataStorage and ServiceDataControl out of SkeletonMemoryManager to the correspoinding data structures itself.

crimson11 force-pushed the mf_new_shm_size_calculation branch from 6c3c9cf to 4c24cbc Compare July 30, 2026 19:52

	/// data structures (e.g. ServiceDataStorage). Those map-types allocate memory dynamically on each insertion which makes
	/// data structures (e.g. ServiceDataStorage). Those map-types allocate memory dynamically on each insertion (the exact amount depends on the implementation) which makes

	mapped_type& at(const Key& key)
	mapped_type& at(const Key& key)&

Uh oh!

Conversation

crimson11 commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

crimson11 commented Jul 23, 2026 •

edited

Loading