Retire the experimental 4 GB memory profile

apps/website/content/en/1.docs/3.upstream/2.request-summary.md

@@ -3,7 +3,7 @@ title: Request summary and priority
 ref: docs/upstream/request-summary
 description: All twelve upstream requests in one table, with priority, estimated effort, blast radius, and the host workaround that each fix removes.
 icon: lucide:list-checks
-updated: 2026-08-08
+updated: 2026-08-13
 navigation:
   title: Request summary
 ---
@@ -72,7 +72,7 @@ Read them as a rough size, not a commitment.
 :::card{title="Input" description="Three defects in mouse, cursor, and keyboard handling." icon="lucide:mouse-pointer-click" to="$docs/upstream/input/double-click-flag"}
 `UR-07` to `UR-09`
 :::
-:::card{title="Runtime" description="Sessions can stop at the 2 GiB cap. A paired 4 GB build buys time; a heap profile must classify retention, fragmentation, or live ownership." icon="lucide:cpu" to="$docs/upstream/runtime/heap-maximum"}
+:::card{title="Runtime" description="Sessions can stop at the 2 GiB cap. Our post-build 4 GB experiment was withdrawn; a heap profile must classify retention, fragmentation, or live ownership." icon="lucide:cpu" to="$docs/upstream/runtime/heap-maximum"}
 `UR-10`
 :::
 :::card{title="Interface proposals" description="Two proposals. They do not correct a defect." icon="lucide:plug" to="$docs/upstream/proposals/build-identification"}

apps/website/content/en/1.docs/3.upstream/5.runtime/1.heap-maximum.md

@@ -3,11 +3,19 @@ title: "UR-10: long sessions stop at the 2 GiB heap cap"
 ref: docs/upstream/runtime/heap-maximum
 description: Build 38797 has a fixed 2 GiB WebAssembly heap. We can prove the ceiling and the failed allocation, but cache retention, fragmentation, and live working set still require an ArenaNet heap profile.
 icon: lucide:cpu
-updated: 2026-08-08
+updated: 2026-08-13
 navigation:
   title: Heap maximum (UR-10)
 ---
 
+::warning{title="The experimental 4 GB profile has been withdrawn"}
+Two users reported severe graphical corruption after 30–45 minutes with the
+post-build 4 GB transform enabled. GWonMac has removed the option and restores
+ArenaNet's standard 2 GiB contract on startup. The reports are strong safety
+evidence, not proof of the exact corrupt pointer path. A compiler-supported
+ArenaNet rebuild or a source-level cache-lifecycle fix remains required.
+::
+
 Some content-heavy sessions end when the WebAssembly heap reaches exactly
 2,147,483,648 bytes. That maximum is declared in both artifacts ArenaNet ships:
 the WASM memory section and its generated JavaScript glue. The next allocation
@@ -171,9 +179,9 @@ GWonMac's production warning monitors the effective heap capacity while there
 is still room to return to a town or outpost, then lets the player choose when
 to reload. Reloading resets the WASM heap. It is recovery, not a memory fix.
 
-### Exact-build 4 GB research profile
+### Withdrawn exact-build 4 GB research profile
 
-We have also built an off-by-default research profile for build 38797. It
+We built an off-by-default research profile for build 38797. It
 changes the WASM maximum to 65,535 pages—4 GiB minus one 64 KiB page—and
 transforms the exact generated JavaScript to treat high wasm32 pointers as
 unsigned addresses.
@@ -191,17 +199,12 @@ Qualification completed so far:
 - the transformed generated string glue wrote and read `GW4G` through that
   high pointer without trapping.
 
-This proves the core approach across the former boundary. It does not prove
-every rare WebGL or host callback path, and it does not bound the underlying
-memory demand. The current profile remains a developer experiment. All five
-variants the production chain can emit—including Enhancements disabled—are
-hash-pinned. It still needs packaged high-address gameplay coverage,
-system-memory testing, and an explicit user setting before an experimental
-player release.
-
-If released before an ArenaNet update, it will be labelled **Experimental 4 GB
-memory mode**, disabled by default, restricted to exact certified builds, easy
-to turn off, and recommended only on Macs with at least 16 GB of RAM.
+Those tests proved selected allocator and JavaScript glue paths across the
+former boundary. They did not prove every WebGL or host callback path. After
+release, two users reported severe graphical corruption after 30–45 minutes
+with the option enabled. The profile is therefore withdrawn and its executable
+transform and certificates have been deleted. Git history preserves the
+research; it is not available through a hidden switch.
 
 ## What we will not do
 
@@ -226,15 +229,13 @@ For ArenaNet's corrective build:
   work above 2 GiB;
 - the client retains a clear failure reason if it exhausts the new maximum.
 
