[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:
http://wingolog.org/archives/2008/04/11/allocate-memory-part-of-n
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)
Backtrace:
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
sophisticated.
> 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.
Andy
ps. I'm happy to see you around!
--
http://wingolog.org/
- fixes to goops + light structs + 'u' slots, Andy Wingo, 2008/04/09
- Re: fixes to goops + light structs + 'u' slots, Ludovic Courtès, 2008/04/10
- Re: fixes to goops + light structs + 'u' slots, Andy Wingo, 2008/04/10
- Re: fixes to goops + light structs + 'u' slots, Ludovic Courtès, 2008/04/13
- Re: fixes to goops + light structs + 'u' slots, Mikael Djurfeldt, 2008/04/13
- Re: fixes to goops + light structs + 'u' slots, Ludovic Courtès, 2008/04/13
- Re: fixes to goops + light structs + 'u' slots,
Andy Wingo <=
- Re: fixes to goops + light structs + 'u' slots, Mikael Djurfeldt, 2008/04/14
- Re: fixes to goops + light structs + 'u' slots, Andy Wingo, 2008/04/19
- Re: fixes to goops + light structs + 'u' slots, Mikael Djurfeldt, 2008/04/19
- Re: fixes to goops + light structs + 'u' slots, Andy Wingo, 2008/04/20
- Re: fixes to goops + light structs + 'u' slots, Mikael Djurfeldt, 2008/04/14
- Re: fixes to goops + light structs + 'u' slots, Andy Wingo, 2008/04/15
- Re: fixes to goops + light structs + 'u' slots, Mikael Djurfeldt, 2008/04/16
- Re: fixes to goops + light structs + 'u' slots, Mikael Djurfeldt, 2008/04/16