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

cmd/compile/internal/types: lazy/incremental type expansion #25056

Open
mdempsky opened this issue Apr 24, 2018 · 4 comments
Open

cmd/compile/internal/types: lazy/incremental type expansion #25056

mdempsky opened this issue Apr 24, 2018 · 4 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. ToolSpeed
Milestone

Comments

@mdempsky
Copy link
Member

The compiler now supports an indexed data format for package export data that enables efficient random-access of package data. We already use this to implement lazy expansion of declarations and inline bodies, but we still currently fully expand types whenever they're referenced. I expect in larger projects that a lot of deeply nested details are never needed and we could avoid reading that data into memory.

I think the steps are largely:

  1. Hide remaining Type fields behind setter/getter methods.
  2. Create a new TSTUB Type with a way to register an expander function that rewrites the Type into a real Go type.
  3. Add a Type.expand method that checks for Etype==TSTUB and calls the expander function.
  4. Insert calls to expand() at the top of every(?) public Type method.
  5. Update iimport.go to create TSTUB types instead of normal types.

Another useful (but non-critical) step would be to review the Type API and try to prune/simplify unnecessary methods. This would reduce how many places we need to instrument with expand calls.

@mdempsky mdempsky added this to the Go1.11 milestone Apr 24, 2018
@mdempsky
Copy link
Member Author

Optimistically tagging for 1.11, but freeze is one week away, so this will probably slip.

@gopherbot
Copy link

Change https://golang.org/cl/109138 mentions this issue: cmd/compile/internal/types: replace Type.Val with Type.Elem

gopherbot pushed a commit that referenced this issue Apr 24, 2018
This reduces the API surface of Type slightly (for #25056), but also
makes it more consistent with the reflect and go/types APIs.

Passes toolstash-check.

Change-Id: Ief9a8eb461ae6e88895f347e2a1b7b8a62423222
Reviewed-on: https://go-review.googlesource.com/109138
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@mdempsky mdempsky modified the milestones: Go1.11, Go1.12 May 1, 2018
@mdempsky
Copy link
Member Author

mdempsky commented May 1, 2018

Not happening for 1.11.

@griesemer
Copy link
Contributor

Also not happening for 1.12.

@griesemer griesemer modified the milestones: Go1.12, Go1.13 Oct 30, 2018
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@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
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. ToolSpeed
Projects
Status: Triage Backlog
Development

No branches or pull requests

5 participants