caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Damien Doligez <damien.doligez@inria.fr>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Gripes with array
Date: 11 Sep 2004 13:16:00 +1000	[thread overview]
Message-ID: <1094872560.23076.176.camel@pelican.wigram> (raw)
In-Reply-To: <1094866987.23076.132.camel@pelican.wigram>

On Sat, 2004-09-11 at 11:43, skaller wrote:
> On Fri, 2004-09-10 at 23:45, Damien Doligez wrote:
> 
> >  An intermediate solution would
> > be to make a "Array.unsafe_make" primitive, which would use memset 
> > instead of initialising the array properly.  

> 
> AFAICS tracking how much of an array is initialised
> with an index the GC can use costs a single
> comparison when you're not initialising arrays.

Specifically: I assume there is some GC 'object'
containing the state data for the collector.

Suppose we add a doubly linked list
of the type

struct pia { 
  pia *next; 
  pia *prev; 
  caml_heap_block *block; 
  unsigned long index; 
} *pial;

to the GC state data. pial means
'pointer to initialising array list'

In order to sweep a block *p for pointers,
you'd need to do this:

if (pial == NULL) usual_scan(p)
else {
  unsigned long index = find_index(pias,p);
  if (index) scan_array(p,index));
  else usual_scan(p);
} 

usual_scan() is the usual scanning algorithm
for a heap block, array_scan is a special
one where the initialised block length is
tracked. The index is incremented when filling
in the array. If the fill is using a fixed value,
every 4K elements, if a function, each element.

All the scan calls are tail recurisve.
I imagine usual_scan and array_scan would
be the different entry points to the same
routine. Clearly the array initialiser
has to be able to add and remove a the pia descriptor
from the list. In addition, the compactor would
need to adjust the heap pointers in the list.

So in the case we're not currently initialising
an array, we require one memory fetch, a load
of the value 'pial'.

Perhaps 'pial' would reside in the cache,
even if it does it is displacing one other value.
So there is a definite cost for all code with
this technique.

BTW: the Felix collector has an array index count
in every heap header block. The actual block
size is independent of this count. As I understand
it the block size indicator in Ocaml is *also* used
to determine string and array sizes which prevents
it being adjusted dynamically during initialisation?

This would be in case there is an exception thrown 
and the array become prematurely unreachable,
since otherwise the array can't be disposed until
it is initialised, and the disparity between
the dynamic and static length would not matter.
The static length is required to free the memory.

This suggests an alternate solution with zero
impact on the sweep: swap the meaning of the
length count in the heap block and pial list.

This means the 'free' routine that disposes
of unreachable heap memory would have to check
the list to find the real memory length.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
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


  reply	other threads:[~2004-09-11  3:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-09  2:10 Jon Harrop
2004-09-09  5:08 ` Ville-Pertti Keinonen
2004-09-09  7:17 ` Jean-Christophe Filliatre
2004-09-09  8:23   ` Richard Jones
2004-09-09  9:08     ` Olivier Andrieu
2004-09-09 12:08       ` Basile Starynkevitch [local]
2004-09-09 12:31         ` Damien Doligez
2004-09-09 10:42     ` Gerd Stolpmann
2004-09-09  9:37 ` Damien Doligez
2004-09-09 10:34   ` Jean-Christophe Filliatre
2004-09-09 12:15     ` Igor Pechtchanski
2004-09-09 13:01   ` Brian Hurt
2004-09-09 20:08     ` [Caml-list] 32-bit is sticking around Brandon J. Van Every
2004-09-09 21:04       ` Jon Harrop
2004-09-11 15:30         ` Lars Nilsson
2004-09-11 16:24           ` [off topic] " David MENTRE
2004-09-11 17:52             ` Lars Nilsson
     [not found]           ` <200409111656.11952.jon@jdh30.plus.com>
2004-09-11 17:47             ` Lars Nilsson
2004-09-09 16:58   ` [Caml-list] Gripes with array Jon Harrop
2004-09-10  5:56     ` Array.init (was [Caml-list] Gripes with array) Christophe Raffalli
2004-09-10  8:53       ` Richard Jones
2004-09-10 14:50         ` Damien Doligez
2004-09-13  7:02       ` Christophe Raffalli
2004-09-10 13:45     ` [Caml-list] Gripes with array Damien Doligez
2004-09-11  1:43       ` skaller
2004-09-11  3:16         ` skaller [this message]
2004-09-11 14:36       ` Jon Harrop
2004-09-11 20:53         ` Damien Doligez
2004-09-12 15:33           ` Jon Harrop
2004-09-12 16:07             ` Basile Starynkevitch [local]
2004-09-10 23:48 ` brogoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1094872560.23076.176.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=damien.doligez@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).