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

On 12 March 2012 07:05, Paul Khuong <pvk@...> 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

Thread view

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.
The net result is that, rather than deadlocking, we have slower functions. Better, in the long run, these slower functions are converted into funcallable instances that jump to compiled code (overhead: a single indirect jump). I'm also doubtful of the policy of punting to SB-EVAL whenever the world lock is held by another thread.
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).
Obviously, nikodemus's work to eliminate the world lock would be even better, but, in the meantime, this lets people build useful systems.
I'm not that confident about the changes, especially without tests, so I'll wait and think a couple days before committing.
Paul Khuong

Paul Khuong <pvk@...> writes:
> However, 1) is extremely hacky, and 2) feels like random band
> aids. Test cases, comments, review and suggestions welcome (:
It's not a great test case, but might this also fix the hunchentoot
deadlock, which goes something like (details are fuzzy at this distance)
load
(asdf:oos 'asdf:load-op :hunchentoot)
(hunchentoot:start ...)
and start spawns a thread which tries to compile a dispatch function,
which it can't do because the main thread is holding the compiler
lock....
Cheers,
Christophe

On 12 March 2012 10:01, Christophe Rhodes <csr21@...> wrote:
> It's not a great test case, but might this also fix the hunchentoot
> deadlock, which goes something like (details are fuzzy at this distance)
> load
> (asdf:oos 'asdf:load-op :hunchentoot)
> (hunchentoot:start ...)
> and start spawns a thread which tries to compile a dispatch function,
> which it can't do because the main thread is holding the compiler
> lock....
The hunchentoot issue is due to the fasl-loader holding the world
lock. (Which we should be rid of the next month, now that I'm back in
the saddle.)
Cheers,
-- nikodemus

On 12 March 2012 07:05, Paul Khuong <pvk@...> 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

Forgot to CC the list.
---------- Forwarded message ----------
From: Nikodemus Siivola <nikodemus@...>
Date: 14 May 2012 20:07
Subject: Re: [Sbcl-devel] Less world-locking in PCL
To: Paul Khuong <pvk@...>
On 27 March 2012 11:22, Nikodemus Siivola <nikodemus@...> wrote:
> 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.
Well, it is part of my threading work now. :)
https://github.com/nikodemus/SBCL/tree/wip-clos-sans-compiler
Above is current the work in progress tree -- not much there yet, but
enough to show the basic idea. (Could not find my old tree, so this is
what I've hacked up today -- hence not very far yet, and virtually
untested.)
Cheers,
-- nikodemus
--
Cheers,
-- Nikodemus

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details