English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2004-02-23 (10:00)
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 caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners