Use hybrid C / Pascal strings in the evaluator #14442

glittershark · 2025-11-01T18:45:25Z

Motivation

This is a draft PR to replace the null-terminated C-style strings in Value with pascal strings, where the length is stored in the allocation before the data. This should be considered basically an experiment right now - this ended up being a big optimization for tvix, but it's unclear how much of a win it'd be for cppnix

Context

Depends on #14444
Depends on #14470

Ericson2314 · 2025-11-01T19:04:10Z

CC @Radvendii

Ericson2314 · 2025-11-01T19:27:01Z

OK I am taking a look at the sanitzer failure.

xokdvium · 2025-11-01T19:31:12Z

Would to see this through :)

edolstra · 2025-11-03T16:52:52Z

What sort of performance improvement can we expect from this? (Memory, speed?)

glittershark · 2025-11-03T17:38:00Z

What sort of performance improvement can we expect from this? (Memory, speed?)

I think it's hard to say. For tvix the big performance win was saving a word of cache footprint by converting rust fat pointers to thin pointers. For C++nix the value representation already uses only one word for the pointer (and another word for context iirc) so the win is less clear. Plausibly length gets cheaper (I have definitely worked in systems where strlen is really costly!) but ime length doesn't end up being that hot in Nix evaluations.

On the other hand, tvix had to incur the cost of an extra pointer indirection to find string length, so maybe the delta in this case is more clearly beneficial, since c++nix already has to chase a pointer to look up the length of a string.

As is always the case, we should benchmark.

Ericson2314 · 2025-11-03T18:04:37Z

In the meeting (going on right now) we also talked about how parsers going through strings character by character were needlessly quadratic. This might not be in our test suite today, but @tomberek can easily add such an example.

I would expect that since this dramatically includes that use-case, even if it is doesn't improve other use-cases (but also doesn't make them worse) the PR should overall be worth it.

In short, the plan to me is:

Benchmark
If seems worth it, merge
Otherwise, add parser test case
Benchmark again
Almost certainly will be worth it (unless we made a mistake in the implementation)
Merge

So all paths lead to merging, but we do make sure we have evidence first.

glittershark · 2025-11-03T18:26:16Z

I would really not be surprised if this issue is just UB - the original implementation was pretty messy, and I never got around to combing through it to find all the ways I was holding C++ wrong.

dpulls · 2025-11-03T18:44:04Z

🎉 All dependencies have been resolved !

src/libexpr/include/nix/expr/value.hh

src/libexpr/include/nix/expr/symbol-table.hh

src/libexpr/eval.cc

Radvendii · 2025-11-03T22:38:03Z

This is what I've found:

the problem has to do with invalid context strings.
it seems to be getting set to another string, rather than turning into a nullpointer or something.
that context string is not getting set to the invalid state when it's initialized via mkPath
the problem goes away when the GC is disabled

Radvendii · 2025-11-03T22:43:03Z

Oh! Could it be that boehm is confused because we're holding onto pointers but they don't point at the beginning of the allocation?

So then it concludes that there's no reference to it and frees it?

hmm... presumably boehm is smarter than that...

Ericson2314 · 2025-11-04T00:26:46Z

Applied the fix, and factored out a new prep PR of #14470 to keep this smaller.

glittershark · 2025-11-04T15:27:42Z

boehm delenda est

xokdvium · 2025-11-04T16:19:12Z

So then it concludes that there's no reference to it and frees it?

Well, it's not suprising consdering that we have interior pointer detection only for the first 8 bytes and only on 64 bit systems to make that work with low-bit tagging.

Radvendii · 2025-11-04T23:14:29Z

boehm delenda est

This might be my next project.

to make that work with low-bit tagging.

I was wondering how that worked!

dpulls · 2025-11-09T22:05:22Z

🎉 All dependencies have been resolved !

src/libexpr/eval.cc

xokdvium

Reworked slightly to reduce the diff and addressed review comments from @Radvendii. Also got rid of a interior pointer footgun that I could find. I'm happy with this diff

Ericson2314 · 2025-11-10T01:08:46Z

src/libexpr/include/nix/expr/value.hh

        return getStorage<FunctionApplicationThunk>();
    }

    const char * pathStr() const noexcept


@xokdvium seems like there should be some method getting a const StringData & from the path that this and the other method are written in terms of?

StringData is more of implementation detail though. No code actually cares about it beyond the string_view and c_str accessors. Maybe it will start caring, but now it doesn't so there's no immediate need to expose this method.

OK I guess that is fine.

FWIW I would like try to get rid of the trailing null byte at some point. and then the const char * ones really ought to go away.

Ericson2314 · 2025-11-10T01:13:02Z

src/libexpr/include/nix/expr/value.hh

+    size_type size_;
+    char data_[];


you want these public?

It's not too clear, but if we want to be on the safe side the layout compatible types should also have the same visibility of members.

Eh we are being extra safe on that, but less safe on preventing people from going through fields by mistake.

https://stackoverflow.com/questions/36149462/does-public-and-private-have-any-influence-on-the-memory-layout-of-an-object

reading that, it seems like we are probably fine so long as all the fields are the same visibility.

src/libexpr/eval.cc

Forgot to print in one case Co-authored-by: Aspen Smith <[email protected]>

Replace the null-terminated C-style strings in Value with hybrid C / Pascal strings, where the length is stored in the allocation before the data, and there is still a null byte at the end for the sake of C interopt. Co-Authored-By: Taeer Bar-Yam <[email protected]> Co-Authored-By: Sergei Zimmerman <[email protected]>

