[Openmcl-devel] Patch: ALLOC-LAP-OPERAND-VECTOR

[Gary Byers]

Hm.  It's 4AM here, so I'm not sure that I fully trust my knee-jerk
reaction, but my knee-jerk reaction is that (since these things are
aggressively free-listed) we'll need to be careful about mixing sizes.
(E.g., if we're cross-compiling targeting the ARM from a PPC host,
we wouldn't want the ARM to blindly grab a 5-element vector that
the PPC had put on the freelist.)

Maybe the right thing to do is to always cons up a fresh vector
when cross-compiling (if the target LAP has a different max
operand count than the host.)

It's been a long time since I've seriously tried to evaluate the
cost of freelisting vs allocation/GC; when I last did so, freelisting
won.

The freelist here (*OPERAND-VECTOR-FREELIST*) is thread-specific:
every thread gets an empty one, so there's no need to do any locking
when modifying it (this is one of the few cases where
WITHOUT-INTERRUPTS is actually the right thing, since you -do- want
to ensure that the modification is atomic.)  When that was all done,
locking was probably more expensive than it is now (and there might
be other ways of ensuring that a global freelist is accessed/modified
in a thread-safe way.)

In the short term, I'm tempted to think that it'd be safest to do
something like:

(defvar *lap-operand-vector-size*
        #+ppc-target 5  ; maybe make this an attribute of the target/arch
        #+arm-target arm::arm-lap-operand-vector-size)

(defun alloc-lap-operand-vector (&optional (size *lap-operand-vector-size*))
   (without-interrupts
     (if (/= size *lap-operand-vector-size*)
       (make-array size :initial-element nil)
       ;;; Else try the freelist mechanism
       ...)))

There's a similar issue when things get returned to the freelist;
you'd only want to do that if they were of *lap-operand-vector-size*
(and just let the GC deal with them otherwise.)



On Mon, 11 Jul 2005, James Bielman wrote:

> I needed more than 5 parsed LAP operands for ARM to handle various
> special/fake operands (the condition code, shifter values, etc).
>
> I looked around some to make sure nothing else depends on this 5
> and didn't see anything...
>
> Index: risc-lap.lisp
> ===================================================================
> RCS file: /usr/local/tmpcvs/ccl-0.14-dev/ccl/compiler/risc-lap.lisp,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 risc-lap.lisp
> --- risc-lap.lisp	19 Oct 2003 08:57:09 -0000	1.1.1.1
> +++ risc-lap.lisp	11 Jul 2005 09:17:24 -0000
> @@ -53,7 +53,7 @@
>
> (def-standard-initial-binding *operand-vector-freelist* (%cons-pool))
>
> -(defun alloc-lap-operand-vector ()
> +(defun alloc-lap-operand-vector (&optional (size 5))
>   (without-interrupts
>    (let* ((v (pool.data *operand-vector-freelist*)))
>      (if v
> @@ -62,7 +62,7 @@
>                (svref v 0))
> 	 (%init-misc nil v)
>          v)
> -       (make-array 5 :initial-element nil)))))
> +       (make-array size :initial-element nil)))))
>
> (defun free-lap-operand-vector (v)
>   (without-interrupts
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>