This mechanism wasn't actually used to create any WeakPtr<Process>.
Such pointers would be pretty hard to work with anyway, due to the
multi-step destruction ritual of Process.
A 16-bit refcount is just begging for trouble right nowl.
A 32-bit refcount will be begging for trouble later down the line,
so we'll have to revisit this eventually. :^)
When size_t replaced int (6f4c370), it caused the 'start = -1' trick to
fail, setting start to (unsigned)-1 instead. This then caused
String.substring to fail, as that is a little bit higher than the length
of the string! This resulted in an outright crash.
Later, the builder is not reset before making a new line. This causes
the line to simply be the earlier one, but with more text on it.
(There's also a few changes from clang-format, namely the #include
reorganization.)
Fixes#1211 (although I wasn't aware of it when I made this commit).
Weakable objects ended up with differing memory layouts in some ports
since they don't build with the DEBUG macro defined.
Instead of forcing ports to define DEBUG, just put this behind a custom
WEAKABLE_DEBUG macro and leave it always-on for now.
This patch adds a globally shared zero-filled PhysicalPage that will
be mapped into every slot of every zero-filled AnonymousVMObject until
that page is written to, achieving CoW-like zero-filled pages.
Initial testing show that this doesn't actually achieve any sharing yet
but it seems like a good design regardless, since it may reduce the
number of page faults taken by programs.
If you look at the refcount of MM.shared_zero_page() it will have quite
a high refcount, but that's just because everything maps it everywhere.
If you want to see the "real" refcount, you can build with the
MAP_SHARED_ZERO_PAGE_LAZILY flag, and we'll defer mapping of the shared
zero page until the first NP read fault.
I've left this behavior behind a flag for future testing of this code.
This shaves ~5 seconds off of a full build, not too bad. Also it just
seems nicer to push this logic out to classes. It could be better but
it's a start. :^)
Compiling anything that includes generated IPC messages is painfully
slow at the moment. This moves the encoding helpers out of line, which
helps a bit. Doing the same for decoding will help more.
