[opensource-dev] Mesh viewers and tcmalloc issues

[Henri Beauchamp]

On Sun, 2 Oct 2011 16:39:49 +0200, Carlo Wood wrote:

> On Sun, 2 Oct 2011 10:20:47 +0200
> Henri Beauchamp <sldev at free.fr> wrote:
> 
> > Really, the only true motivation behind the use of tcmalloc in mesh
> > viewers (it was not use for non-mesh viewers) is to provide aligned
> > allocations. Without it, and the way the mesh viewer code is written,
> > the viewer simply crashes as soon as it tries to perform an SSE2
> > operation on an unaligned structure.
> 
> Use _mm_malloc, if that doesn't exist use posix_memalign
> and if that also doesn't exist, just use malloc.
> That will work (for sse2 alignment).

Insufficient for the current way the mesh viewers code is written:
you also need all classes (and their members) used with SSE2
operations to be aligned, else you get crashes. This means that
the C++ "new" call is also impacted.

If you're not convinced, try by yourself by compiling the mesh viewer
without tcmalloc under Linux or Windows, and admire the segfaults as
soon as it starts rezzing anything.

Also, this is why LL didn't use tcmalloc for MacOS-X builds, since
that OS got natively aligned memory allocations.

> tcmalloc is to get speed from not having to lock
> threads when they allocate memory: they each have
> their own pool. I never saw any evidence that the
> main thread is waiting considerable long times
> (ie > 10 usec) on a lock in malloc because other
> threads are trying to alloc/free memory, so I don't
> see the need for tcmalloc in the viewer. I think
> LL fell in love with it for their server, but the
> decision to use it for the viewer is wrong. 

They introduced tcmalloc use *only* because of the mesh code
(tcmalloc was not in use before the mesh branch appeared),
but I agree that its use in the viewer, beside the memory
alignment issue is an overkill and certainly not necessary.

I'd rather see a simpler memory allocator used than tcmalloc...

Henri.