User Extensions

The extension package system allows the language compiled by Bigloo to be extended and this is achieved by associating an extension file with a suffix. The extension file is loaded at the beginning of a compilation and it can do three things: call extern programs (unix programs); define macros; modify the values of some of the compiler's variables (for example, the list of the libraries to be linked with). The Bigloo's initializing procedure is the following:

For now, two extension packages exist: the Meroon package which is a native version of the Christian Queinnec object language; the Camloo [SerranoWeis94] package which is a front end compiler for the Caml language [Caml-light]

Furthermore, Bigloo supports the -extend option which forces the usage of an extension file. When Bigloo encounters this option, it immediately loads the extension file, invoking the function *extend-entry* with the list of arguments which have not been parsed yet.

The extension files are always sought in the directory containing the Bigloo's libraries.

User pass

Bigloo allows the user to add a special pass to the regular compilation, this pass taking place before macro expansion. There are two ways to add a user pass.

Memory Profiling

The Bigloo Memory Profiler reports information about the garbage collector activity and the number of allocations. The memory profiler is only available to the C backend.

For programs to be profiled, they must be compiled and linked with the -pmem Bigloo option. It disables some optimizations (such as function inlining) and it forces the C compilation with the -g flags.

Memory profiling uses the Unix LD_PRELOAD facility to override the definition of the standard Bigloo library. As such, it requires programs to be linked against dynamic libraries. Note that the Bigloo -Obench option forces the compiler to link against static libraries and it is then incompatible with the -pmem command line option.

The memory profiler is named bglmemrun. It is use as:

$ bigloo -O3 -unsafe -pmem maze.scm
$ bglmemrun ./a.out
When the execution completes, it produces a report such as:

gc   1: alloc size=2.49MB, heap size=4.12MB, live size=3.95MB
gc   2: alloc size=2.59MB, heap size=7.34MB, live size=2.34MB
...
gc  68: alloc size=8.10MB, heap size=13.05MB, live size=4.71MB
gc  69: alloc size=5.16MB, heap size=13.05MB, live size=0.14MB


===================================================
allocation size: 463.95MB
gc count: 69

lib/init.c:
      565:     0.05MB  0.01% [      64] (vector, keyword, input-port, output-port, string, mutex)
objs/obj_u/Ieee/port.c:
     3835:     0.81MB  0.17% [     300] (string, mutex, output-port)
objs/obj_u/Ieee/vector.c:
      936:    39.24MB  8.46% [     109] (vector)
/home/serrano/trashcan/TBR/maze.c:
      417:   196.19MB 42.29% [ 5143100] (vector)
     2248:   120.16MB 25.90% [ 1750000] (procedure)
      454:    93.46MB 20.14% [ 1750000] (vector)
      565:    13.35MB  2.88% [     100] (vector)
      881:     0.31MB  0.07% [   20103] (pair)
     2519:     0.12MB  0.03% [    8020] (pair)
      958:     0.11MB  0.02% [    3500] (vector)
      677:     0.09MB  0.02% [    6020] (pair)

---------------------------------------------------
allocation count: 140737358159915
   vector              :   342.41MB 73.80% [ 6897370]
   procedure           :   120.17MB 25.90% [ 1750100]
The first column is the line location of the C generated files. To get the locations associated with the original Scheme source file, use the additional Bigloo command line options -glines.

Example:

$ bigloo -O3 -unsafe -pmem maze.scm -glines
$ bglmemrun ./a.out
...
===================================================
allocation size: 463.95MB
gc count: 69

lib/init.c:
      565:     0.05MB  0.01% [      64] (vector, keyword, input-port, output-port, string, mutex)
objs/obj_u/Ieee/port.c:
     3835:     0.81MB  0.17% [     300] (string, mutex, output-port)
/home/serrano/trashcan/TBR/maze.scm:
      182:   196.19MB 42.29% [ 5143100] (vector)
      620:   120.16MB 25.90% [ 1750000] (procedure)
      187:    93.46MB 20.14% [ 1750000] (vector)
      260:    13.35MB  2.88% [     100] (vector)
      318:     0.31MB  0.07% [   20103] (pair)
      763:     0.13MB  0.03% [    8534] (pair)
      373:     0.11MB  0.02% [    3500] (vector)
      307:     0.08MB  0.02% [    5505] (pair)
objs/obj_u/Ieee/vector.c:
      936:    39.24MB  8.46% [     109] (vector)

---------------------------------------------------
allocation count: 140737358037043
   vector              :   342.41MB 73.80% [ 6897370]
   procedure           :   120.17MB 25.90% [ 1750100]