mirror of
https://github.com/nodejs/node.git
synced 2026-11-09 15:11:11 -05:00
Philipp Dunkel
df2ea49e00
Add zlib.crc32c(data[, value]), which computes the CRC-32C checksum (Castagnoli polynomial, RFC 3720 section 12.1). CRC-32C has better error detection properties than the CRC-32 of zlib.crc32() and is the checksum required by many current protocols, formats and services, among them: - iSCSI header and data digests (RFC 7143) - SCTP packet checksums (RFC 9260) - iWARP MPA framing (RFC 5044) - NVMe/TCP header and data digests - ext4, Btrfs and XFS metadata checksums - the Snappy framing format - Apache Kafka record batches - LevelDB and RocksDB block checksums - TensorFlow TFRecord files - Google Cloud Storage and Amazon S3 object checksums Implementing any of these in JavaScript currently needs a userland CRC-32C, which is far slower than native code. The function mirrors zlib.crc32(): it accepts a string (encoded as UTF-8) or an ArrayBufferView, takes an optional 32-bit unsigned starting value so a checksum can be continued across chunks, and has a V8 fast API path. The checksum is computed by absl::ExtendCrc32c() from the bundled Abseil, which is already built and linked into node, so this adds no new dependency and no new checksum implementation. absl_crc32c is added to the libraries linked with --shared-abseil. Abseil selects its hardware-accelerated CRC-32C path (SSE4.2 and PCLMULQDQ on x64, the CRC32 and PMULL extensions on arm64) at compile time, so with node's default compiler flags the portable table-driven implementation is used. It runs at about the same speed as zlib.crc32() (about 6.5 GB/s on a recent x64 machine), while the hardware path reaches about 38 GB/s. Builds whose target CPU baseline already includes those instructions get the hardware path without changes. Enabling it for generic builds is left out on purpose: on x64, Abseil uses the accelerated code for unrecognized CPUs without a runtime feature check, so compiling it in unconditionally would fault on CPUs without SSE4.2. Signed-off-by: Philipp Dunkel <pip@pipobscure.com> PR-URL: https://github.com/nodejs/node/pull/66828 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Paolo Insogna <paolo@cowtech.it> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Node.js Core Tests
This directory contains code and data used to test the Node.js implementation.
For a detailed guide on how to write tests in this directory, see the guide on writing tests.
On how to run tests in this directory, see the contributing guide.
For the tests to run on Windows, be sure to clone Node.js source code with the
autocrlf git config flag set to true.
Test Directories
| Directory | Runs on CI | Purpose |
|---|---|---|
abort |
Yes | Tests that use --abort-on-uncaught-exception and other cases where we want to avoid generating a core file. |
addons |
Yes | Tests for addon functionality along with some tests that require an addon. |
async-hooks |
Yes | Tests for async_hooks functionality. |
benchmark |
Yes | Test minimal functionality of benchmarks. |
cctest |
Yes | C++ tests that are run as part of the build process. |
code-cache |
No | Tests for a Node.js binary compiled with V8 code cache. |
common |
N/A | Common modules shared among many tests.1 |
doctool |
Yes | Tests for the documentation generator. |
es-module |
Yes | Test ESM module loading. |
fixtures |
N/A | Test fixtures used in various tests throughout the test suite. |
internet |
No | Tests that make real outbound network connections.2 |
js-native-api |
Yes | Tests for Node.js-agnostic Node-API functionality. |
known_issues |
Yes | Tests reproducing known issues within the system.3 |
message |
Yes | Tests for messages that are output for various conditions |
node-api |
Yes | Tests for Node.js-specific Node-API functionality. |
parallel |
Yes | Various tests that are able to be run in parallel. |
pseudo-tty |
Yes | Tests that require stdin/stdout/stderr to be a TTY. |
pummel |
No | Various tests for various modules / system functionality operating under load. |
sequential |
Yes | Various tests that must not run in parallel. |
testpy |
N/A | Test configuration utility used by various test suites. |
tick-processor |
No | Tests for the V8 tick processor integration.4 |
v8-updates |
No | Tests for V8 performance integration. |
-
Tests for networking related modules may also be present in other directories, but those tests do not make outbound connections. ↩︎
-
All tests inside of this directory are expected to fail. If a test doesn't fail on certain platforms, those should be skipped via
known_issues.status. ↩︎ -
The tests are for the logic in
lib/internal/main/prof_process.jsandlib/internal/v8_prof_polyfill.js. The tests confirm that the profile processor packages the correct set of scripts from V8 and introduces the correct platform specific logic. ↩︎