> The reason behind it is the hardened memory allocator, which seems to create a significant overhead for Osmand. That might be because scrolling a map requires constant loading and discarding of data.
... is this really the right hunch, over e.g. the OpenStreetMaps app lacking in discipline with its heap allocations?
OsmAnd has a large legacy C++ codebase with a lot of memory corruption bugs. Many memory corruption bugs have been found and reported by GrapheneOS users. It isn't yet clear if the performance issues the OpenGL renderer has with hardened_malloc are caused by it making too many allocations or actual bugs.
The hardened_malloc configuration used by GrapheneOS is very security-oriented including using a quarantine for freed slab allocations and it could provide a toggle to use a more performance-oriented configuration for an app instead of only being able to use the default allocator instead.
OsmAnd's map engine is mostly native C++. The hardened allocator wraps malloc for that native heap, where decoded tile geometry and texture buffers live during scroll. The Java side still uses ART's GC, so you get a split: the UI can feel fine while the native render path pays the hardened-allocator tax on every tile churn. That also matches why a Leaflet WebView (one heap model) can feel different from the same map data inside OsmAnd.
The hardened allocator doesn't wrap malloc but rather is the default malloc implementation on GrapheneOS with a per-app opt-out toggle. It makes no substantial difference for overall OS performance but there are definitely apps where it matters. OsmAnd works fine for most users without disabling it though.
It's very likely caused by a set of bugs in the app rather than simply inefficient patterns. Users regularly report hardened_malloc detecting memory corruption bugs in OsmAnd.
perching_aix · · focus · HN ↗
> The reason behind it is the hardened memory allocator, which seems to create a significant overhead for Osmand. That might be because scrolling a map requires constant loading and discarding of data.
... is this really the right hunch, over e.g. the OpenStreetMaps app lacking in discipline with its heap allocations?
himata4113 · · focus · HN ↗
RedComet · · focus · HN ↗
grapheneos · · focus · HN ↗
The hardened_malloc configuration used by GrapheneOS is very security-oriented including using a quarantine for freed slab allocations and it could provide a toggle to use a more performance-oriented configuration for an app instead of only being able to use the default allocator instead.
someonebaggy · · focus · HN ↗
cnrcode · · focus · HN ↗
grapheneos · · focus · HN ↗
grapheneos · · focus · HN ↗