1

I am breaking my head in understanding the BoehmGC allocation scheme - GC_malloc. I am not getting how it allocates memory, not seen any malloc or mmap which GC_malloc internally calls.

Can someone kindly help me? Any links or code snippet will be of big help.

Huge thanks in advance. Boehm GC source code

 enter code here
 254 /* Allocate lb bytes of composite (pointerful) data */
 255 #ifdef THREAD_LOCAL_ALLOC
 256   void * GC_core_malloc(size_t lb)
 257 #else
 258   void * GC_malloc(size_t lb)
 259 #endif
 260 {
 261     void *op;
 262     void **opp;
 263     size_t lg;
 264     DCL_LOCK_STATE;
 265 
 266     if(SMALL_OBJ(lb)) {
 267         lg = GC_size_map[lb];
 268         opp = (void **)&(GC_objfreelist[lg]);
 269         LOCK();
 270         if( EXPECT((op = *opp) == 0, 0) ) {
 271             UNLOCK();
 272             return(GENERAL_MALLOC((word)lb, NORMAL));
 273         }
 274         /* See above comment on signals.        */
 275         GC_ASSERT(0 == obj_link(op)
 276                   || (word)obj_link(op)
 277                         <= (word)GC_greatest_plausible_heap_addr
 278                      && (word)obj_link(op)
 279                         >= (word)GC_least_plausible_heap_addr);
 280         *opp = obj_link(op);
 281         obj_link(op) = 0;
 282         GC_bytes_allocd += GRANULES_TO_BYTES(lg);
 283         UNLOCK();
 284         return op;
 285    } else {
 286        return(GENERAL_MALLOC(lb, NORMAL));
 287    }
 288 }
