Nelson B wrote:
[...]. When NSS attempt to allocate more memory from an
arena pool, the PLArenaPool code attempts to use an arena from its
free list, and only gets a new arena from the heap if there are no
arenas in the free list that are large enough to satisfy the request.
[...]
To solve that problem, it is generally necessary to disable the arena free
list, so that arenas are actually freed back to the heap each time they
are freed, and are allocated afresh from the heap each time they are
allocated. This makes NSS slower, [...]
Quite an interesting description.
But I have a problem with it, this doesn't say *why* this is faster than
malloc/free. I'm listing three possible explanations below.
I think it's important to understand it has to be explained by one those
three reasons, and not just : "we're doing it ourself so it's better"
It can be faster only if :
1 - The implementation is simply better than the default one in malloc/free
2 - It knows things about the way NSS allocates memory that allows it to
choose different tradeoffs than a generic malloc/free, tradeoffs that
work better in the case of NSS
3 - It has a different contract than the stock malloc/free
If 1, then NSS should better replace globally new/free with it's own
version. And have a compilation option to allow to use the native
implementation on systems where it's known that the native version is
very optimized and therefore better than NSS version. Not include that
in PLArenaPool where it has nothing to do.
I don't have the feeling it's really 2. If it's really 2, it'd better be
perfectly understood and documented where the strategy differs and what
the limitation are. 2 would mean PLArenaPool is better than new/free in
some usage, but also *slower* in some other case, so there'd better be a
caveat about when that will be the case. And an option to revert to
new/free.
I'm left with 3 as the most probable option, and in fact I'm thinking
about a probable cause in that line.
Is PLArenaPool allocation thread safe ?
If not, then this is probably what explains the better performances (but
maybe not all of it, so it might still be interesting to investigate the
other options).
_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
