I have some progress towards the patch ;; INLINE REPORT total=653 cannot=1490 soon=0 inlined-calls=2280 <- thats in building ABCL library
First, I rewrote a Java PrettyPrinter to transform the AST to make primtive subclasses produce static funcions in the outer classes.. Instead of reflection, I produced synthetic methods to make the non-static execute(..)s to call the static ones. 653 of these are done this way.
Here is the transformed src: http://uabcl.googlecode.com/files/start-of-inlines.zip
Then I used Allesio's .patch on compiler-pass2.lisp to make bytecode call the static methods instead. 2280 call site were transformed this way
First here was a couple successes: (from decompiling the .cls files)
lispobject.aset(Primitives._ARRAY_ROW_MAJOR_INDEX_execute( lispobject, alispobject[2]).intValue(), lispobject1 = alispobject[0]);
That called #'ARRAY-ROW-MAJOR-INDEX
And
LispObject lispobject1 = HashTableFunctions.GETHASH_execute( lispobject, SYM223280_TRACE_INFO_HASHTABLE.symbolValue(lispthread));
Before that inline it would have been
lispthread.execute( Symbol.GETHASH, lispobject, SYM223280_TRACE_INFO_HASHTABLE.symbolValue(lispthread));
So that is good news!
However I could not do this to 1490 call sites. due to the fact that there was no static function avalible because the primtive was produced by the lisp compiler and had no method stub.
lispthread.execute(SYM223284_SET_FDEFINITION, lispobject, lispobject2);
That needed to say:
fdefination_22._SET_FDEFINITION_execute(lispobject, lispobject2);
that was %set-fdefinition which was defined in fdefination.lisp
So I still need to do some more work on getting the lisp part o the compiler to produce outer method stubs with inroads to being called via invoke-static.
I ran the ANSI-TESTS and CL-BENCH ..Tthe ansi-tests had too much variance in Time to say anything eigther way.. I proved to myself that the inlines was better.. a few times.. then I proved to myself a couple more time they weren't any faster. So didnt prove anything at all. (and I had some regressions that have to be fixed by removing some struct things from the inlinable registry (or something)) The CL-BENCH is also a bit too varied to say anything. But shouldnt expect too much yet since only 1/3 of the callsites that should be inlined are when I ran them.
PLEASE Anyone who wants, can download that .zip file and see of that can work on compiler-pass2.lisp To make the emitted primtives (and closures?) to produce statically invokable sites. (Also a clear way to find thm at later compile passes)
I am kinda sorta working on that.. but its easier for me to decompile the classes to .java.. (I use a patched JODE instead of JAD). Reprint them.. and recompile them (instead of doing it with .lisp)
However doing it with comnpiler-pass2.lisp would be much prefered and appriciated
----- Original Message ----- From: "Ville Voutilainen" ville.voutilainen@gmail.com To: "Alessio Stalla" alessiostalla@gmail.com Cc: dmiles@users.sourceforge.net; armedbear-devel@common-lisp.net Sent: Tuesday, December 01, 2009 1:55 AM Subject: Re: [armedbear-devel] svn r12228 breaks build
2009/12/1 Alessio Stalla alessiostalla@gmail.com:
Let me add that, iirc, our compiler is smart enough to translate (funcall #'something a b c) to the same code it generates for (something a b c). It would only need to fall back to reflection if the parameter to funcall is not constant, as in (let ((fn #'something)) (funcall fn a b c)). Also what is especially costly about reflection is not the invocation per se but the lookup of the methods, and that is done only once, when the primitive is instantiated or when it makes the first reflective call (depending on the "lazy" flag).
I think the obvious route forward is to make a patch and measure. Then we'll know whether there are performance changes. Has anybody done measurements with the current partial patches, or have I missed a more comprehensive patch?