Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] design for ocaml heap profiler
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Christian Lindig <lindig@c...>
Subject: [Caml-list] design for ocaml heap profiler
To complete OCaml's toolbox I'd like to have a heap profiler that 
tracks allocation of memory. As a first step, I'd like to augment each 
heap-allocated block with the address of the instruction that allocated 
it. Then the GC could write out a trace that shows where all the live 
memory comes from.

My first idea was to change the the block-allocation instructions in 
the bytecode interpreter such that they allocate one additional slot  
to hold the current address' instruction:

	#define Alloc_small_hp(b,n,t)  \

	Use Alloc_small_hp instead of Alloc_small in in interp.c

Only the runtime systems knows about the additional slot and I expected 
the generated code never to touch the new slot. However, it does not 
work, the compiler crashes, and I could not find out why.

A better design would reserve the new slot as part of the header; this 
requires to redefine the macros in mlvalues.h. Has anybody tried to 
enlarge the header? It would be very nice if the header could be 
enlarged by a configurable number n of slots, where n=0 for the 
production runtime system.

I appreciate any advice about how to enlarge heap blocks for run-time 

-- Christian

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: