[roll] Roll fuchsia [starnix] Encapsulate anonymous memory allocations inside MemoryManager This moves the allocation of the backing object for anonymous memory allocations inside the MemoryManager type to prepare for changing the backing objects. MemoryManager now exposes separate functions for adding a VMO-backed mapping and anonymous mappings. The loader now allocates the stack as anonymous memory and uses the MemoryAccessor trait to fill in the initial stack data. Anonymous memory more closely matches Linux (observable via /proc/../smaps). Using the MemoryAccessor trait is slightly slower than directly writing in to the VMO currently, but is expected to be faster once we can use memory mappings for this. This also moves the POPULATE behavior to the internals of map to encapsulate how the memory is being managed. This also performs the population operation under the MemoryManagerState lock. If needed, we could move this back out of the lock and perform it in MemoryManager at the risk of issuing an op on mappings that another thread has already modified. Original-Bug: b/310255065 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/941196 Original-Revision: eda6d0a8840f018c9422f73d9934e4761f7706a0 GitOrigin-RevId: ca70eb7df510ba5c94b253e6708f14c496f57a34 Change-Id: I76e67dfc8e183e1cd8e2272f959827f085b0acc4
This repository contains Fuchsia's Global Integration manifest files.
All changes should be made to the internal version of this repository. Our infrastructure automatically updates this version when the internal one changes.
Currently all changes must be made by a Google employee. Non-Google employees wishing to make a change can ask for assistance via the IRC channel #fuchsia on Freenode.
First install Jiri.
Next run:
$ jiri init $ jiri import minimal https://fuchsia.googlesource.com/integration $ jiri update
Third party projects should have their own subdirectory in ./third_party.