runtime: refactor into separate subpackages

golang / go

The Go programming language

https://go.dev

BSD 3-Clause "New" or "Revised" License

121.58k stars 17.41k forks source link

runtime: refactor into separate subpackages #11647

Open michaelmatloob opened 9 years ago

michaelmatloob commented 9 years ago

Now that the runtime is Go code, we should be able to break it apart into multiple packages.

Among other things we should consider putting locking, the gc, and special symbols in separate packages.

robpike commented 9 years ago

Why, exactly?

michaelmatloob commented 9 years ago

Now that the runtime is written in Go, it's worth taking the time to consider whether it could be better organized if it were split into packages. I think it could. Splitting the runtime into packages could also help improve the readability, in the style sense, of the code. That would make the runtime more accessible to new contributors.

It was also suggested by crawshaw that putting certain parts of the runtime into their own packages would make it easier to stub out or replace parts of the runtime. That would be helpful when bootstrapping a new architecture or os, where all of the runtime is not available, or in creating a modified runtime that would run without an os.

josharian commented 9 years ago

I'm in favor of splitting up the runtime, at least insofar as it is mostly just movement of existing code. This has the following advantages:

Makes the structure and components of the runtime more obvious. There really are several basically standalone pieces.
Faster to run runtime tests when making modifications. (This is a pain point; the runtime tests are slow.)
Easier to do safe refactoring and experimentation.
Having a runtime/internal/magic package will make it more obvious where the runtime touches the compiler.

michaelmatloob commented 8 years ago

CL https://golang.org/cl/14204 updates this issue.

gopherbot commented 8 years ago

CL https://golang.org/cl/16817 mentions this issue.

gopherbot commented 8 years ago

CL https://golang.org/cl/16870 mentions this issue.

gopherbot commented 8 years ago

CL https://golang.org/cl/16871 mentions this issue.

rsc commented 8 years ago

We got a couple subpackages in for Go 1.6. More work in Go 1.7.

josharian commented 8 years ago

Another advantage to this: More of the runtime could be build concurrently. It's not super slow to build, but it always runs first, and linearly, since everything else depends on it. See the graph at #15734.

bradfitz commented 7 years ago

Bumping this to Go 1.9. Not sure anything happened in Go 1.8 but it seems too late now.

gopherbot commented 7 years ago

CL https://golang.org/cl/41650 mentions this issue.

gopherbot commented 5 years ago

Change https://golang.org/cl/171702 mentions this issue: devapp/owners: remove josharian from runtime

bcmills commented 5 years ago

At the very least, if there are parts of runtime that are not tightly coupled to the implementation details of the compiler, it would probably help maintainers of other compliers (such as TinyGo) to split those parts into separate subpackages. (See #31330.)

josharian commented 2 years ago

Another advantage to doing this: Any parts of the runtime not involved in scheduling can have their race/msan instrumentation done by the compiler rather than manually.