-For our optional mitigation, every accepted JS/WASM pair must be pinned to an
-exact ArenaNet build, unknown builds must remain untouched, the mode must be
-visible in diagnostics, and disabling it must restore ordinary client behavior
-after restart.
+Historical archives containing the experiment remain readable and are labelled
+as legacy captures.
 
 ## Current conclusion
 
 The 2 GiB limit and final failed allocation are in ArenaNet's shipped client.
 The reason some sessions consume the available address space still needs an
-ArenaNet source-level heap profile. Until that is fixed, a safe reload remains
-the conservative mitigation and an exact-build 4 GB mode can provide optional
-headroom for informed testers.
+ArenaNet source-level heap profile. Until that is fixed, the warning and
+user-controlled safe reload remain the only client-side mitigation we consider
+safe.

apps/website/content/en/1.docs/3.upstream/7.reference/1.our-workarounds.md

@@ -3,14 +3,15 @@ title: Our workarounds, and what each fix removes
 ref: docs/upstream/reference/our-workarounds
 description: What GWonMac does to the client today, why each workaround exists, what it costs us per client build, and exactly what we delete after each upstream fix.
 icon: lucide:wrench
-updated: 2026-08-08
+updated: 2026-08-13
 navigation:
   title: Our workarounds
 ---
 
 This page is everything our host does to the client today: why each workaround
 exists, what it costs per client build, and exactly what each upstream fix
-lets us delete.
+removes. The withdrawn memory experiment remains below as an explicitly marked
+historical record.
 
 ## Ground rules
 
@@ -126,21 +127,20 @@ memory capacity cannot shrink inside one process; reload starts a new heap.
 ownership policy is bounded and long content-diverse sessions remain well
 below the effective cap. The general crash-recovery path remains.
 
-## Research profile — paired 4 GB JS/WASM transform
+## Withdrawn research profile — paired 4 GB JS/WASM transform
 
 **Reduced or removed by:** `UR-10`.
 
-An off-by-default developer profile raises build 38797's WASM maximum to 4 GiB
+An off-by-default developer profile raised build 38797's WASM maximum to 4 GiB
 minus one page and transforms the matching generated JavaScript to normalize
 wasm32 pointers above 2 GiB. It is a paired transform: changing only the WASM
 maximum would hand negative pointer values to JavaScript and is refused.
 
-The exact pair has passed ArenaNet-allocator qualification above 3 GiB and a
-live Electron string-glue test at 2,625 MiB. It remains a research profile, not
-a default player setting. All five variants the production chain can emit are
-hash-pinned. Before an experimental release it still needs packaged
-high-address gameplay coverage, system-memory testing, and explicit opt-in
-copy. Diagnostics record the effective mode and cap.
+The exact pair passed allocator qualification above 3 GiB and a live Electron
+string-glue test at 2,625 MiB. Those bounded tests were not enough: two users
+later reported severe graphical corruption after 30–45 minutes with the option
+enabled. We withdrew and deleted the executable profile. This is strong safety
+evidence, not proof of the exact corrupt pointer path.
 
 **Cost per client build.** Both official artifact hashes, every accepted
 predecessor hash, both derived hashes, and the generated-glue pointer audit.
@@ -165,5 +165,5 @@ headroom.
 Six of the twelve requests exist because of file handling; one exists because
 of a single unwritten byte. Fix `UR-01` to `UR-07` and three production
 workarounds disappear outright. A source-level `UR-10` correction also avoids
-turning the research-only 4 GB profile into another permanent certification
-burden.
+depending on another post-build 4 GB transform. A compiler-supported ArenaNet
+rebuild or cache-lifecycle fix remains required.

apps/website/content/en/2.blog/4.gwonmac-tools-is-here.md

@@ -7,6 +7,12 @@ readingTime: 5 min read
 author: authors/matamo
 ---
 
+::warning{title="Update: experimental 4 GB option withdrawn"}
+We removed this option after two reports of severe graphical corruption during
+30–45 minute sessions. GWonMac now restores ArenaNet's standard 2 GB limit on
+startup. The memory warning and Reload Guild Wars recovery remain available.
+::
+
 Release `2026.8.5` introduces **GWonMac Tools Beta**: a local build and team manager made specifically for Guild Wars on Mac.
 
 You can capture your current party, create player and hero builds, reorder heroes and skills, share complete teams, and apply a saved setup from a supported PvE outpost. The release also adds template import and export, an experimental 4 GB memory limit, and two interface styles.
@@ -65,17 +71,17 @@ You can also publish a build from Tools into Guild Wars. The Tools library and t
 
 Read the [template migration guide](/docs/guides/templates) for the complete workflow.
 
-## More memory headroom for long sessions
+## Historical: experimental memory headroom
 
 Guild Wars normally has a 2 GB memory limit. Very long sessions can eventually approach it and may need a reload.
 
