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

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

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

Comments

Projects
None yet
5 participants
@randall77
Contributor

randall77 commented Apr 21, 2016

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

@rasky

This comment has been minimized.

Member

rasky commented Mar 10, 2018

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

@josharian

This comment has been minimized.

Contributor

josharian commented Mar 10, 2018

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

This comment has been minimized.

Member

rasky commented Mar 10, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

randall77 commented Mar 10, 2018

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

This comment has been minimized.

Member

aclements commented Mar 12, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment