Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Finding and fixing Ghostty's largest memory leak

mitchellh.com

Post reply on HN
Print view View original

31–40 of 152 posts

Re: Finding and fixing Ghostty's largest memory leak

#31

Post by Neywiny »

Edit: I'm getting a lot of down votes for this but nobody is saying why I'm wrong. If you think I'm wrong enough to down vote, please reply why.

I don't understand why that is the preferred fix. I would have solved it other ways:

1. When resizing the page, leave some flag of how it was allocated. This tagging is commonly done as the always 0 bits in size or address fields to save space.

2. Since the pool is a known size of contiguous memory, check if the memory to be freed is within that range

3. Make the size immutable. If you want to realloc, go for it, and have the memory manager handle that boundary for you.

Both of those not only maintain functionality which seems to have been lost with the feature reduction but also are more future proof to any other changes in size.

Re: Finding and fixing Ghostty's largest memory leak

#32

Post by dang »

1a527dd5 wrote: post #29
dang wrote: post #21

Earlier quoted context omitted.

Could you please follow the HN guidelines when posting here? They include " assume good faith. " and " don't cross-examine ". https://news.ycombinator.com/newsguidelines.html

Will do my best :)

Appreciated!

Re: Finding and fixing Ghostty's largest memory leak

#35

Post by mitchellh »

drob518 wrote: post #33

Why not just use a circular buffer for the scroll back? Why use blocks at all if you’re just going to recycle them anyway? That said, great write-up.

It started that way, and that's a common way to do this. One of the reasons is to avoid large pre-allocations OR large copies. A few other notes over on lobsters: https://lobste.rs/s/vlzg2m/finding_fixing_ghostty_s_largest_...

Re: Finding and fixing Ghostty's largest memory leak

#36

Post by woodruffw »

dangoodmanUT wrote: post #34

waiting for someone to say "this wouldn't have happen if you chose rust"

You’ll probably be waiting a long time, since Rust very explicitly doesn’t have “leak safety” as a constructive property. Safe Rust programs are allowed to leak memory, because memory leaks themselves don’t cause safety issues.

There’s even a standard, non-unsafe API for leaking memory[1].

(What Rust does do is make it harder to construct programs that leak memory unintentionally. It’s possible but not guaranteed that a similar leak would be difficult to express idiomatically in Rust.)

[1]: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...

Re: Finding and fixing Ghostty's largest memory leak

#37

Post by hotpotat »

Neywiny wrote: post #31

Edit: I'm getting a lot of down votes for this but nobody is saying why I'm wrong. If you think I'm wrong enough to down vote, please reply why. I don't understand why that is the preferred fix. I would have solved it other ways: 1. When resizing the page, leave some flag of how it was allocated. This tagging is commonly done as the always 0 bits in size or address fields to save space. 2. Since the pool is a known s…

I upvoted you because I would like to know the response to these approaches
Post reply on HN