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.

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

runtime: move internals to internal/runtime #65355

Open
prattmic opened this issue Jan 29, 2024 · 9 comments
Open

runtime: move internals to internal/runtime #65355

prattmic opened this issue Jan 29, 2024 · 9 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@prattmic
Copy link
Member

Right now package runtime appears to serve two purposes:

  • It contains most of the implementation of the Go runtime.
  • And, it exposes the world-public API for various runtime-related functionality (runtime.GOMAXPROCS, etc).

At first glance, this seems perfectly normal and reasonable, however there is actually a third purpose:

  • Expose std-internal APIs that should not be world-public. e.g., runtime.semacquire for sync.Mutex or runtime.netpollopen for os and net.

These APIs should not be public to the whole world as they are implementation details that may change. However, with the current layout there is no good way to expose these internal APIs, so we must use //go:linkname between packages, and in some cases copy entire type definitions between packages (#64549).

If we move most of the runtime implementation to internal/runtime, then it could expose a richer API surface useful to other packages in std, but nothing outside of std would be able to access them due to the rules of internal. Package runtime would remain to provide the same API, but it would be much smaller and simply import internal/runtime for most functionality.

In moving, there are also opportunities for cleanup along the lines of #51087. e.g., perhaps the timer implementation is in internal/runtime/timer, etc. Though this move isn't really a prerequisite for that; we could do that in runtime/internal/timer as well.

This change would technically be solely an implementation detail, though in practice there are likely symbols that folks depend on anyway, either via linkname (https://go.dev/cl/548235) or implicitly by looking for in profiles, stack traces, etc.

cc @golang/runtime

@prattmic prattmic added the NeedsFix The path to resolution is known, but the work has not been done. label Jan 29, 2024
@prattmic prattmic added this to the Backlog milestone Jan 29, 2024
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jan 29, 2024
@mauri870
Copy link
Member

I really like the idea of having a internal/runtime package. The runtime code always felt too "convoluted" for me. It grew a lot with time to the point it is now a sum of numerous assembly files, internal code for the GC and auxiliary runtime stuff, race, asan, msan code, and buried in the middle of all this the public runtime apis. I believe having an internal package dedicated to these bits would hopefully clean runtime enough that it will be easier to navigate and more inlined with the other standard library packages.

@gopherbot
Copy link

Change https://go.dev/cl/559076 mentions this issue: runtime,time: clean duplicate definitions time.runtimeTimer and runtime.timer

qiulaidongfeng added a commit to qiulaidongfeng/go that referenced this issue Jan 31, 2024
For golang#65355

Change-Id: I32f37b2971996d50451505e412157dd49b29f581
@gopherbot
Copy link

Change https://go.dev/cl/559675 mentions this issue: runtime,reflect: clean duplicate definitions runtimeSelect

@gopherbot
Copy link

Change https://go.dev/cl/559715 mentions this issue: runtime: migrate internal/syscall to internal/runtime

@gopherbot
Copy link

Change https://go.dev/cl/560155 mentions this issue: runtime: migrate internal/atomic to internal/runtime

@gopherbot
Copy link

Change https://go.dev/cl/560136 mentions this issue: syscall: call internal/runtime/syscall.Syscall6 in RawSyscall6

Jun10ng added a commit to Jun10ng/go that referenced this issue Feb 1, 2024
Jun10ng added a commit to Jun10ng/go that referenced this issue Feb 1, 2024
@gopherbot
Copy link

Change https://go.dev/cl/560395 mentions this issue: Clean up duplicate function IssystemGoroutine

@gopherbot
Copy link

Change https://go.dev/cl/560596 mentions this issue: runtime: clean up duplicate function isSystemGoroutine

qiulaidongfeng added a commit to qiulaidongfeng/go that referenced this issue Feb 7, 2024
For golang#65355

Change-Id: If676bffe28ae3f20e4ed15a56993811bee05ef22
@gopherbot
Copy link

Change https://go.dev/cl/562296 mentions this issue: runtime,reflect: clean duplicate definitions itab

gopherbot pushed a commit that referenced this issue Feb 21, 2024
For #65355

Change-Id: I5fefe30dcb520159de565e61dafc74a740fc8730
Reviewed-on: https://go-review.googlesource.com/c/go/+/559715
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
Development

No branches or pull requests

3 participants