From af82f39e11f682d2be514b09e9b364dd1db0bc62 Mon Sep 17 00:00:00 2001
From: Benjamin Woodruff <benjamin.woodruff@vercel.com>
Date: Mon, 5 Aug 2024 17:01:48 -0400
Subject: [PATCH] [turbopack] Minimal implementation of local Vcs (#68469)

*This is a migrated PR. This was in the turbo repository before the
next.js merge.*
**Migrated From:** https://github.com/vercel/turbo/pull/8780

# Description

Local Vcs store task-local values inside of the current task's state.
The `SharedReference` holding onto their values is dropped when the task
exits.

The contents of a local Vc must still use a refcounted
`SharedReference`/`triomphe::Arc` because they can be turned into
`ReadRef` objects
(https://turbopack-rust-docs.vercel.sh/rustdoc/turbo_tasks/struct.ReadRef.html),
which require a `'static` lifetime. We can experiment with adding a
lifetime to `ReadRef` in a future iteration, but there's little
advantage to doing this until we have local tasks.

# Limitations

This implements *just enough* to create and read local Vcs (with a
test!). There are many things that are still unimplemented with
`todo!()`. Most notably:

- We can't resolve a local `Vc` to a `ResolvedVc`.
- There's no way to return or pass a local `Vc` as an argument yet.
- For safety, we should only allow construction of local `Vc`s in
functions where we know that the return value is a `ResolvedValue`.

Grand plan:
https://www.notion.so/vercel/Resolved-Vcs-Vc-Lifetimes-Local-Vcs-and-Vc-Refcounts-49d666d3f9594017b5b312b87ddc5bff

# Memory Usage

- This increases the size of `Vc`/`RawVc` from 96 bits to 128 bits. With
clever packing this could (in theory) be solved. However, that it
increase the number of machine words (2x 64bit), so it might not have
any real impact after alignment happens.

- This increase the size of `CurrentTaskState`. I suspect this isn't too
bad as there should be a smallish number of tasks active at any given
time.

**I was not able to measure any change to peak memory/heap usage.**

Built using

```
cargo build --release -p next-build-test
```

Ran heaptrack on a single page (`/sink`) in `shadcn/ui` with:

```
cd ~/ui/apps/www
heaptrack ~/nextpack/target/release/next-build-test run sequential 1 1 '/sink'
```

And analyzed the results with

```
heaptrack --analyze /home/bgw.linux/ui/apps/www/heaptrack.next-build-test.3066837.zst | tail -20
```

### Before

```
total runtime: 130.25s.
calls to allocation functions: 48553541 (372786/s)
temporary memory allocations: 3863919 (29666/s)
peak heap memory consumption: 1.13G
peak RSS (including heaptrack overhead): 2.69G
total memory leaked: 4.96M
suppressed leaks: 7.24K
```

```
total runtime: 135.48s.
calls to allocation functions: 48619554 (358863/s)
temporary memory allocations: 3883888 (28667/s)
peak heap memory consumption: 1.12G
peak RSS (including heaptrack overhead): 2.70G
total memory leaked: 4.71M
suppressed leaks: 7.24K
```

### After

```
total runtime: 157.20s.
calls to allocation functions: 48509638 (308579/s)
temporary memory allocations: 3902883 (24827/s)
peak heap memory consumption: 1.13G
peak RSS (including heaptrack overhead): 2.70G
total memory leaked: 4.86M
suppressed leaks: 7.24K
```

```
total runtime: 130.25s.
calls to allocation functions: 48553541 (372786/s)
temporary memory allocations: 3863919 (29666/s)
peak heap memory consumption: 1.13G
peak RSS (including heaptrack overhead): 2.69G
total memory leaked: 4.96M
suppressed leaks: 7.24K
```

# Testing Instructions

```
cargo nextest r -p turbo-tasks -p turbo-tasks-memory
```