Greetings, and thank you so much!
This is now in. Your assumptions are correct, but alas the n_used
counter is not reliably maintained. Here is the version now checked
in commensurate with (room):
DEFUN_NEW("TOTAL-BYTES-ALLOCATED",object,fStotal_bytes_allocated,SI,0,0,NONE,OO,OO,OO,OO,(void),"")
{
int i;
unsigned long bytes;
for(bytes=0,i=t_start; i < t_end; i++) {
struct typemanager *tm=tm_of(i);
if (tm->tm_type!=i)
continue;
bytes += TM_NUSED(*tm) * tm->tm_size;
}
bytes+=ncbpage*PAGESIZE;
bytes+=rb_pointer-rb_start;
RETURN1(make_fixnum(bytes));
}
Quite a big difference. I need to fix tm_nused someday. Notes:
1) This is a slight overestimate -- we really should subtract the free
block space from the contiguous allocation usage
2) The algorithm needs correcting when sgc is on -- is one interested
in the active read-write set, of the static read-only set here?
3) This might motivate me to provide a function to print the
contiguous block structure for Matt Kaufmann ...
Also think I fixed the install of clcs/packages.lisp and bin/gcl.
Please let me know if problems persist.
Thanks again so much!
Stephen Wilson <[EMAIL PROTECTED]> writes:
> Hello,
>
> I have been working on evaluating/integrating a Lisp based testing
> framework into Axiom (based on Lift). One of the features is the
> ability to benchmark the running of tests.
>
> To accommodate the benchmark code, I needed a function which returns
> the total number of bytes allocated since the image was started.
>
> I could not find such a function. Perhaps I missed it? There is
> SI:ALLOCATED, but it reports information for a specific type only.
>
> I considered writing a function using SI:ALLOCATED and SI:SIZE-OF for
> personal use. However, when I considered if such a function would be
> of use to GCL, I realized it may be better to attempt it in C.
>
> Of course, if the facility already exists, then this is just a
> learning experience for me. Attached is a patch against alloc.c.
>
> I have two issues with this code:
>
> * Is it correct to assume that all entries in tm_table with the
> tm_size field equal share the same allocation space? I assumed
> this from the documentation for SI:ALLOCATED.
>
> * Im slightly concerned about overflow of the `bytes' variable. Is
> this likely? Should bignum arith be used?
>
> Hopefully this might be of some use to GCL, however I completely
> understand if it is deemed unnecessary, badly implemented, etc.
>
> Sincerely,
> Steve
>
>
--
Camm Maguire [EMAIL PROTECTED]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
