Evaluate jitter LRU cache for memshrink
Categories
(Core :: General, enhancement)
Tracking
()
People
(Reporter: tjr, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [overhead:4k])
We have an LRU cache here: https://searchfox.org/mozilla-central/rev/31d8600b73dc85b4cdbabf45ac3f1a9c11700d8e/toolkit/components/resistfingerprinting/nsRFPService.cpp#104 with 45 entries with that number being chosen based on little testing.
The cache stores SHA-256 results to avoid repeated hashing, and the cache is used for our timestamp jittering, so we potentially cause a hash on every DOM timestamp-related thing.
Each cache entry is:
Atomic<long long, Relaxed> keyPart1;
Atomic<long long, Relaxed> keyPart2;
PRTime accessTime = 0;
nsCString data;
I'm not sure what the overhead is, but that's at least 8 + 8 + 8 + 32 (string contents) + string overhead + atomic overhead * 45 = 2520 bytes (plus the overhead.)
The cache could be made smaller if we figured out what a good cache size was. Now that there's only one origin per process, it surely doesn't need to be quite that large. I don't know if saying 1 KB or so meets the goals of memshrink but I figured I'd file and let you evaluate.
|
||
Comment 1•5 years ago
|
||
(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #0)
I'm not sure what the overhead is, but that's at least 8 + 8 + 8 + 32 (string contents) + string overhead + atomic overhead * 45 = 2520 bytes (plus the overhead.)
I make this 8 + 8 + 8 + 16 (sizeof nsCString) + 48 (string storage: HASH_DIGEST_SIZE_BYTES (256 / 8 = 32) + 1 for null terminator + 15 for malloc bucket quantization) * 45 = 3,960 + other overhead.
Though I'll note that replacing the nsCString data with a char[HASH_DIGEST_SIZE_BYTES] would get rid of the 16 bytes of nsCString overhead, the null terminator, and the malloc overhead for the string storage.
Description
•