I have a WearOS watch which is a frustratingly janky piece of crap. Whenever you try to do anything on it, it freezes for several seconds. Why? because it's SWAPPING! what the what?! 1.9G of virtual memory for a daemon on a wristwatch? 21 java apps, each with >760M vmem? JFC
Conversation
Replying to
Right, but it's relying way too hard on the virtual memory mechanism to maintain the working set. The load average spikes >10 if I do something crazy like load the settings menu.
2
1
The issue is definitely not virtual memory usage. You can't really determine much from VIRT. Each mapping uses a small amount of memory, but larger mappings don't consume more resources. The design approach they use is to share tons of potentially used data via memory mappings.
1
In the default optimized spawning model, each app is forked from the Zygote, which preloads all the commonly used Java and native libraries including running their initialization code. It's a startup time and memory use optimization. It uses more actual memory with it disabled.
You did catch the part where the app freezes for several seconds? It doesn't matter what should be etc, the user experience is that it sucks.
1
Whatever is wrong, I don't see a way it could be connected to the virtual memory usage. A lot of that would be from stuff like the Control Flow Integrity shadow mapping which reserves a ton of address space as PROT_NONE to guarantee it has contiguous space for all possible needs.
1
1
Show replies
I would have thought more would show as shared memory in that case. I definitely see processes going into D state in top and load averages spiking way, way up whenever I use the thing but as you say it's hard to know how big the actual working set is.