[armedbear-devel] svn r12228 breaks build

[logicmoo at gmail.com]

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 at gmail.com>
To: "Alessio Stalla" <alessiostalla at gmail.com>
Cc: <dmiles at users.sourceforge.net>; <armedbear-devel at 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 at 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?