Measure and modify Go garbage collection behavior on AWS Graviton-based compute
Introduction
Choose an AWS Graviton-based instance for Go garbage collection benchmarking
Install Go and Benchstat on an AWS Graviton-based Amazon EC2 instance
Create a Go garbage collection benchmark
Run the benchmark with default Go garbage collection settings
Interpret the default garbage collection benchmark results
Experiment with garbage collection optimization
Next Steps

  Log an issue

  Fork and edit

  Discuss on Discord

About this Learning Path

Skill level:  Introductory
Reading time:  1 hr 15 min
Last updated:  14 Sep 2026
Skill level:
  Introductory
Reading time:
  1 hr 15 min
Last updated:
  14 Sep 2026
Author:Geremy Cohen, Arm
Arm IP:Neoverse
Tags: Performance and Architecture AWS Graviton Linux Go Benchstat
Author:
  • Geremy Cohen, Arm
Arm IP:
Neoverse
Tags:
Performance and Architecture AWS Graviton Linux Go Benchstat

Who is this for?

This Learning Path is for engineers interested in learning more about Go garbage collection (GC) behavior on Arm.

What will you learn?

Upon completion of this Learning Path, you will be able to:

  • Select an AWS Graviton-based instance for repeatable Go GC measurements
  • Install Go and Benchstat on an Arm Linux server
  • Run a Go benchmark that reports allocation, GC, and pause-time metrics
  • Capture CPU and heap profiles without changing GC behavior
  • Interpret benchmarking results and experiment with changing GC behavior

Prerequisites

Before starting, you will need the following:

  • An AWS account with permission to launch an AWS Graviton-based Amazon EC2 instance running Ubuntu 24.04 LTS or another Arm Linux distribution
  • The AWS CLI installed and configured on your local machine
  • Basic familiarity with Go benchmarks and Linux shell commands

Summary

AI-assisted

This summary was drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
You’ll establish a Go GC baseline on an AWS Graviton-based Arm server. First, you’ll install Go and Benchstat and confirm default runtime settings. Then, you’ll run a benchmark and collect allocation, pause, and GC metrics with CPU and heap profiles. You’ll compare results with Benchstat before experimenting with GC behavior and measuring its impact.

Frequently asked questions

AI-assisted

These FAQs were drafted with an approved AI-assisted workflow and reviewed by Arm contributors before publication. Human technical review remains part of the process so the final page reflects engineering rigor, accuracy, and Arm editorial standards.

Close
?
How do I verify the instance and Go toolchain are Arm-based before benchmarking?
Run go version and check that it reports linux/arm64. Also run go env GOOS GOARCH and confirm GOARCH is arm64.
What should I check to keep the default Go GC baseline intact?
Confirm that GOGC, GOMEMLIMIT, GODEBUG, and GOMAXPROCS aren’t set. Use env | grep -E '^(GOGC|GOMEMLIMIT|GODEBUG|GOMAXPROCS)=' || true and unset any variables that appear.
What result should I expect after the baseline benchmark run?
You should have a runtime snapshot (Go version, GOOS/GOARCH, CPU count, and memory) and raw benchmark output in default_gc_benchmark.txt. Run benchstat default_gc_benchmark.txt next to create the summary used to compare and interpret the baseline metrics.
How do I interpret the Benchstat metrics related to GC?
ns/op shows time per operation (lower is faster), B/op shows bytes allocated per operation, and allocs/op shows the number of allocations per operation—lower values generally reduce GC pressure. gc/op indicates how often GC cycles occur per operation. A lower gc/op means GC runs less frequently for the same work.
How do I capture CPU and heap profiles without changing GC behavior?
Leave GOGC, GOMEMLIMIT, GODEBUG, and GOMAXPROCS unset and run the benchmark using the profiling commands. The run writes CPU and heap profiles alongside the benchmark results while preserving default GC behavior.
Next