[Pika-dev] Object data area API, memchunks, object locks

[Andreas Rottmann]

[cc'ing people personally 'cause of ML lag]

I've now implemented "object data areas", as already roughly described
in [0]. For increasing memory efficiency in the future, I've put a
minimal memory chunk interface in hackerlab, which is ATM directly
mapped to lim_{alloc,free}:

   struct mem_chunk;
   typedef struct mem_chunk *t_mem_chunk;

   enum mem_chunk_type
     {
       mem_chunk_alloc_only,
       mem_chunk_alloc_and_free
     };
   typedef enum mem_chunk_type t_mem_chunk_type;

   t_mem_chunk  mem_chunk_new (int atom_size,
                               int area_atoms,
                               t_mem_chunk_type type,
                               alloc_limits limits);
   void         mem_chunk_destroy (t_mem_chunk mem_chunk);
   void *       mem_chunk_alloc   (t_mem_chunk mem_chunk);
   void *       mem_chunk_zalloc  (t_mem_chunk mem_chunk);
   void         mem_chunk_free    (t_mem_chunk mem_chunk, void *mem);


The API is closely modelled after GLib's, and I intend to "port" their
implementation some time in the future, but that's only an
optimization. The code can be found in my archive, revision
hackerlab--devo--1.0--patch-1.

The object data area API is mostly the same as described in [0], with
an additional quirk: there are "normal" and "strong" object data
areas. A "strong" object data area keeps the object alive, and can be
released without knowing which object it belongs to. 

Object locks are implemented as a strong object data area, since (at
least I think so), objects should stay alive as long there exist any
locks (wether held or not) on them. Also, the
scm_release_object_locks() function gets passed only the locks
themselves, not the objects they refer to. With a strong object data
area, there is no need to store the object referred to in the data
area itself.

The object data area API looks like this ATM (as in
pika-scm--object-locks--0.1--patch-2):

   t_uint scm_create_object_data_area (t_scm_arena arena, size_t size);
   void *scm_obtain_object_data_area (t_scm_arena arena,
                                      t_scm_word * obj,
                                      t_uint key,
                                      int strongp);
   void scm_release_object_data_area (t_scm_arena arena,
                                      t_scm_word * obj,
                                      t_uint key);
   void  scm_release_strong_object_data_area (t_scm_arena arena,
                                              void * data_area,
                                              t_uint key);

If you pass a true value for "strongp", you get a strong data
area. You *can* use scm_release_strong_object_data_area() instead of
scm_release_object_data_area() for releasing such data areas.

Note that I have not yet made the GC interact properly with object
data areas, but I'll do so when I tackle the "little hashq problem".

[0] http://mail.nongnu.org/archive/html/pika-dev/2004-03/msg00014.html

Regards, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

The best way to accelerate a Windows machine is at 9.81 m/s^2