This updates all our page data structures so that the `0` value
(literally `@memset(0)`) means empty. This way, when we initialize a new
page via mmap (OS-guaranteed zeroed), we don't need to write to it, and
don't trigger the kernel to physically map the memory.
From Ghostty 1.3.1, our empty terminal physical memory usage goes from
128 KB to 48 KB (#14130) to 16 KB (this PR). And even with an empty
prompt written on my machine, it holds at 16KB, only increasing to two
pages (32 KB) with 24 rows written.
Here are some measurements.
| Per terminal | Before (macOS) | After (macOS) | Before (Linux) | After
(Linux) |
|-------------------------------------------------------|----------------|---------------|----------------|---------------|
| Page-list memory dirty, fresh | 48 KiB | 16 KiB | 24 KiB | 8 KiB |
| Page-list memory dirty, 24 visible rows written | 64 KiB | 32 KiB | 36
KiB | 20 KiB |
Note macOS uses 16KB pages and Linux generally uses 4 KB pages.
I ran `ghostty-bench +terminal-stream` main vs this branch and with
every normal workload the results are within noise (sometimes faster
sometimes slower).
**AI usage:** It was used as a judge/validator. The actual changes were
me, commit messages and PR messages all me.
This replaces the `std.heap.MemoryPool` used for page buffers with a
custom pool called `UntouchedPool`. This keeps its free list in a side
array and never reads/writes items until `create()`. This means that
demand-driven allocations (like mmaped pages) don't incur physical costs
until they're actually used.
The standard `std.heap.MemoryPool` uses an intrusive linked list for its
items which causes every item to be touched, which forces a full page-in
of memory.
It turns out we also had a lot of assertions and logic to work around
this in various ways (size of rows, asserting we overwrite the free list
entry, etc.) that we can now remove because of this.
For an 80x24 terminal on macOS (16 KB pages):
| Per terminal | Before | After |
|------------------------------|----------|----------|
| Page-list memory dirty | 128 KiB | 48 KiB |
| Process phys_footprint delta | 143 KiB | 62 KiB |
| Page-list virtual size | 2208 KiB | 1600 KiB |
The remaining 48 KB is the active page, because we sprinkle metadata
around the page which forces every page to be paged in. I'm going to
follow this up with some work trying to move all our metadata to the
front of the page so we only page one in until the rest is needed, but
not sure if its achievable.
Micro-benchmarks on the pool show that its twice the speed (slower) to
create/free due to the side list, but in an actual `+terminal-stream`
benchmark churning through pages, there is no measurable difference. I
think its a good trade.
This replaces the `std.heap.MemoryPool` used for page buffers with
a custom pool called `UntouchedPool`. This keeps its free list in a side
array and never reads/writes items until `create()`. This means that
demand-driven allocations (like mmaped pages) don't incur physical costs
until they're actually used.
The standard `std.heap.MemoryPool` uses an intrusive linked list for
its items which causes every item to be touched, which forces a full
page-in of memory.
It turns out we also had a lot of assertions and logic to work around
this in various ways (size of rows, asserting we overwrite the free
list entry, etc.) that we can now remove because of this.
For an 80x24 terminal on macOS (16 KB pages):
| Per terminal | Before | After |
|------------------------------|----------|----------|
| Page-list memory dirty | 128 KiB | 48 KiB |
| Process phys_footprint delta | 143 KiB | 62 KiB |
| Page-list virtual size | 2208 KiB | 1600 KiB |
The remaining 48 KB is the active page, because we sprinkle metadata
around the page which forces every page to be paged in. I'm going to
follow this up with some work trying to move all our metadata to the
front of the page so we only page one in until the rest is needed,
but not sure if its achievable.
Micro-benchmarks on the pool show that its twice the speed (slower) to
create/free due to the side list, but in an actual `+terminal-stream`
benchmark churning through pages, there is no measurable difference. I
think its a good trade.
This fixes a regression of 9a6469743 introduced in 6e8ed4e8b.
With this fix the mouse pointer will be restored to the previous (which
could have be set to something else via OSC22), not a hardcoded .text or
.default.
It also will change the cursor to a text selection if shift is held even
without mouse tracking, I think this is the expected behavior when a
cursor is set via OSC22. (Kitty additionaly, once you start selecting
changes to text (I-beam), this would be a follow-up if we desire to
behave like kitty with OSC22 pointers).
keyToMouseShape was initially designed with more of a transition table
model in mind to handle key presses/overrides based on very specific
cursor states. This never materialized, so I think it's safe to just
simply the process of handling overrides and/or passing along the
current cursor state from the terminal in the event of key presses.
Also removed a test that is essentially a duplicate of one before it now
(returning current surface shape in the event of no overrides).
I think this is the expected behavoir when a custom OSC22 pointer is set. Once
shift is released it will return to mouse_shape (whatever the pointer
was before shit held).
Fixes the runaway-thread bug reported in #14100 (vouched there).
`openThread` drains the spawned opener's stderr with
`takeDelimiterExclusive('\n')`. That function tosses only the exclusive
length, so the `'\n'` is never consumed. Once the child writes one line
to stderr, every subsequent call returns an empty slice without
advancing the stream: the `while (true)` loop spins forever — one pinned
core per affected `open()`, logging empty `os-open: open stderr=`
warnings at tens of thousands of messages per second for the lifetime of
the process — and `exe.wait()` is never reached, so the child is never
reaped.
This change reads inclusively (`takeDelimiterInclusive`, which does
consume the delimiter) and trims the `'\n'` for logging.
Observed in the wild embedding libghostty on macOS: several days of
uptime accumulated six leaked opener threads at ~70% of a core each
(~4.4 cores), from six link clicks whose `/usr/bin/open` wrote to
stderr. After the fix, the same workload shows zero `os-open` log
traffic and no leaked threads.
Repro without the fix: open a link whose handler writes to stderr (e.g.
an OSC 8 link with an unknown scheme), then watch a core pin and `log
stream --predicate 'subsystem == "com.mitchellh.ghostty"'` flood.
**AI disclosure** (per `AI_POLICY.md`): the bug was diagnosed and this
patch drafted with Claude Code (thread sampling, log analysis, and
reading the Zig 0.16 `std.Io.Reader` source to confirm
`takeDelimiterExclusive`/`takeDelimiterInclusive` toss semantics). I
reviewed the analysis and the change, understand both, and verified the
fix in a production build of the embedding app.
takeDelimiterExclusive never consumes the delimiter: it tosses only the
exclusive length, so the '\n' stays buffered. Once the spawned opener
writes a single line to stderr, every subsequent call returns an empty
slice without advancing the stream, and openThread's loop spins forever
- one pinned core per affected open(), logging empty
"open stderr=" warnings at tens of thousands of messages per second for
the lifetime of the process. The thread also never reaches exe.wait(),
so the child is never reaped.
Read inclusively instead (which does consume the delimiter) and trim
the '\n' for logging.
Repro: open a link whose handler writes to stderr, e.g. an OSC 8 link
with an unknown scheme; watch a core disappear and the unified log
flood with "os-open: open stderr=".
See discussion #14100.
A search that had already exhausted a screen's PageList never picked up
history pages prepended afterwards by incremental snapshot restore.
The lower level PageListSearch and so on could already handle this, we
just needed to let it know that more history existed to search. This
fixes that.
A search that had already exhausted a screen's PageList never picked up
history pages prepended afterwards by incremental snapshot restore.
The lower level PageListSearch and so on could already handle this, we
just needed to let it know that more history existed to search. This
fixes that.
Bumps
[flatpak/flatpak-github-actions/flatpak-builder](https://github.com/flatpak/flatpak-github-actions)
from 6.7 to 6.8.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/flatpak/flatpak-github-actions/releases">flatpak/flatpak-github-actions/flatpak-builder's
releases</a>.</em></p>
<blockquote>
<h2>v6.8</h2>
<ul>
<li>Add saveCache flag</li>
<li>Add ability to override artifact name</li>
<li>Add buildDebugBundle flag</li>
<li>Update tests, documentation and dependencies</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="7932741660"><code>7932741</code></a>
Update all dependencies and regenerate dist</li>
<li><a
href="09e3d61868"><code>09e3d61</code></a>
readme: Don't specify setting cache key to github.sha (<a
href="https://redirect.github.com/flatpak/flatpak-github-actions/issues/261">#261</a>)</li>
<li><a
href="23e622281a"><code>23e6222</code></a>
Update runtime versions and docker images to latest</li>
<li><a
href="a3ab43f581"><code>a3ab43f</code></a>
flatpak-builder: Add saveCache flag</li>
<li><a
href="8e357b1556"><code>8e357b1</code></a>
ci: Remove unnecessary 'needs' from debug bundle job</li>
<li><a
href="26e19caa3a"><code>26e19ca</code></a>
ci: Add test for artifact-name</li>
<li><a
href="06d246b4d5"><code>06d246b</code></a>
flatpak-builder: Add ability to override artifact name</li>
<li><a
href="a262264771"><code>a262264</code></a>
ci: Add job that uses build-debug-bundle</li>
<li><a
href="f7362292df"><code>f736229</code></a>
flatpak-builder: Add buildDebugBundle flag</li>
<li><a
href="3b10954431"><code>3b10954</code></a>
ci: Update actions to versions using Node 24</li>
<li>See full diff in <a
href="401fe28a83...7932741660">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Bumps [cachix/cachix-action](https://github.com/cachix/cachix-action)
from 5f2d7c5294214f71b873db4b969586b980625e71 to
38b082610b782e7e93e209c35fd730d399dee866.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/cachix/cachix-action/blob/master/RELEASE.md">cachix/cachix-action's
changelog</a>.</em></p>
<blockquote>
<h1>Release</h1>
<ol>
<li>
<p>Create and push a new tag:</p>
<pre lang="console"><code>git tag v17
git push origin v17
</code></pre>
</li>
<li>
<p>Wait for CI to pass.</p>
</li>
<li>
<p><a href="https://github.com/cachix/cachix-action/releases/new">Create
a release</a> for the new tag.</p>
</li>
<li>
<p>Move the major version tag to the latest release:</p>
<pre lang="console"><code>git tag -fa v17
git push origin v17 --force
</code></pre>
</li>
</ol>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="38b082610b"><code>38b0826</code></a>
dev: cleanup tests and dev files</li>
<li><a
href="0fe030c286"><code>0fe030c</code></a>
dist</li>
<li><a
href="792dafcfd0"><code>792dafc</code></a>
deps: bump dependencies</li>
<li><a
href="b690244fb5"><code>b690244</code></a>
ci: improve Nix compatibility test coverage</li>
<li><a
href="f495f3ffa2"><code>f495f3f</code></a>
Merge pull request <a
href="https://redirect.github.com/cachix/cachix-action/issues/217">#217</a>
from cachix/dependabot/github_actions/actions/checkout-7</li>
<li><a
href="9ee3c77d45"><code>9ee3c77</code></a>
chore(deps): bump actions/checkout from 6 to 7</li>
<li>See full diff in <a
href="5f2d7c5294...38b082610b">compare
view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Found another regression when investigating #14107 after the last fix.
This regression appears on macOS 15 and 26 as well: **New window by
Shortcuts.app or service menu while a window is visible would create a
tab**.
It appears that for `new-window` triggered by Shortcuts/Service, a small
delay is needed to avoid automatic tabbing. It's either removing
`NSWindow.userTabbingPreference == .always` completely or adding another
"delay" for cascading. The latter should be better.
Also fixes another cascading for `macos-titlebar-style = hidden`
previously missed.
https://github.com/rcaloras/bash-preexec/releases/tag/0.7.0
We only source bash-preexec for bash < 4.4, so most of this release is
inert for us: the PS0 function-substitution hook (bash >= 5.3) and the
array PROMPT_COMMAND handling (bash >= 5.1) are never reached. What we
do pick up is the simpler install string, per-prompt re-adjustment of
PROMPT_COMMAND when something else modifies it, preservation of $? and
$_ on early returns, and the first-command preexec fix.
We continue to carry one local modification: __bp_adjust_histcontrol
stays disabled in the DEBUG trap hook so the user's HISTCONTROL is
respected (#2269). The original justification was that we didn't use the
preexec command argument, which is no longer true because we use it for
the window title. The comment now explains the current reasoning: our
bash >= 4.4 integration also uses `history 1` without adjusting
HISTCONTROL and accepts the same inaccuracy for space-prefixed commands,
so the legacy path is kept consistent with it.
*AI Usage:* I asked Fable 5.1 to run a verification pass after my manual
upgrade, and it confirmed the expected behavior.
https://github.com/rcaloras/bash-preexec/releases/tag/0.7.0
We only source bash-preexec for bash < 4.4, so most of this release is
inert for us: the PS0 function-substitution hook (bash >= 5.3) and the
array PROMPT_COMMAND handling (bash >= 5.1) are never reached. What we
do pick up is the simpler install string, per-prompt re-adjustment of
PROMPT_COMMAND when something else modifies it, preservation of $? and
$_ on early returns, and the first-command preexec fix.
We continue to carry one local modification: __bp_adjust_histcontrol
stays disabled in the DEBUG trap hook so the user's HISTCONTROL is
respected (#2269). The original justification was that we didn't use
the preexec command argument, which is no longer true because we use it
for the window title. The comment now explains the current reasoning:
our bash >= 4.4 integration also uses `history 1` without adjusting
HISTCONTROL and accepts the same inaccuracy for space-prefixed commands,
so the legacy path is kept consistent with it.