-You can now opt into an experimental 4 GB limit under:
+This release originally offered an experimental 4 GB limit under:
 
 **Settings → Advanced → Experimental 4 GB memory limit**
 
-The option is off by default and requires restarting Guild Wars. Settings shows whether the current session is using 2 GB or 4 GB.
-
-The larger limit provides more headroom and may help during long sessions. It does **not** stop memory from continuing to grow. If 4 GB mode is unavailable for the current Guild Wars version, GWonMac safely starts in normal 2 GB mode instead.
+The option has since been withdrawn because it can cause severe graphical
+corruption during long sessions. Current versions remove existing opt-ins and
+always use ArenaNet's original 2 GB JS/WASM pair.
 
 The new memory warning stays out of the way and lets you reload Guild Wars directly when the current session is running low.
 
@@ -119,7 +125,7 @@ The most useful feedback now is:
 - Repeated Team Apply runs with different hero professions and skill bars
 - Normal and Hard Mode application
 - Larger or unusual hero rosters
-- Long sessions using the experimental 4 GB limit
+- Long sessions using the standard memory warning and Reload Guild Wars recovery
 - Interface and layout behavior on smaller Mac displays
 
 If something fails, tell us what you expected, what Guild Wars showed afterward, and which Mac you use.

docs/diagnostics.md

@@ -170,9 +170,9 @@ A failed growth request at the compiled limit proves that the official client
 requested more memory than that module permits. It does not identify which
 client subsystem retained the earlier allocations.
 
-Function indices apply only to the exact captured module. The 4 GB option
-records requested and effective state. An unavailable certified profile falls
-back to the ordinary module with a closed reason.
+Function indices apply only to the exact captured module. Older archives may
+contain the withdrawn 4 GB profile's requested and effective state; current
+versions decode that legacy evidence but never emit or activate the profile.
 
 ## Performance measurement rule
 

docs/user-guide.md

@@ -150,14 +150,12 @@ Password fields are never copied.
 The official web client cannot copy text that it only displays, such as chat
 history or item names.
 
-## Extended memory
+## Memory recovery
 
-**Advanced → Experimental 4 GB memory limit** requests the certified 4 GB module
-for the next start. Restart `gwonmac` after changing it.
-
-If the current ArenaNet build has no 4 GB certificate, the app uses the ordinary
-2 GB module. The larger limit can delay a memory-related crash. It cannot stop
-memory that continues to grow.
+Guild Wars uses ArenaNet's standard 2 GB WebAssembly memory limit. A previously
+released experimental 4 GB option was withdrawn after reports of severe
+graphical corruption during long sessions. Existing opt-ins are removed when
+GWonMac next starts.
 
 When the app warns about memory, choose **Reload Guild Wars**. Guild Wars
 normally reconnects. Reload in an outpost when you want the lowest gameplay

internal/upstream/memory-exhaustion-log.md

@@ -1,6 +1,7 @@
 # Long-session WebAssembly memory exhaustion
 
-> **Status: cause confirmed; upstream growth cause unresolved.** This is a
+> **Status: cause confirmed; upstream growth cause unresolved; 4 GB host
+> mitigation withdrawn.** This is a
 > historical investigation record. Current diagnostics behavior is defined by
 > [Diagnostics](../../docs/diagnostics.md).
 
@@ -14,6 +15,13 @@ Increasing `MAXIMUM_MEMORY` to 4 GB would buy about 2.5 times the usable memory
 on the measured client. It would not fix the continuing growth. The evidence
 does not distinguish a leak, fragmentation, or retained content.
 
+GWonMac briefly shipped an exact-build post-build 4 GB transform. It was
+withdrawn after two users reported severe graphical corruption after 30–45
+minutes with the option enabled. That is strong evidence that the transform is
+not safe to ship, although it does not prove the exact corrupt pointer path. A
+compiler-supported ArenaNet rebuild or a source-level cache-lifecycle fix is
+still required.
+
 gwonmac records heap growth and warns before likely exhaustion. It does not show
 a minutes-remaining estimate to players because real workloads made that number
 misleading.

package.json

@@ -57,7 +57,6 @@
     "diagnostics:compare": "tsc && node build/tools/diagnostics/compare.js",
     "diagnostics:attribute-stalls": "tsc && node build/tools/diagnostics/attribute-stalls.js",
     "diagnostics:attribute-frames": "tsc && node build/tools/diagnostics/attribute-frames.js",
-    "memory:qualify:4gb": "node --import ./scripts/ts-hook.mjs --experimental-strip-types scripts/qualify-extended-memory.ts",
     "verify:runtime": "pnpm check && pnpm build && node scripts/verify-companion-kernel.mjs && pnpm test:integration && pnpm test:release && pnpm tools:test:e2e && pnpm test:electron",
     "verify": "pnpm verify:runtime && pnpm package:built && pnpm test:packaged"
   },