Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't limit ExternalName::TestName length #4764

Merged
merged 1 commit into from
Aug 24, 2022

Conversation

jameysharp
Copy link
Contributor

Following up on discussion in #4667, here's a way to avoid making sweeping changes while still using reasonable names in filetests. @afonso360, how does this look to you? @cfallin, do the numbers here sound okay to you?

In order to keep the ExternalName enum small, the TestcaseName struct was limited to 17 bytes: a 1 byte length and a 16 byte buffer. Due to alignment, that made ExternalName 20 bytes.

That fixed-size buffer means that the names of functions in Cranelift filetests are truncated to fit, which limits our ability to give tests meaningful names. And I think meaningful names are important in tests.

This patch replaces the inline TestcaseName buffer with a heap-allocated slice. We don't care about performance for test names, so an indirection out to the heap is fine in that case. But we do care somewhat about the size of ExternalName when it's used during compiles.

On 64-bit systems, Box<[u8]> is 16 bytes, so TestcaseName gets one byte smaller. Unfortunately, its alignment is 8 bytes, so ExternalName grows from 20 to 24 bytes.

According to valgrind --tool=dhat, this change has very little effect on compiler performance. Building wasmtime with --no-default-features --release, and compiling the pulldown-cmark benchmark from Sightglass, I measured these differences between main and this patch:

  • total number of allocations didn't change (ExternalName::TestCase is not used in normal compiles)
  • 592 more bytes allocated over the process lifetime, out of 171.5MiB
  • 320 more bytes allocated at peak heap size, out of 12MiB
  • 0.24% more instructions executed
  • 16,987 more bytes written
  • 12,120 fewer bytes read

In order to keep the `ExternalName` enum small, the `TestcaseName`
struct was limited to 17 bytes: a 1 byte length and a 16 byte buffer.
Due to alignment, that made `ExternalName` 20 bytes.

That fixed-size buffer means that the names of functions in Cranelift
filetests are truncated to fit, which limits our ability to give tests
meaningful names. And I think meaningful names are important in tests.

This patch replaces the inline `TestcaseName` buffer with a
heap-allocated slice. We don't care about performance for test names, so
an indirection out to the heap is fine in that case. But we do care
somewhat about the size of `ExternalName` when it's used during
compiles.

On 64-bit systems, `Box<[u8]>` is 16 bytes, so `TestcaseName` gets one
byte smaller. Unfortunately, its alignment is 8 bytes, so `ExternalName`
grows from 20 to 24 bytes.

According to `valgrind --tool=dhat`, this change has very little effect
on compiler performance. Building wasmtime with `--no-default-features
--release`, and compiling the pulldown-cmark benchmark from Sightglass,
I measured these differences between `main` and this patch:

- total number of allocations didn't change (`ExternalName::TestCase` is
  not used in normal compiles)
- 592 more bytes allocated over the process lifetime, out of 171.5MiB
- 320 more bytes allocated at peak heap size, out of 12MiB
- 0.24% more instructions executed
- 16,987 more bytes written
- 12,120 _fewer_ bytes read
@jameysharp jameysharp requested a review from cfallin August 24, 2022 00:01
Copy link
Member

@cfallin cfallin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This leads to much cleaner-looking test files -- thanks a bunch!

total number of allocations didn't change (ExternalName::TestCase is not used in normal compiles)
592 more bytes allocated over the process lifetime, out of 171.5MiB
320 more bytes allocated at peak heap size, out of 12MiB

Yeah, I think that's fine; 593 extra bytes on 171.5MiB would have been just far too much, but 592, I think I can live with :-)

@github-actions github-actions bot added the cranelift Issues related to the Cranelift code generator label Aug 24, 2022
@jameysharp jameysharp merged commit 9cb987c into bytecodealliance:main Aug 24, 2022
@jameysharp jameysharp deleted the box-testname branch August 24, 2022 04:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift Issues related to the Cranelift code generator
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants