[armedbear-devel] Performance of eq hash tables
2013-05-22 20:35:08 GMT
_______________________________________________ armedbear-devel mailing list armedbear-devel <at> common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
_______________________________________________ armedbear-devel mailing list armedbear-devel <at> common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
_______________________________________________ armedbear-devel mailing list armedbear-devel <at> common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Well, to some extent I can see your problem. Indeed there seem to be no slots in the 'MOP:FUNCALLABLE-STANDARD-OBJECT class. The layoutFuncallableStandardClass is what confused me, but that's indeed the layout of the metaclass.So, you're correct that the fix works by accident. The solution should be to add a slot by the name 'MOP::NAME to the FUNCALLABLE-STANDARD-OBJECT. That slot can contain the name of the object (ie function) for which the item is defined. In that case, we should probably remove the direct slot MOP::NAME on the standard generic function, since it's already defined on the superclass if we decide to do that.
_______________________________________________ armedbear-devel mailing list armedbear-devel <at> common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Hi Rudi,
Basically the expectation we violated was the fact that %set-lambda-name didn't want to take a funcallable instance as its function argument. The commit changed that and used the first slot of the funcallable instance class layout (called NAME) to store the name. I guess we forget to finalize the class somewhere, so the spots don't appear?
Bye,
Erik.
sent from my phoneOn Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi <at> constantly.at> wrote:Hi,
I suspect that the changes in commit r14452 only work by accident.
The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since
(class-slots (find-class 'funcallable-standard-object))
returns NIL, these assumptions hold only when the objects are in fact generic functions.
Amusingly,
(function-lambda-expression (make-instance 'funcallable-standard-object))
runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though
(typep (make-instance 'funcallable-standard-object) 'function) => T
so I can't trigger the array-out-of-bounds error right now.
Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly.
Cheers,
Rudi
_______________________________________________ armedbear-devel mailing list armedbear-devel <at> common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Forgot to mention: Pre 14452 it was enough to just quickload cl-cont to trigger the bug.
Bye, Erik
sent from my phone
Hi Rudi,
Basically the expectation we violated was the fact that %set-lambda-name didn't want to take a funcallable instance as its function argument. The commit changed that and used the first slot of the funcallable instance class layout (called NAME) to store the name. I guess we forget to finalize the class somewhere, so the spots don't appear?
Bye,
Erik.
sent from my phoneOn Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi <at> constantly.at> wrote:Hi,
I suspect that the changes in commit r14452 only work by accident.
The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since
(class-slots (find-class 'funcallable-standard-object))
returns NIL, these assumptions hold only when the objects are in fact generic functions.
Amusingly,
(function-lambda-expression (make-instance 'funcallable-standard-object))
runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though
(typep (make-instance 'funcallable-standard-object) 'function) => T
so I can't trigger the array-out-of-bounds error right now.
Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly.
Cheers,
Rudi
_______________________________________________ armedbear-devel mailing list armedbear-devel <at> common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
sent from my phone
Hi Rudi,
Basically the expectation we violated was the fact that %set-lambda-name didn't want to take a funcallable instance as its function argument. The commit changed that and used the first slot of the funcallable instance class layout (called NAME) to store the name. I guess we forget to finalize the class somewhere, so the spots don't appear?
Bye,
Erik.
sent from my phoneOn Apr 2, 2013 7:32 PM, "Rudolf Schlatte" <rudi <at> constantly.at> wrote:Hi,
I suspect that the changes in commit r14452 only work by accident.
The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since
(class-slots (find-class 'funcallable-standard-object))
returns NIL, these assumptions hold only when the objects are in fact generic functions.
Amusingly,
(function-lambda-expression (make-instance 'funcallable-standard-object))
runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT {665C5A83}> is not of type FUNCTION.") even though
(typep (make-instance 'funcallable-standard-object) 'function) => T
so I can't trigger the array-out-of-bounds error right now.
Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly.
Cheers,
Rudi
_______________________________________________ armedbear-devel mailing list armedbear-devel <at> common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Hi,
I suspect that the changes in commit r14452 only work by accident.
The definions of SLOT_INDEX_NAME in FuncallableStandardClass vs FuncallableStandardObject are no
problem, since the latter simply isn't used anywhere. But the new methods getName() and setName() assume
that a) the FuncallableStandardObject instance has at least one slot, and b) that slot holds a name. Since
(class-slots (find-class 'funcallable-standard-object))
returns NIL, these assumptions hold only when the objects are in fact generic functions.
Amusingly,
(function-lambda-expression (make-instance 'funcallable-standard-object))
runs into the type error on line 2666 of Primitives.lisp ("The value #<FUNCALLABLE-STANDARD-OBJECT
{665C5A83}> is not of type FUNCTION.") even though
(typep (make-instance 'funcallable-standard-object) 'function) => T
so I can't trigger the array-out-of-bounds error right now.
Could I have a recipe for triggering the bug? I'd like to see how cl-cont uses
funcallable-standard-objects, and what expectations we violate. I believe I can fix this properly.
Cheers,
Rudi
_______________________________________________ armedbear-devel mailing list armedbear-devel <at> common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
RSS Feed6 | |
|---|---|
30 | |
56 | |
70 | |
34 | |
49 | |
18 | |
55 | |
26 | |
100 | |
44 | |
36 | |
55 | |
41 | |
22 | |
27 | |
59 | |
11 | |
23 | |
45 | |
15 | |
42 | |
50 | |
30 | |
41 | |
20 | |
67 | |
51 | |
115 | |
41 | |
93 | |
47 | |
34 | |
39 | |
29 | |
74 | |
135 | |
135 | |
164 | |
116 | |
157 | |
64 | |
93 | |
93 | |
140 | |
54 | |
8 | |
32 | |
112 | |
89 | |
121 | |
99 | |
181 | |
143 | |
81 | |
136 | |
141 | |
89 | |
4 | |
7 | |
2 | |
16 | |
34 | |
7 | |
11 | |
24 | |
8 | |
22 | |
10 | |
18 | |
35 | |
5 | |
28 | |
51 | |
6 | |
4 | |
5 | |
18 | |
13 | |
13 | |
2 | |
16 | |
12 | |
10 | |
19 | |
13 | |
39 | |
6 | |
20 | |
64 | |
24 | |
12 | |
15 | |
40 | |
25 | |
15 | |
11 | |
31 | |
41 | |
17 | |
36 | |
36 | |
51 | |
164 | |
31 | |
46 | |
13 | |
12 | |
9 | |
1 | |
21 | |
109 | |
66 | |
70 | |
11 | |
33 | |
35 | |
2 |