[WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re: Loading credentials in verify callback just as needed ?

[B. Scott Michel]

On 8/31/2012 8:51 AM, B. Scott Michel wrote:
> I'd hesitate before writing my own memory manager (essentially what
> you're proposing with memory pools). There's a good chunk of literature
> that demonstrates that customized memory management is inefficient. It's
> also a good indication that there's a different problem that needs to be
> addressed. If you're using Linux, malloc() is already managing pools of
> memory, as is almost every other malloc() implementation since around 1990.
>
> 2 million malloc() calls probably needs to be fixed first. If that can't
> be fixed, look at the algorithm and fix it. But think long and hard
> before writing your own memory manager.
>
>
> -scooter
>

For the academically inclined, Emery Berger's dissertation research is
what you want to go look at:

*OOPSLA 2002: Reconsidering Custom Memory Allocation
<http://www.cs.umass.edu/%7Eemery/pubs/berger-oopsla2002.pdf>
* with Ben Zorn <http://research.microsoft.com/%7Ezorn> & Kathryn
McKinley <http://www.cs.utexas.edu/users/mckinley>
We show that a good general-purpose allocator is better (faster and more
space-efficient) than all styles of custom allocators except regions,
but these have serious problems. We introduce *reaps* (regions + heaps),
which combine the flexibility and space efficiency of heaps with the
performance of regions.
Talk (PowerPoint) <http://www.cs.umass.edu/%7Eemery/talks/OOPSLA-2002.ppt>.

*OOPSLA 2005: Quantifying the Performance of Garbage Collection vs.
Explicit Memory Management
<http://www.cs.umass.edu/%7Eemery/pubs/gcvsmalloc.pdf>
* with Matthew Hertz. <http://www.cs.umass.edu/%7Ehertz>
This paper provides empirical answers to an age-old question: is garbage
collection faster/slower/the same speed as malloc/free? We introduce
oracular memory management, an approach that lets us measure unaltered
Java programs as if they used malloc and free. The result: a good GC can
match the performance of a good allocator, but it takes 5X more space.
If physical memory is tight, however, conventional garbage collectors
suffer an order-of-magnitude performance penalty.
Talk: PowerPoint
<http://www.cs.umass.edu/%7Eemery/presentations/oopsla2005-quantifyinggc.ppt>,
PDF
<http://www.cs.umass.edu/%7Eemery/presentations/oopsla2005-gcvsmalloc.pdf>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120831/207da7d2/attachment.htm>