#15804: WebKit: crash in incrementPageOccupancy
---------------------------------------+----------------------------
Reporter: X512 | Owner: pulkomandy
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Applications/WebPositive | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Platform: All |
---------------------------------------+----------------------------
Comment (by mmlr):
The commit chain from https://review.haiku-os.org/c/haiku/+/2590 downwards
implements cache resizing for the remaining cut_area cases. It is based
off the original patch in #8466 and then actually implements the swap
handling for the middle cut / cache split case. Combined with the
overcommit for PROT_NONE change in hrev54120 this should make this work
perfectly.
The strategy to implement should then indeed be the one I outlined in
comment:19 above. Initial reservation happens with a large PROT_NONE mmap
resulting in unreserved overcommitting address range blockage. Individual
commits would then mmap usable, non-overcommitting reserved but not page
mapped memory, only producing as much page pressure as needed. And finally
decommits would cut PROT_NONE, so again unreserved overcommitting, holes
into the committed areas that would now actually release the pages
inbetween.
The distinctions here are:
* Overcommitting: Memory (of any kind, including swap) is not reserved up
front. This means you can always reserve the address space, even if you
reserve 100GB but only have a combined RAM + swap of < 100GB.
* Non-Overcommitting: All allocations need to be backed by some kind of
memory, so you can only ever allocate as much as your total RAM + swap -
anything already reserved allows you. This seems inconvenient, but it
guarantees that you can later actually allocate all of the reservation
that you made and won't run into B_NO_MEMORY.
* Mapped / page backed: The address range is actually backed by RAM pages
and not swapped out. You usually start out with memory reserved, but not
actually backed by RAM until you access a page, when the resulting page
fault maps a page of RAM, possibly pushing something else out of the way
to swap.
So what you want is the pure address space reservation (and later the
holes done by decommit) to be unmapped and overcommitting, which is now
done by PROT_NONE. And anything else you want to be lazily backed by pages
so that you only push stuff out of RAM when really needed.
Note that for decommit to actually be able to free pages and reduce memory
reservations with the holes it punches into existing allocations, it needs
the cut_area changes (or to always overlap previously committed ranges
fully, so that it will delete the underlying areas and caches).
--
Ticket URL: <https://dev.haiku-os.org/ticket/15804#comment:24>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
