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.

Sign up for GitHub

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

Jump to bottom

cmd/compile: ephemeral slicing doesn't need protection against next object pointers #15397

Open
randall77 opened this issue Apr 21, 2016 · 6 comments
Open

cmd/compile: ephemeral slicing doesn't need protection against next object pointers #15397

randall77 opened this issue Apr 21, 2016 · 6 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Performance
Milestone
Unplanned

Comments

@randall77
Copy link
Contributor 

func f(b []byte) byte {
    b = b[3:]
    return b[4]
}

We compile this to something like (bounds checks omitted):

    p = b.ptr
    inc = 3
    if b.cap == 3 {
        inc = 0
    }
    p += inc
    return *(p+4)

The if in the middle is there to make sure we don't manufacture a pointer to the next object in memory. But the resulting pointer is never exposed to the garbage collector, so that if is unnecessary. Manufacturing a pointer to the next object in memory is ok if that pointer is never spilled at a safe point. (Bounds checks will make sure such a pointer is never actually used.)

Unfortunately, I don't see an easy way to do this optimization in the current compiler. Marked as unplanned.

See #14849
@randall77 randall77 added this to the Unplanned milestone Apr 21, 2016
@randall77 randall77 mentioned this issue Jan 7, 2017
Open
@randall77 randall77 mentioned this issue Feb 14, 2018
Open
@rasky
Copy link
Member

rasky commented Mar 10, 2018

@randall77 do you happen to have any idea nowadays on how to attack this problem?

@josharian
Copy link
Contributor

I read on some thread somewhere that @aclements is working on “safe points everywhere” which might make this infeasible.

I wonder whether it’d help to concoct a branch-free way to calculate inc.

@rasky
Copy link
Member

rasky commented Mar 10, 2018 •
edited

It's already branch-free, but it's still expensive. With this and the writer barriers, people will always have to remove slicing from performance-critica code, unless we agree on a way forward.

@navytux
Copy link
Contributor

navytux commented Mar 10, 2018

For the reference - the write barrier at b = b[3:] might be maybe omitted: #24314 (still waiting for @aclements feedback).

@randall77
Copy link
Contributor Author

No, I'm still not sure how you would do this. And @josharian is right, if we get safe points everywhere this gets significantly harder.

@aclements
Copy link
Member

If you can ensure the out-of-bounds pointer won't be live for more than an instruction or two, it might be okay to mark those as unsafe points. We're absolutely going to need unsafe points for the write barrier, but I've been working on removing them from other compiler constructs (like range loops).

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Performance
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@josharian @rasky @navytux @aclements @randall77 @gopherbot