Re: port-arm/55533: nodejs fails with "out of memory" on aarch64 (with reproducer)

[Michael van Elst <mlelstv%serpens.de@localhost>]

The following reply was made to PR port-arm/55533; it has been noted by GNATS.

From: Michael van Elst <mlelstv%serpens.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-arm/55533: nodejs fails with "out of memory" on aarch64
 (with reproducer)
Date: Sat, 8 Aug 2020 14:08:20 +0200

 The mmap failure is pretty forward.
 
 The memory map is a list of adjacent memory regions, each with a part
 that is allocated (start..end) followed by a part that is free
 (end..end+gap).
 
 mmap() searches the list until it finds a gap that is large enough and
 where the requested alignment can be fullfilled.
 
 When a zero hint is used, the search starts from the beginning of the
 list and everything is fine.
 
 But with a non-zero hint, the search starts with the region that
 includes the given address. This is technically wrong, since the
 beginning of the list is never searched. But if the hint is
 somewhere in the heap, the search will reach the end of the heap
 and find space there.
 
 This also works when we do top down allocation. The search goes
 backwards and the "end" of the heap is its lowest address.
 
 Things go wrong if you use a hint that is not in the heap, e.g.
 a stack address for bottom up allocation, or a program address
 for top down allocation.
 
 To be correct, the search would need to wrap around until it
 reaches the start position to really search the full list.
 
 
 
 In our code we use an additional red-black-tree to locate
 a region for a given address faster than the original
 linear search. The tree even maintains a "max gap" value
 for subtrees, so we could just walk the tree and prune
 subtrees when searching for free space.
 
 But we don't do that. We just search downwards, using
 a simple heuristic. This speeds up the search when
 we need go to the end of the heap, but otherwise may
 miss gaps that are large enough. In that case we fall
 back to the linear search.
 
 Instead of wrapping around the linear search, we could
 also do a complete tree walk. The linear search wouldn't
 be necessary then.
 
 
 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."