Hello, Nelson.
Thank you again for detailed description. This is a valuable piece of
information.
Best regards,
--
Konstantin Andreev, software engineer.
Swemel JSC
On Fri, 18 Dec 2009, Nelson B Bolyard wrote:
On 2009-12-17 13:39 PST, Konstantin Andreev wrote:
On Tue, 17 Dec 2009, Nelson B Bolyard wrote:
The use of arena pool marks is merely necessary to ensure proper cleanup in the
rare case where the first of those two allocations succeeds but the second
fails.
Hmm... interesting. Do I understand right, "arena marks" are like transaction
boundaries for memory allocations ? May I consider the equivalence:
PORT_ArenaMark ~~ begin transaction
PORT_ArenaUnmark ~~ commit transaction
PORT_ArenaRelease ~~ rollback transaction
That's a reasonable first approximation, yes.
ArenaPools are like heaps. The memory in them is allocated in large blocks called arenas. Inside the
ArenaPool, the arenas are organized as if they were in a stack. New allocations may be viewed as additional
arenas "pushed" on that stack. The ArenaMark function returns the address of a marker in the stack
of arenas. It is the address where the next arena would be pushed onto the arena stack. ArenaUnmark merely
discards the ArenaMark. ArenaRelease "pops" the stack, removing all the arenas from the stack that
were allocated after the mark was created. It is the only operation, other than destroying the arenapool,
that reduces the size of the stack. Otherwise, the stack just grows until the arenapool is destroyed, at
which point all the arenas are freed or returned to a "free arena list", depending on their sizes.
Each ArenaPool has its own separate stack, and hence marks are only relevant to
the ArenaPool from which they are gotten.
Marks may be nested. That is, you can get a mark, and then get another mark.
it is also possible that multiple threads might acquire marks in the same
ArenaPool if that pool is used as memory for some shared object. You cannot
release a mark if another thread has acquired a mark in the same ArenaPool
since you acquired that mark. When there is a nested mark belonging to another
thread, your attempt to release is treated like an unmark instead. That's why
it's important to explicitly unmark. Your mark may be nested. Every mark
should be followed by either an unmark or a release.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
