Jean-Marc Desperrier wrote:
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
malloc/free is a major bottleneck in multithreaded programs
because the contention for the locks that protect the heap
is very high. By reducing the calls to malloc/free, PLArenaPool
reduces the contention for the heap locks and so can potentially
speed up the code.
PLArenaPool is also used in NSS for its convenience. You allocate
chunks of memory from an arena pool. When you are done, you can
free them all with a single function call.
Each PLArenaPool is not protected by a lock and is originally
intended to be used by a single thread. The PLArenaPool used
in NSS is actually PORTArenaPool, which consists of a PLArenaPool
and a lock. See how PORT_NewArena creates a PORTArenaPool and
returns it as a PLArenaPool:
http://lxr.mozilla.org/security/ident?i=PORT_NewArena
So, the PLArenaPool created by PORT_NewArena is thread-safe.
This typecast unfortunately is not obvious to new NSS developers
and has been the source of a couple of bugs.
Wan-Teh
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
