This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSOC Student application


On 2008/3/30, Alexey Salmin <alexey.salmin@gmail.com> wrote:
> > 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)
>  {
>   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.
>
>  salmin@salmin:~/gcc/src/libcpp$ grep XNEW * | wc -l
>  66
>  salmin@salmin:~/gcc/src/libcpp$ grep XDELETE * | wc -l
>  6
>  salmin@salmin:~/gcc/src/libcpp$ grep free * | wc -l
>  153
>  salmin@salmin:~/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 :)
>

$ objdump -t libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1 | cut -c48- | \
   grep -i alloc | sort -u

There are aprox. 95 symbols related to *alloc* as by example
malloc, calloc, ealloc, ecalloc, etc.

 It's good idea to deforest some different symbols from this
forest of *alloc* to use common symbols.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]