[ntuple] Fixes for alignment by jblomer · Pull Request #22312 · root-project/root

jblomer · 2026-05-16T05:32:36Z

Use the new TClass alignment information where applicable. This fixes

Alignment of classes whose alignment is defined by a transient member
Alignment of certain streamer fields

Additionally, use the new and delete operators with alignment info. This ensures correct memory allocation for over-aligned types.

Fixes #16765

github-actions · 2026-05-16T09:18:43Z

Test Results

22 files 22 suites 3d 9h 39m 40s ⏱️
3 860 tests 3 788 ✅ 0 💤 72 ❌
76 176 runs 75 820 ✅ 215 💤 141 ❌

For more details on these failures, see this check.

Results for commit aa8c36c.

♻️ This comment has been updated with latest results.

pcanal · 2026-05-18T18:14:57Z


+void ROOT::RFieldBase::EnsureValidAlignment(std::size_t alignment)
+{
+   if (alignment == 0 || alignment > ROOT::RFieldBase::kMaxAlignment || !ROOT::Internal::IsPowerOfTwo(alignment))


This is similar (but different) to ROOT::Internal::IsValidAlignment.

Suggested change

if (alignment == 0 || alignment > ROOT::RFieldBase::kMaxAlignment || !ROOT::Internal::IsPowerOfTwo(alignment))

if (!ROOT::Internal::IsValidAlignment(alignment) || alignment > ROOT::RFieldBase::kMaxAlignment)

At least in the main I/O part the limitation to 4096 is only for std::vector because they can be handled without dictionary (but then we need to explicitly handle the alignment of their content.

Is RNTuple more restrictive (i.e. calling an generically provided call to new for various alignment?)

Actually it isn't. Assuming that the std::vector layout doesn't change depending on the alignment of its item type, RNTuple has no further maximum alignment restrictions of its own. At the moment, I use the maximum alignment to verify that the std::vector alignment is independent.

In general, I thought that it makes sense to have either no size limit or one size limit for all types.

I can see how it might be simpler for user but I find it confusing for developer as the vector limitation is very specific, localized and 'easy' to increase, if a user report reaching the limit for another containers we might (at least temporarily) be confused of where to lift the limit for that other containers.

Makes sense. I changed the code such that the limitation is only active for the vector field.

hahnjo

The code changes look good overall; quickly looking at the failures, it appears that macOS and Windows are complaining about the missing import of <array>. Not sure if that solves all issues...

hahnjo

As discussed offline, this is missing the part of aligning the dynamic array in std::vector<T> (relatively easy to do) and RVec<T> (harder because it currently uses malloc and free). In the worst case, we discussed throwing in case we have alignment larger than std::max_align_t

pcanal · 2026-05-27T03:17:04Z

+void ROOT::RFieldBase::EnsureValidAlignment(std::size_t alignment)
+{
+   if (!Internal::IsValidAlignment(alignment) || alignment > ROOT::RFieldBase::kMaxAlignment)
+      throw ROOT::RException(R__FAIL(std::string("invalid alignment: ") + std::to_string(alignment)));


I think it would be more helpful for the user to be more specific about the error message.

Suggested change

throw ROOT::RException(R__FAIL(std::string("invalid alignment: ") + std::to_string(alignment)));

if (!Internal::IsValidAlignment(alignment))

throw ROOT::RException(R__FAIL(std::string("invalid alignment: ") + std::to_string(alignment)));

// If user report alignment is excess of our support 'all' we need to do is extend the cases supported

// for vector (see RFieldSequenceContainer.cxx's ConstructVector and TEmulatedCollectionProxy.h)

// and then increase kMaxAlignment.

if (alignment > ROOT::RFieldBase::kMaxAlignment)

throw ROOT::RException(R__FAIL(std::string("Unsupported alignment: ") + std::to_string(alignment)));

Done as part of the switch statements in RVectorField.

pcanal · 2026-06-01T15:40:38Z

+   if (alignOfValue <= sizeof(std::max_align_t)) {
+      new (where) std::vector<char>();
+   } else {


What is the advantage of special casing the alignment 1, 2, 4 and 8 (i.e. the effective role of this if statement)?

pcanal · 2026-06-01T15:42:40Z

+      case 1024: std::destroy_at(static_cast<std::vector<Internal::RAlignedStorage<1024>> *>(objPtr)); break;
+      case 2048: std::destroy_at(static_cast<std::vector<Internal::RAlignedStorage<2048>> *>(objPtr)); break;
+      case 4096: std::destroy_at(static_cast<std::vector<Internal::RAlignedStorage<4096>> *>(objPtr)); break;
+      default: R__ASSERT(false);


What is the advantage of having here an R__ASSERT while in other similar case we use throw?

pcanal

LGTM. Thanks.

jblomer self-assigned this May 16, 2026

jblomer requested a review from bellenot as a code owner May 16, 2026 05:32

jblomer added the in:RNTuple label May 16, 2026

jblomer requested review from dpiparo and pcanal as code owners May 16, 2026 05:32

jblomer added the Small Bug Density label May 16, 2026

jblomer force-pushed the ntuple-update-align branch from bb61c3d to 694bd02 Compare May 16, 2026 07:25

jblomer requested review from enirolf, hahnjo and silverweed May 16, 2026 07:26

jblomer force-pushed the ntuple-update-align branch 2 times, most recently from 27ddc85 to ba94832 Compare May 16, 2026 07:42

jblomer added the clean build Ask CI to do non-incremental build on PR label May 16, 2026

jblomer closed this May 16, 2026

jblomer reopened this May 16, 2026

silverweed reviewed May 18, 2026

View reviewed changes

Comment thread core/foundation/inc/ROOT/BitUtils.hxx Outdated

pcanal reviewed May 18, 2026

View reviewed changes

Comment thread core/foundation/inc/ROOT/BitUtils.hxx Outdated

pcanal reviewed May 18, 2026

View reviewed changes

hahnjo reviewed May 22, 2026

View reviewed changes

Comment thread tree/ntuple/test/CustomStruct.hxx

hahnjo requested changes May 22, 2026

View reviewed changes

jblomer force-pushed the ntuple-update-align branch 3 times, most recently from 787669e to 2c2dc4a Compare May 26, 2026 11:59

jblomer requested review from hahnjo and pcanal May 26, 2026 20:14

jblomer removed the clean build Ask CI to do non-incremental build on PR label May 26, 2026

jblomer closed this May 26, 2026

jblomer reopened this May 26, 2026

pcanal reviewed May 27, 2026

View reviewed changes

jblomer added the clean build Ask CI to do non-incremental build on PR label May 27, 2026

jblomer added 6 commits June 1, 2026 11:30

[io] move (R)AlignedStorage to bit utils

bfa42ed

[core] add IsPowerOfTwo() to bit utils

fbb3759

[ntuple] use TClass alignment info where possible

90cfea1

[ntuple] fix memory allocation for over-aligned fields

6ab801f

[ntuple] fix up vector resize for over-aligned values

9994ce9

[ntuple] fix up vector new/delete for over-aligned values

aa8c36c

jblomer force-pushed the ntuple-update-align branch from 2c2dc4a to aa8c36c Compare June 1, 2026 13:44

jblomer requested a review from pcanal June 1, 2026 13:45

pcanal reviewed Jun 1, 2026

View reviewed changes

pcanal approved these changes Jun 1, 2026

View reviewed changes

	if (alignment == 0 \|\| alignment > ROOT::RFieldBase::kMaxAlignment \|\| !ROOT::Internal::IsPowerOfTwo(alignment))
	if (!ROOT::Internal::IsValidAlignment(alignment) \|\| alignment > ROOT::RFieldBase::kMaxAlignment)

-      throw ROOT::RException(R__FAIL(std::string("invalid alignment: ") + std::to_string(alignment)));
+   if (!Internal::IsValidAlignment(alignment))
+      throw ROOT::RException(R__FAIL(std::string("invalid alignment: ") + std::to_string(alignment)));
+   // If user report alignment is excess of our support 'all' we need to do is extend the cases supported
+   // for vector (see RFieldSequenceContainer.cxx's ConstructVector and TEmulatedCollectionProxy.h)
+   // and then increase kMaxAlignment.
+   if (alignment > ROOT::RFieldBase::kMaxAlignment)
+      throw ROOT::RException(R__FAIL(std::string("Unsupported alignment: ") + std::to_string(alignment)));

Conversation

jblomer commented May 16, 2026

Uh oh!

github-actions Bot commented May 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

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!

hahnjo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hahnjo left a comment

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!

pcanal left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions Bot commented May 16, 2026 •

edited

Loading