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.

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.

bemerybmw · 2026-08-07T09:36:29Z

+///        service-elements (events + fields), which is the fixed capacity the event_controls_ container is constructed
+///        with.
+/// \return needed size (in bytes) for a single control shm-object.
+std::size_t CalculateServiceDataControlShmSize(


We're missing tests for this?

Added tests

bemerybmw · 2026-08-07T09:36:36Z

+///        service-elements (events + fields), which is the fixed capacity the ServiceDataStorage containers are
+///        constructed with.
+/// \return needed size (in bytes) for the data shm-object.
+std::size_t CalculateServiceDataStorageShmSize(


We're missing tests for this?

Added tests

        {
            return ShmSizeCalculationMode::kSimulation;
        }
+        else if (shm_size_calc_mode_value == kShmSizeCalcModeAnalysis)


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.

Added death-test for LinearSearchMap for capacity overflow. SkeletonMemoryManager now uses GetServiceElementInstanceDeployment helper.

Added tests for ServiceDataControl for size calculation.

Added tests for ServiceDataStorage for size calculation.

bemerybmw · 2026-08-10T08:22:51Z

+            GetServiceElementInstanceDeployment<ServiceElementType::FIELD>(lola_service_instance_deployment_, name);
+        SCORE_LANGUAGE_FUTURECPP_ASSERT_PRD_MESSAGE(
+            deployment.lola_event_instance_deployment_.max_subscribers_.has_value(),
+            "Number of sample slots need to be specified for event on provider side!");


Suggested change

"Number of sample slots need to be specified for event on provider side!");

"Max subscribers need to be specified for field on provider side!");

bemerybmw · 2026-08-10T08:24:32Z

+    // When searching via the const overload of find
+    const auto it = const_unit.find(kSomeKey);
+
+    // Then an existing key is found and


Suggested change

// Then an existing key is found and

// Then an existing key is found

bemerybmw · 2026-08-10T08:40:21Z

+///           needed the maximum possible alignment padding. This mirrors what the real construction allocates on the
+///           (monotonic) shared-memory resource, eventually slightly overestimating it, as we have to assume that
+///           memory allocation starts from a worst-case aligned situation.
+std::pair<std::size_t, std::size_t> CalculateServiceDataStorageShmSize(


Better to return a struct than a pair so that the values are named rather than accessing via .first / .second.

bemerybmw · 2026-08-10T08:47:51Z

+
    // (1) The ServiceDataStorage object itself (including the inline bookkeeping of its two LinearSearchMaps).
-    std::size_t total_size = CalculateWorstCaseAllocationSize(sizeof(ServiceDataStorage), alignof(ServiceDataStorage));
+    AccumulateAllocationSize(sizeof(ServiceDataStorage), alignof(ServiceDataStorage), minimal_size, worst_case_size);


Why do we need to calculate the size using worst case alignment for every allocation? I would have thought that we would do this for the first allocation, but after that, the size / alignment calculations would be deterministic for all other allocations, assuming that we calculate them all in the same order as they're allocated in production code (and obviously don't miss any allocations).

And if we actually do the first allocation in shared memory using max_align_t then wouldn't the simulation run then calculate the same size as the analysis run?

bemerybmw · 2026-08-10T08:49:14Z

+    const std::vector<ServiceElementControlSizeInfo> service_elements_size_info{
+        ServiceElementControlSizeInfo{kEventProperties.GetTotalNumberOfSlots(), kEventProperties.max_subscribers},
+        ServiceElementControlSizeInfo{kEventProperties.GetTotalNumberOfSlots(), kEventProperties.max_subscribers}};
+    const auto [minimal_size, worst_case_size] = CalculateServiceDataControlShmSize(


I don't really like that we are modifying the production function just to use the minimal_size here in a test. I'd like to understand this point better and then see if we can come up with a better solution: https://github.com/eclipse-score/communication/pull/760/changes/13d59fa31253a687bbed7c29f94174b16b08494a..c60cea9e544f63cf221586f77d524dd3f08b1716#r3747958827

The size calculation by analysis has now been changed: We don't estimate additional padding/alignment buffer anymore, since we are now "in total control" of the allocation. Thus the analyzed size shall exactly match the size resulting from simulation. Skeleton component tests were added to verify this.

+bool AreServiceElementBindingsGeneric(const SkeletonBinding::SkeletonEventBindings& events,
+                                      const SkeletonBinding::SkeletonFieldBindings& fields)
+{
+    const auto* const first_binding_map = !events.empty() ? &events : (!fields.empty() ? &fields : nullptr);


+            // exactly number_of_slots * sizeof(SampleType) bytes, aligned to alignof(SampleType) - no rounding.
+            if (are_bindings_generic)
+            {
+                const auto& generic_event_binding = static_cast<const GenericSkeletonEventBinding&>(event_binding);


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 force-pushed the mf_new_shm_size_calculation branch 5 times, most recently from f8aab17 to d04e2bf Compare August 1, 2026 16:18

crimson11 force-pushed the mf_new_shm_size_calculation branch from d04e2bf to 93af38c Compare August 4, 2026 11:35

github-advanced-security AI found potential problems Aug 4, 2026

View reviewed changes

crimson11 force-pushed the mf_new_shm_size_calculation branch from 93af38c to 798fdc0 Compare August 4, 2026 12:50

bemerybmw reviewed Aug 7, 2026

View reviewed changes

github-advanced-security AI found potential problems Aug 7, 2026

View reviewed changes

Comment thread score/mw/com/impl/configuration/configuration_json_parsing_strategy.cpp

{

return ShmSizeCalculationMode::kSimulation;

}

else if (shm_size_calc_mode_value == kShmSizeCalcModeAnalysis)

crimson11 requested a review from bemerybmw August 7, 2026 14:06

crimson11 force-pushed the mf_new_shm_size_calculation branch from e3af40f to fc21d3a Compare August 8, 2026 20:34

crimson11 added 8 commits August 8, 2026 23:32

impl/lola: Added shm-size calc for CTRL

c01a870

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

impl/lola: Refine LinearSearchMap

5027a59

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

impl/lola: Fixed review comments

d97fc0c

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

18eb616

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

com/impl/lola: extended tests for LinearSearchMap

13d59fa

Added death-test for LinearSearchMap for capacity overflow. SkeletonMemoryManager now uses GetServiceElementInstanceDeployment helper.

mw/com/impl/lola: Added ServiceDataControl test

cbfe647

Added tests for ServiceDataControl for size calculation.

mw/com/impl/lola: Added ServiceDataStorage tests

595c6bb

Added tests for ServiceDataStorage for size calculation.

crimson11 force-pushed the mf_new_shm_size_calculation branch from fc21d3a to 595c6bb Compare August 8, 2026 21:33

bemerybmw requested changes Aug 10, 2026

View reviewed changes

crimson11 force-pushed the mf_new_shm_size_calculation branch from c60cea9 to 3dbaee4 Compare August 11, 2026 10:13

crimson11 force-pushed the mf_new_shm_size_calculation branch from 3dbaee4 to 0e56382 Compare August 11, 2026 10:20

crimson11 requested a review from bemerybmw August 11, 2026 10:29

github-advanced-security AI found potential problems Aug 11, 2026

View reviewed changes

	"Number of sample slots need to be specified for event on provider side!");
	"Max subscribers need to be specified for field on provider side!");

	// Then an existing key is found and
	// Then an existing key is found

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

crimson11 commented Jul 23, 2026 •

edited

Loading