RajSanpui
  • 11,556
  • 32
  • 79
  • 146
  • What does `GENERAL_MALLOC` expand to? Can you run this through the preprocessor and look again? – Kerrek SB Sep 07 '11 at 10:48
  • @Kerrek SB: Using -dM option in GCC? – RajSanpui Sep 07 '11 at 10:53
  • In GCC you can use `-E` to see the preprocessor output: `gcc -E myfile.c | less` -- you'll get a ton of output, look near the end. – Kerrek SB Sep 07 '11 at 10:55
  • Our target, does not have support for -E let me check it in cross-compiler. – RajSanpui Sep 07 '11 at 11:09
  • @Kerrek SB: It is expanding to GC_debug_malloc(4, "prog2.c", 9); Thanks, let me try to trace that. – RajSanpui Sep 07 '11 at 11:18
  • @Kerrek SB: I used GC_malloc, and that's getting expanded to GC_debug_malloc which internally calls GC_malloc again. But what is GENERAL_MALLOC that is not shown in macro expansion. – RajSanpui Sep 07 '11 at 11:31
  • It has to come from somewhere... you could search through the entire source to see where it's defined. – Kerrek SB Sep 07 '11 at 11:32
  • I grepped, i am astonished to see that it exists nowhere. Here is my grep result. You can refer to source code i have given avove (link of Boehm GC) – RajSanpui Sep 07 '11 at 11:33
  • @Kerrek SB: gc-7.1]$ grep -R "GENERAL_MALLOC" . ./gcj_mlc.c:#define GENERAL_MALLOC(lb,k) \ ./gcj_mlc.c:#define GENERAL_MALLOC_IOP(lb,k) \ ./gcj_mlc.c: op = (ptr_t)GENERAL_MALLOC((word)lb, GC_gcj_kind); ./gcj_mlc.c: op = (ptr_t)GENERAL_MALLOC((word)lb, GC_gcj_kind); ./gcj_mlc.c: op = (ptr_t)GENERAL_MALLOC_IOP(lb, GC_gcj_kind); ./gcj_mlc.c: op = (ptr_t)GENERAL_MALLOC_IOP(lb, GC_gcj_kind); ./malloc.c:#define GENERAL_MALLOC(lb,k) \ ./malloc.c: return(GENERAL_MALLOC((word)lb, PTRFREE)); – RajSanpui Sep 07 '11 at 11:35
  • @Kerrek SB: This is the only thing i see: 106 #define GENERAL_MALLOC(lb,k) \ 107 GC_clear_stack(GC_generic_malloc_inner((word)lb, k)) – RajSanpui Sep 07 '11 at 11:36
  • @Kerrek SB: Here is the source link. http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/ – RajSanpui Sep 07 '11 at 11:38
  • @Kerrek SB: Please help me if you can :( – RajSanpui Sep 07 '11 at 11:41
  • What do you mean "exists nowhere", you just pointed out where it's defined! So just look at that... (it's a multiline definition, so grep swallows the most part of it). – Kerrek SB Sep 07 '11 at 11:42
  • @Kerrek SB: Surprisingly it only exists in gcj_mlc.c which corresponds if we use java (gcj compiler) not anything with gcc – RajSanpui Sep 07 '11 at 11:45
  • Wait wait, you just said that there's a hit in `malloc.c` -- why not start with that? – Kerrek SB Sep 07 '11 at 11:48
  • @Kerrek SB: 200 #define GENERAL_MALLOC(lb,k) \ 201 GC_clear_stack(GC_generic_malloc(lb, k)) 202 /* We make the GC_clear_stack_call a tail call, hoping to get more of */ 203 /* the stack. – RajSanpui Sep 07 '11 at 11:48
  • @Kerrek SB: Sorry for the trouble, and thanks a lot. LEt me know if you come to know about the allocator (something in addition) meanwhile i am also searching. Infinite thanks :) – RajSanpui Sep 07 '11 at 11:49
  • Hm, I don't know, they may be doing some preprocessor black magic, maybe they're redefining the macro somewhere on the way... I've never seen that source and have no idea, but I'm sure you can trace it out with a cup of coffee and patience :-) – Kerrek SB Sep 07 '11 at 11:54
  • @Kerrek SB: Thanks for the optimism, I will have to make it somehow :) – RajSanpui Sep 07 '11 at 12:01
  • I hope you have read http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html There is an explanation on how it works. – xanatos Sep 07 '11 at 12:19
  • @xantos: Yes, i have seen it. Does not mention about the call sequence :( – RajSanpui Sep 07 '11 at 13:07

2 Answers2

0

There are two possibilities:

  • It returns a pointer given by GENERAL_MALLOC (two returns)
  • it sets op = *opp (the line with the EXPECT) and then it returns op. I'll say that the second is to reuse freed blocks.

For the second case: look at the value of opp before the if:

opp = (void **)&(GC_objfreelist[lg]);

In opp there is a pointer to the "free" list of objects.

The if probably checks if there is any block in that list. If there isn't (== 0) then it uses GENERAL_MALLOC.

xanatos
  • 109,618
  • 12
  • 197
  • 280
0

Look at the os_deps.c file where (most) of the OS-dependent functions are implemented.

mmap can be used by Boehm-GC if it's configured to use that. (See the various GC_unix_get_mem(bytes) functions.)

If mmap isn't used, the other (bare) allocator used sbrk.

Mat
  • 202,337
  • 40
  • 393
  • 406
  • Ahh thanks, that was more close than other replies. Let me check it. – RajSanpui Sep 07 '11 at 10:54
  • Yes, mmap is used there, but i can't see where GC_malloc is calling that. – RajSanpui Sep 07 '11 at 10:57
  • result = mmap(last_addr, bytes, PROT_READ | PROT_WRITE | OPT_PROT_EXEC, GC_MMAP_FLAGS | OPT_MAP_ANON, zero_fd, 0/* offset */); – RajSanpui Sep 07 '11 at 10:58
  • The complete call chain is probably pretty tricky, especially with how macros are used in the middle, and the various caches. You'll need to study that code (and/or the related research material on Boehm-GC's homepage) if you want to understand it completely. – Mat Sep 07 '11 at 10:58
  • ok..yes. In between if you can get to know something (in your time) about this call chain, it will be of BIG-BIG-BIG help to me :) – RajSanpui Sep 07 '11 at 11:02
  • Do your research. It will (most likely) never be a direct call to the allocator given the structure of Boehm-GC, which you should study first if you want to understand the code. It's far from trivial. – Mat Sep 07 '11 at 11:04
  • Yes, true. Don't understand why people try to make it so tricky :( – RajSanpui Sep 07 '11 at 11:05