This is the mail archive of the
mailing list for the GCC project.
Re: GSOC Student application
> 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.
salmin@salmin:~/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)))
salmin@salmin:~/gcc/src/libiberty$ grep -A 11 '^xmalloc (' xmalloc.c
xmalloc (size_t size)
if (size == 0)
size = 1;
newmem = malloc (size);
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
salmin@salmin:~/gcc/src/libcpp$ grep XNEW * | wc -l
salmin@salmin:~/gcc/src/libcpp$ grep XDELETE * | wc -l
salmin@salmin:~/gcc/src/libcpp$ grep free * | wc -l
salmin@salmin:~/gcc/src/libcpp$ grep malloc * | wc -l
> 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 :)