Mau Aplikasi Gacor? Wajib Ngerti Value Type

Core idea: “Value types” to reduce GC pressure and latency

Many modern back-end/application stacks rely on garbage collection (GC), which tracks and cleans heap objects.

However, GC can introduce GC pauses—where the application briefly “stops” to reclaim memory—causing CPU spikes and latency spikes, even when the underlying algorithms are efficient.

A common performance strategy is to keep short-lived data from landing on the heap. Instead, prefer value types so values can live on the stack.

---

Stack vs Heap (and why it matters)

Heap (the “bucket” GC watches)

• When you create reference-like objects (or pointers), their data typically ends up on the heap.
• GC must:
  • track references
  • determine what’s unused
  • clean up unreachable objects
• As the heap fills with allocated objects, GC runs more often, leading to more pauses and higher latency.

Stack (short-lived “work desk” values)

• The stack holds short-lived values.
• Data is automatically cleared when it goes out of scope.
• Stack allocation typically avoids GC tracking overhead, reducing allocation overhead and avoiding GC pauses for those values.

---

What “value type” means in the programming-language sense

The discussion distinguishes language “value types” (e.g., structs in Go/C# style) from similarly named DDD value objects.

In languages like Go:

• A non-pointer value type (e.g., a struct used as a value) can remain on the stack.
• If it becomes a pointer/reference, it may escape to the heap and become more expensive.

---

Go-specific performance tool: Escape analysis

The speaker introduces escape analysis: the compiler determines whether a value escapes its scope. If it does, it moves to the heap.

Common patterns that trigger heap escape in Go include:

• Returning or storing values as pointers
• Storing in fields or passing to functions that accept pointers
• Converting to interface types
  • Example mentioned: fmt.Println uses an “empty interface”, which can force escaping
• Capturing large values in closures

---

Tutorial/demo included (GitHub link + tools/commands)

An example Go project is shown (referenced via a link in the video description) to demonstrate whether values end up on stack vs heap.

Using escape analysis output

Escape analysis is enabled via compiler flags (example form shown):

• -gcflags "-m" (to view escape decisions and “escape lift” behavior)

Demonstrated outcomes (conceptual examples)

• Using a point via pointers → moves to heap
• Keeping a point as a value and only using x + y → does not escape
• Even if it’s a value type, passing it into fmt.Println (interface conversion) can cause escape for that variable

---

Benchmark section: “heap vs stack” performance comparison

The video benchmarks two approaches:

1. Allocate/use points on the heap (e.g., via pointers / “new heap”)
2. Use points as stack values (e.g., “new stack” / no pointers)

Example reported behavior

Heap usage

• Allocations grow (example: on the order of 10 million)
• GC runs many times (example: ~42 GC runs)
• More overhead and pauses show up

Stack usage

• Heap allocations drop to near zero
• GC doesn’t run in the demo

Conclusion

The stack/value approach is reported as significantly faster (speaker cites ~11x in the simple test, with potentially larger gains in realistic scenarios).

---

Practical application guidance (backend/server workloads)

The guidance is to design request-lifecycle code so objects are short-lived:

• Most web backends are stateless per request
• If each request allocates data and then discards it after completion, stack-style lifetimes can reduce or eliminate GC work

A summarized heuristic:

• “Use the heap as small as possible”
• Avoid creating long-lived references unnecessarily across requests

---

Java note: lack of value types (Valhalla mentioned)

Historically, the speaker says Java lacked true value types like Go/C# structs—so complex types tend to become heap objects.

Project Valhalla is presented as the expected path forward:

• Introduces a value record concept (e.g., value Point / “value record”)
• Expected optimization: represent fields in a more primitive-like, stack-friendly form

Status mentioned: discussed/under development with speculative timing.

---

Other languages / general conclusion

• Many languages support some form of value types.
• In languages with manual memory control (e.g., C/C++), you can explicitly choose lifetimes.

Final takeaway

• GC load increases when you allocate many objects to the heap
• For best performance, prefer value types / stack allocation where possible
• Avoid patterns that create unnecessary pointers/references
• Avoid patterns that force escape to heap

---

Main speakers/sources

• Speaker: An Indonesian tech presenter (narrator), discussing Go/C#/Java memory model concepts.
• Source/tooling referenced:
  • GitHub example project (linked in the video description; specific repo not included in subtitles)
  • Go compiler escape analysis (GC flags such as -gcflags "-m")
  • Java Valhalla (Project Valhalla / JEP mentioned as JP401)
  • Benchmarks via a GC benchmark section in the example project