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: refactor into separate subpackages #11647

Open
michaelmatloob opened this Issue Jul 9, 2015 · 11 comments

Comments

Projects
None yet
10 participants
@michaelmatloob
Contributor

michaelmatloob commented Jul 9, 2015

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.

@michaelmatloob michaelmatloob changed the title from refactor the runtime into separate packages to runtime: refactor the into separate subpackages Jul 9, 2015

@ianlancetaylor ianlancetaylor changed the title from runtime: refactor the into separate subpackages to runtime: refactor into separate subpackages Jul 10, 2015

@ianlancetaylor ianlancetaylor modified the milestones: Go1.6, Go1.6Early Jul 10, 2015

@robpike

This comment has been minimized.

Contributor

robpike commented Jul 10, 2015

Why, exactly?

@michaelmatloob

This comment has been minimized.

Contributor

michaelmatloob commented Jul 26, 2015

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

This comment has been minimized.

Contributor

josharian commented Jul 27, 2015

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

This comment has been minimized.

Contributor

michaelmatloob commented Nov 10, 2015

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

@gopherbot

This comment has been minimized.

gopherbot commented Nov 11, 2015

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

gopherbot pushed a commit that referenced this issue Nov 12, 2015

runtime: break out system-specific constants into package sys
runtime/internal/sys will hold system-, architecture- and config-
specific constants.

Updates #11647

Change-Id: I6db29c312556087a42e8d2bdd9af40d157c56b54
Reviewed-on: https://go-review.googlesource.com/16817
Reviewed-by: Russ Cox <rsc@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented Nov 12, 2015

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

gopherbot pushed a commit that referenced this issue Nov 12, 2015

runtime: move arch_mips64(le)?.go into runtime/internal/sys
Somehow these were left out of the orignial CL.

Updates #11647

Change-Id: I058a30eaa25fbb72d60e7fb6bc9ff0a3b54fdb2a
Reviewed-on: https://go-review.googlesource.com/16870
Reviewed-by: Minux Ma <minux@golang.org>
@gopherbot

This comment has been minimized.

gopherbot commented Nov 12, 2015

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

gopherbot pushed a commit that referenced this issue Nov 12, 2015

runtime: delete runtime/internal/atomic/textflag.h
As per mdempsky's comment on golang.org/cl/14204, textflag.h is
copied to the includes dir by cmd/dist, and the copy in
runtime/internal/atomic is not actually being used.

Updates #11647

Change-Id: Ie95c08903a9df54cea4c70ee9d5291176f7b5609
Reviewed-on: https://go-review.googlesource.com/16871
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
@rsc

This comment has been minimized.

Contributor

rsc commented Nov 24, 2015

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

@rsc rsc modified the milestones: Go1.7Early, Go1.6Early Nov 24, 2015

@bradfitz bradfitz modified the milestones: Go1.8, Go1.7Early May 6, 2016

@josharian

This comment has been minimized.

Contributor

josharian commented May 18, 2016

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.

@quentinmit quentinmit added the NeedsFix label Oct 11, 2016

@bradfitz

This comment has been minimized.

Member

bradfitz commented Oct 28, 2016

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

@bradfitz bradfitz modified the milestones: Go1.9, Go1.8 Oct 28, 2016

@gopherbot

This comment has been minimized.

gopherbot commented Apr 25, 2017

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

@aclements aclements modified the milestones: Go1.10, Go1.9 Jun 9, 2017

@rsc rsc removed this from the Go1.10 milestone Nov 22, 2017

@rsc rsc added this to the Go1.11 milestone Nov 22, 2017

@aclements aclements modified the milestones: Go1.11, Unplanned Jul 3, 2018

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