Align fs.ReadStream buffer pool writes to 8-byte boundary

[trxcllnt]

fs: align fs.ReadStream buffer pool writes to 8-byte boundary

Prevents alignment issues when people create a typed array from a chunk buffer, similar to 285d8c6.

Fixes#24817

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[bnoordhuis]

LGTM. It might be infinitesimally nicer to move it into a function so you can simply write pool.used = align(pool.used), with align() being:

functionalign(n){return(n+7)&~7;// Align to 8 byte boundary.}

[trxcllnt]

👍 thanks @bnoordhuis, I moved the logic into a roundUpToMultipleOf8 function and updated the PR

[bnoordhuis]

If you're only using alignedOffset inside the if/else arms, can you make it const and scope it to inside the arms?

Is start + toRead correct when alignedOffset may not be start + bytesRead? What I mean is, shouldn't start + toRead be rounded up too?

[trxcllnt]

Rounding up is unsafe here, since toRead is clamped within the size of the pool on initialization. I had the same thought initially, but rounding it up caused unrelated tests to fail.

[bnoordhuis]

But you agree it's slicing less than before? Note that slice() takes start and end arguments (inclusive), not start and length.

After thinking about this some more, I think that the rules/constraints should be:

1. thisPool.used is always a multiple of 8 (the pool itself is already suitably aligned), and

2. this particular slice() call should only slice multiples of 8 at offsets that are multiples of 8.

(1) implies (2) because (2) caches slices for reuse by (1).

(2) can be enforced by rounding start + toRead down.

Potential pitfall: rounding up or down can result in slices smaller than kMinPoolSpace. It should check that the slice's length >= kMinPoolSpace before pushing it into poolFragments.

[trxcllnt]

Yes it is slicing less than before. By rounding up the start position, we advance 8 - n_remainder bytes past where we would have sliced. In this PR, pool.used (and thisPool.used) should always be a multiple of 8, which I believe addresses point (1).

With regards to (2), the byteLength of each slice as it is now isn't guaranteed to be a multiple of 8, though I think that's also a good idea. Performance-wise, it's best to align the toRead value to the processor's cache line size, but I left it as-is to keep the surface area of this PR to a minimum. I would be happy to add this though.

Good catch on the adjusted size causing the pool fragment size to dip below kMinPoolSpace, I'll update the PR with a fix here in a bit.

[bnoordhuis]

LGTM % nits. CI: https://ci.nodejs.org/job/node-test-pull-request/19282/

[bnoordhuis]

Tiniest of nits: alignedOffset is a misnomer since it's not actually aligned (yet.)

[bnoordhuis]

One more micro-nit: comments should be capitalized and punctuated (and normally have two spaces before the // - I expect the linter will complain.)

[bnoordhuis]

https://ci.nodejs.org/job/node-test-pull-request/19338/

[trxcllnt]

@bnoordhuis what else needs to be done here? Are those three failing checks related to this change? I tried parsing through the console output, but can't see any indication of why it's failing.

[bnoordhuis]

Let's run the CI again and see what happens: https://ci.nodejs.org/job/node-test-pull-request/19989/

[addaleax]

@trxcllnt Do you think you could rebase this? Sorry for the merge conflicts!

[trxcllnt]

@addaleax just resolved the conflict via the github UI, let me know if I should do anything further. Thanks!

[addaleax]

@trxcllnt One problem is that merge conflicts break our CI and make landing changes harder – can you use git rebase rather than a merge commit?

(We can probably figure this out another way if not, but this would definitely make things easier)

[trxcllnt]

@addaleax sure thing -- rebased from upstream/master and resolved the conflict locally. I'm always wary of resolving conflicts during a rebase, so let me know if it doesn't look right.

[trxcllnt]

@bnoordhuis@addaleax anything left to do here? The node folks in the Apache Arrow project would appreciate if we could merge this soon 🙏 since we have a workaround in place that has to resort to copying chunks if the offset isn't aligned. It can be a nasty/hidden performance cliff for users if they're doing a lot of file I/O. Let me know if there's anything else I can do ❤️

[addaleax]

@trxcllnt It looks like the rebase went wrong somehow? There’s 22000 added lines in this PR now…

Generally, there’s nothing in the way of landing it, and bumping the thread is the exact right thing to do :)

[trxcllnt]

@addaleax thanks for the heads up! should be fixed now :-)

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22092/

[trxcllnt]

@addaleax bump :-]

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22866/

[addaleax]

Landed in b884ceb 🎉 Thanks for the PR!