> There are issues of Garbage Collection from libgcc or Boehms's GC
> that you possibly can't use another allocators that these defaults,
> unless you have control of the manager of the whole memory,
> and it's too complex due to the gigant size of the project.
[EMAIL PROTECTED]:~/gcc/src/include$ grep XNEW libiberty.h
#define XNEW(T) ((T *) xmalloc (sizeof (T)))
#define XNEWVEC(T, N) ((T *) xmalloc (sizeof (T) * (N)))
#define XNEWVAR(T, S) ((T *) xmalloc ((S)))
[EMAIL PROTECTED]:~/gcc/src/libiberty$ grep -A 11 '^xmalloc (' xmalloc.c
xmalloc (size_t size)
{
PTR newmem;
if (size == 0)
size = 1;
newmem = malloc (size);
if (!newmem)
xmalloc_failed (size);
return (newmem);
}
So, you can see that XNEW* macro are now exactly the same as just
malloc function and they were added only for possible future change of
the memory allocator.
Any malloc function should be repalced with this macro AFAIK.
And the worst thing I can see in the code is freeing the memory
allocated with XNEW macro. It works fine now but it's wrong as I
understand.
[EMAIL PROTECTED]:~/gcc/src/libcpp$ grep XNEW * | wc -l
66
[EMAIL PROTECTED]:~/gcc/src/libcpp$ grep XDELETE * | wc -l
6
[EMAIL PROTECTED]:~/gcc/src/libcpp$ grep free * | wc -l
153
[EMAIL PROTECTED]:~/gcc/src/libcpp$ grep malloc * | wc -l
13
> You must know that before optimizing anything, you must profile the
> whole code (-pg, gprof, ...) and study the beautiful formula of
> "Amdahl's Law" for sequential machines in some books.
>
> Studied this law, you can optimize better than your previous knowledge.
I know what profiling is. And I know how parallel programs work,
thanks. I'm just talknig here about distinct improvements I can do,
not about some abstract optimizing.
>
> Luck U.S.S.R. boy ;)
>
Yes, I've been living in USSR for 2 first years of my life :)
