testing: implement AllocsPerRun - #5772
jakebailey wants to merge 1 commit into
Conversation
|
Huh, not how it behaved locally.... Will fix :) |
39df6ae to
29ab91c
Compare
| } | ||
|
|
||
| gcLock.Lock() | ||
| gcMallocs++ |
There was a problem hiding this comment.
are we allowed to use an atomic here; istm that there are two calls, add(1) to increment, and return add(0) to get the current mallocs count.
There was a problem hiding this comment.
oh, but its a double word :( ok, lock it is
When I'm at my mac again I'll have to look into this; not the first time it's flaked |
29ab91c to
c094eb5
Compare
|
Foiled by my own netip unskip 😄 |
Allocation-sensitive standard library tests currently receive a constant zero, hiding regressions and optimization opportunities. Real measurements expose existing differences from upstream, so keep those tests excluded until TinyGo meets their allocation budgets.
c094eb5 to
bb09ac5
Compare
|
Because our escape analysis is not as good as Big Go's, this causes the following packages in the test corpus to fail: These all have tests expecting zero allocations and getting 1. There are a few other packages that use This is not to say we shouldn't merge this, but it does mean it quickly exposes other places we need to beef up the escape analysis. |
3 participants
This implements
testing.AllocsPerRun. The current code returned 0, which causes a bunch of tests to pass even though they shouldn't, so explicitly skip those.All GC providers already had the code for this, save for Boehm which just needs a counter under the existing GC lock.
Custom GC needs to implement this via
ReadMemStats. (Though, I am of the opinion that custom GC should go away, because it was only ever added so someone could add Boehm themselves!)The makefile is getting nasty; I have a change I want to send in the future to try and make it less repetitive, but for now it keeps doing the same copypasta as before.