UB free test for CString Drop

[matklad]

This implements an UB free (I hope :) ) test for #36264. Thanks to @petrochenkov and @nagisa for advice.

It also switched to volatile_write for zeroing per @Amanieu suggestion, which should prevent LLVM from optimizing our efforts away. @nagisa could you re-run your benchmark with this implementation to see if anything has changed?

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[nagisa]

@nagisa could you re-run your benchmark with this implementation to see if anything has changed?

The benchmark was in /tmp and I’ve restarted since.

[matklad]

volatile_write does make Drop a little slower according to my benchmark.

Source code: https://gist.github.com/matklad/87a77a7670b1b9144e09b9c4e62ea00f

Two runs without Drop for CString:

Baseline 1: empty String
ns per iter = 83
ns per iter = 83
ns per iter = 84

Baseline 2: hello world String
ns per iter = 161
ns per iter = 162
ns per iter = 161

Bench 1: empty CString
ns per iter = 103
ns per iter = 102
ns per iter = 101

Bench 2: hello world CString
ns per iter = 114
ns per iter = 115
ns per iter = 114

Baseline 1: empty String
ns per iter = 84
ns per iter = 83
ns per iter = 83

Baseline 2: hello world String
ns per iter = 161
ns per iter = 161
ns per iter = 162

Bench 1: empty CString
ns per iter = 100
ns per iter = 100
ns per iter = 100

Bench 2: hello world CString
ns per iter = 112
ns per iter = 111
ns per iter = 111

two runs with volatile write (this PR):

Baseline 1: empty String
ns per iter = 86
ns per iter = 86
ns per iter = 86

Baseline 2: hello world String
ns per iter = 162
ns per iter = 162
ns per iter = 162

Bench 1: empty CString
ns per iter = 113
ns per iter = 112
ns per iter = 112

Bench 2: hello world CString
ns per iter = 127
ns per iter = 127
ns per iter = 127

Baseline 1: empty String
ns per iter = 86
ns per iter = 85
ns per iter = 85

Baseline 2: hello world String
ns per iter = 166
ns per iter = 161
ns per iter = 161

Bench 1: empty CString
ns per iter = 115
ns per iter = 114
ns per iter = 114

Bench 2: hello world CString
ns per iter = 128
ns per iter = 129
ns per iter = 129

Will try to add a non volatile write bench later. Is there a faster way to build stdlib than make -j10 rustc-stage1 NO_REBUILD=1? And NO_REBUILD does not help here I guess?

[matklad]

Here's the one with non-volatile write (no perceivable difference with volatile):

Baseline 1: empty String
ns per iter = 86
ns per iter = 86
ns per iter = 86

Baseline 2: hello world String
ns per iter = 161
ns per iter = 161
ns per iter = 161

Bench 1: empty CString
ns per iter = 112
ns per iter = 112
ns per iter = 111

Bench 2: hello world CString
ns per iter = 126
ns per iter = 126
ns per iter = 126

[matklad]

Also it may make sense to compare these to the cost of the allocation, because the overhead kinda amortizes between new and drop. So, creating a hello world string is about 1000 ns on my machine.

[alexcrichton]

I don't think it's worth using a volatile write to try to fix this test, it's just an opportunistic thing we do and if LLVM decides to remove it then that seems like a good thing. (it won't do so in debug mode, especially if we #[inline] this destructor).

If the test causes problems then I think it's safe to remove, it's probably not worth having a super elaborate test case for this.

[matklad]

The test works fine without volatile at the moment, though it could theoretically break in the future.

it won't do so in debug mode, especially if we #[inline] this destructor

Yes indeed. So I'll add #[inline(always)] and remove the test altogether tomorrow.

[matklad]

#36741