github-actions bot added new-cli Relating to the "nix" command with-tests Issues related to testing. PRs with tests have some priority c api Nix as a C library with a stable interface labels Nov 1, 2025

Ericson2314 force-pushed the pascal-strings branch 2 times, most recently from dda5c2f to 15a9f93 Compare November 1, 2025 19:03

Ericson2314 force-pushed the pascal-strings branch from 15a9f93 to 6f82634 Compare November 1, 2025 19:10

Ericson2314 changed the title ~~Pascal strings~~ Use hybrid C / Pascal strings in the evaluator Nov 1, 2025

xokdvium self-assigned this Nov 1, 2025

Ericson2314 force-pushed the pascal-strings branch 2 times, most recently from d5a1e45 to f89ef40 Compare November 1, 2025 20:18

This was referenced Nov 1, 2025

Inline only-used-once closures in ExprConcatStrings::eval #14443

Merged

Use less c_str() in the evaluator, and other cleanups #14444

Merged

Ericson2314 force-pushed the pascal-strings branch 2 times, most recently from 91905f3 to 2f15843 Compare November 1, 2025 21:41

This comment was marked as resolved.

Sign in to view

Ericson2314 force-pushed the pascal-strings branch from 2f15843 to 8e7cd91 Compare November 2, 2025 04:42

This comment was marked as resolved.

Sign in to view

xokdvium requested changes Nov 3, 2025

View reviewed changes

src/libexpr/include/nix/expr/value.hh Outdated Show resolved Hide resolved

Radvendii reviewed Nov 3, 2025

View reviewed changes

src/libexpr/include/nix/expr/symbol-table.hh Show resolved Hide resolved

src/libexpr/eval.cc Show resolved Hide resolved

Ericson2314 force-pushed the pascal-strings branch from 8e7cd91 to ea6ba08 Compare November 3, 2025 23:05

This comment was marked as resolved.

Sign in to view

Ericson2314 force-pushed the pascal-strings branch from ea6ba08 to 874640c Compare November 4, 2025 00:24

Ericson2314 marked this pull request as ready for review November 4, 2025 17:04

Ericson2314 requested a review from edolstra as a code owner November 4, 2025 17:04

Ericson2314 force-pushed the pascal-strings branch from 874640c to 7a642f2 Compare November 9, 2025 23:03

xokdvium reviewed Nov 9, 2025

View reviewed changes

src/libexpr/eval.cc Outdated Show resolved Hide resolved

xokdvium force-pushed the pascal-strings branch 2 times, most recently from 0667013 to 3bc870e Compare November 10, 2025 00:49

xokdvium approved these changes Nov 10, 2025

View reviewed changes

Ericson2314 reviewed Nov 10, 2025

View reviewed changes

src/libexpr/eval.cc Show resolved Hide resolved

Ericson2314 and others added 2 commits November 10, 2025 00:54

Make string matcher for libexpr texts like others

8c113f8

Forgot to print in one case Co-authored-by: Aspen Smith <[email protected]>

Ericson2314 force-pushed the pascal-strings branch from 3bc870e to 3bf8c76 Compare November 10, 2025 06:01

Ericson2314 enabled auto-merge November 10, 2025 06:01

Ericson2314 approved these changes Nov 10, 2025

View reviewed changes

Ericson2314 added this pull request to the merge queue Nov 10, 2025

Ericson2314 mentioned this pull request Nov 10, 2025

Use StringData for Nix language value documentation too #14527

Open

Merged via the queue into NixOS:master with commit a786c9e Nov 10, 2025
16 checks passed

Uh oh!

Use hybrid C / Pascal strings in the evaluator #14442

Use hybrid C / Pascal strings in the evaluator #14442

Uh oh!

Conversation

glittershark commented Nov 1, 2025 • edited by Ericson2314 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Context

Uh oh!

Ericson2314 commented Nov 1, 2025

Uh oh!

Ericson2314 commented Nov 1, 2025

Uh oh!

xokdvium commented Nov 1, 2025

Uh oh!

This comment was marked as resolved.

edolstra commented Nov 3, 2025

Uh oh!

glittershark commented Nov 3, 2025

Uh oh!

Ericson2314 commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

glittershark commented Nov 3, 2025

Uh oh!

dpulls bot commented Nov 3, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Radvendii commented Nov 3, 2025

Uh oh!

Radvendii commented Nov 3, 2025

Uh oh!

This comment was marked as resolved.

Ericson2314 commented Nov 4, 2025

Uh oh!

glittershark commented Nov 4, 2025

Uh oh!

xokdvium commented Nov 4, 2025

Uh oh!

Radvendii commented Nov 4, 2025

Uh oh!

dpulls bot commented Nov 9, 2025

Uh oh!

Uh oh!

xokdvium left a comment

Choose a reason for hiding this comment

Uh oh!

Ericson2314 Nov 10, 2025

Choose a reason for hiding this comment

Uh oh!

xokdvium Nov 10, 2025

Choose a reason for hiding this comment

Uh oh!

Ericson2314 Nov 10, 2025

Choose a reason for hiding this comment

Uh oh!

Ericson2314 Nov 10, 2025

Choose a reason for hiding this comment

Uh oh!

xokdvium Nov 10, 2025

Choose a reason for hiding this comment

Uh oh!

Ericson2314 Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

glittershark commented Nov 1, 2025 •

edited by Ericson2314

Loading

Ericson2314 commented Nov 3, 2025 •

edited

Loading

Ericson2314 Nov 10, 2025 •

edited

Loading