Re: [Sbcl-devel] Less world-locking in PCL

[Nikodemus S. <nik...@ra...>]

On 12 March 2012 07:05, Paul Khuong <pv...@pv...> wrote:

> A development branch is up at https://github.com/pkhuong/sbcl/tree/no-world-lock-pcl. The patches take care of two issues:
>
>  1. PCL no longer *has* to call COMPILE to function to generate functions
>  2. Avoid grabbing the world lock in CPL-OR-NIL and in CHECK-WRAPPER-VALIDITY
>
> It seems to work: not only does it still pass all tests on linux/x86-64 (according to Stelian), but it also avoids deadlocks when building iolib under SWANK (Stelian's tests, again).
>
> However, 1) is extremely hacky, and 2) feels like random band aids. Test cases, comments, review and suggestions welcome (:
>
> 1) is implemented by attempting to grab the world lock, without blocking if it isn't
> available. If we can't acquire the world lock, PCL instead uses SB-EVAL to return
> interpreted functions that are opportunistically converted to native code each time
> they're called. That's all in src/pcl/macros.lisp and it seems Rube Goldberg-y. It also
> depends a bit on a patch to sb-eval to support the compilation of interpreted closures;
> I'm not convinced it's the best way to do it.

I have (hm, had? can't find it just now) a not-quite-shipshape tree
somewhere that takes the same approach to some of the PCL issues, but
uses closures instead of interpreted functions. (Re-instating a code
path that was deleted a few years back.) That tree is not part of my
threading work. The motivation there was to speed up CLOS code by
compiling things only if they get called at least N times.

...I'm not convinced it's the best way either.

> 2) seems obviously correct, but I don't know what else could be similarly improved. What
> do you think of switching the world-lock to an upgradable reader/writer lock? It would
> let us more easily exploit our read-mostly common cases, with less hand-rolled code
> duplication (but we'd have to handle write upgrade failures).

I think R/W lock is TRT class graph related issues in general.

I like the wrapper validity change and the less-eager finalization.

I didn't study the tree in great detail yet, but overall it looks fine to me.

Cheers,

 -- Nikodemus