[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fixes to goops + light structs + 'u' slots

From: Andy Wingo
Subject: Re: fixes to goops + light structs + 'u' slots
Date: Mon, 14 Apr 2008 23:45:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Hi Mikael!

On Sun 13 Apr 2008 21:09, "Mikael Djurfeldt" <address@hidden> writes:

>> > I have heard that in a well-done CLOS implementation, accessors are are
>> > generally faster than slot-ref
> Note that the current implementation *does*
> compile in the slot position into this form and indeed *has* the
> property which Andy mentions above.

I did not realize this. Thanks for mentioning it. I have shied away from
GOOPS internals in the past, but every time I have a brush with them I
learn something interesting.

What is your perspective regarding <foreign-slot>? I wrote a bit about
what I did recently in Guile-Gnome here:

I define a class with a foreign slot like this:

guile> (use-modules (oop goops))
guile> (define-class <foo> () (bar #:class <foreign-slot>))
guile> (define x (make <foo>))
guile> (slot-set! x 'bar 45)
guile> (slot-set! x 'bar 450000000000000000000)

In current input:
   6: 0* [slot-set! #<<foo> b7dbaa60> bar {450000000000000000000}]

<unnamed port>:6:1: In procedure slot-set! in expression (slot-set! x (quote 
bar) ...):
<unnamed port>:6:1: Value out of range 0 to 4294967295: 450000000000000000000
ABORT: (out-of-range)

Is this designed to work? It seems that all is still not right,
@slot-ref (only used in accessors, not in slot-ref) accesses the slot as
a SCM regardless of whether is is a 'u' slot or a 'p' slot. I suppose
that part of the dispatch/compilation needs to be made more

>  Also, SMOB-based accessors would
> be more heavyweight with regard to class creation and memory
> consumption than the current solution.

Regarding memory consumption. Currently, structs are double-cells: one
word for the vtable, one for the data, one empty, and one for the
"STRUCT_GC_CHAIN", used (please correct me) during GC to ensure that
structs are freed before their vtables.

This seems to be to be a waste of memory in instances, in that they
occupy 4 words when they only need 2. Is it not possible to avoid this?
I have puzzled over this for a number of hours, but have not really come
up with anything that seems workable, given our lazy incremental
sweeping. I suppose another bitvector for structs in the cards would
work; you could run through it at the end of marking, and mark all
structs' vtables.

> In any case, *please* always benchmark changes like this against previous 
> code.

Will work on some benchmarking, I am very interested to see how some of
the method dispatch and compilation code works.


ps. I'm happy to see you around!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]