-
Notifications
You must be signed in to change notification settings - Fork 906
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
add gc layout for some basic types #4495
Conversation
For #4479 |
6db7b16
to
13e2c95
Compare
src/runtime/slice.go
Outdated
@@ -47,7 +47,13 @@ func sliceGrow(oldBuf unsafe.Pointer, oldLen, oldCap, newCap, elemSize uintptr) | |||
// memory allocators, this causes some difficult to debug issues. | |||
newCap = 1 << bits.Len(uint(newCap)) | |||
|
|||
buf := alloc(newCap*elemSize, nil) | |||
var layout unsafe.Pointer | |||
if elemSize == 1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this check < size of pointer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was just being ultra-conservative for this initial POC, and also my test case was focussed on strings. This could absolutely be smarter.
Here's the result of https://github.com/dgryski/trifles/tree/master/tinyjsonbench with the layout patches:
and on wasi
|
13e2c95
to
0e26b70
Compare
Ideally I think the layout should be computed by the compiler and stored with the rest of the type info data, but I'm leaving that for a later PR. I just did the easy ones for now. |
badf1dd
to
07d9d53
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! It's one of those "I should do that some day" but never actually did.
src/runtime/slice.go
Outdated
// less type info here; can only go off element size | ||
if elemSize < unsafe.Sizeof(uintptr(0)) { | ||
layout = gcLayoutNoPtrs | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably best solved by a small compiler change that will pass the layout to runtime.sliceAppend
(like it does today with runtime.alloc
).
40e9dca
to
26c55b9
Compare
PTAL. I think I've addressed everything except the compiler change to pass more type info to the runtime slice functions. |
26c55b9
to
b2fb1fd
Compare
b2fb1fd
to
0b6d61d
Compare
Is a GC layout in this PR the same thing that big Go refers to as a GC shape? |
@ydnar Yes, basically. (For those playing along at home: https://github.com/golang/proposal/blob/master/design/generics-implementation-dictionaries-go1.18.md ) For our implementation, see https://github.com/tinygo-org/tinygo/blob/dev/src/runtime/gc_precise.go . |
More or less (source):
The TinyGo GC layout value doesn't contain alignment and it barely contains size (it doesn't repeat pointer locations, so for a slice or array it would only use the element layout and expect the GC to repeat that). But most importantly, it contains information on which parts (may) contain a pointer - or rather, which parts most definitely don't contain a pointer. Also, am I glad now that I wrote some rather extensive documentation for this feature! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Assuming it passes the test corpus, I think this is fine to merge?
Yes, it passes the test corpus. If you're happy with the code in |
Interestingly there are some binary size and RAM usage changes:
These don't use the precise GC yet, and the changes are too large to reasonably be caused by the added code in this PR, so I think these are actually due to interp changes. Which I think is a good thing? |
No description provided.