WeakArray finalization never yields

Hi, there!

Please, have a look at WorldState >> #runStepMethodsIn:, which processes the list of deferred UI messages in a loop:

runStepMethodsIn: aWorld
        "Perform periodic activity inbetween event cycles"
        | queue msg limit stamp |
        "Limit processing of deferredUIMessages to a max. amount of time"
        limit := self class deferredExecutionTimeLimit.
        stamp := Time millisecondClockValue.
        queue := self class deferredUIMessages.
        [(Time millisecondsSince: stamp) >= limit
                or:[(msg := queue nextOrNil) == nil]]
                        whileFalse: [msg value].
        "..."

There is a time limit to keep the UI responsive.

Now look at WeakArray class >> finalizationProcess:

finalizationProcess

        [FinalizationSemaphore wait.
         FinalizationLock
                critical:
                        [FinalizationDependents do:
                                [ :weakDependent |
                                weakDependent ifNotNil:
                                        [weakDependent finalizeValues]]]
                ifError:
                        [:msg :rcvr | rcvr error: msg]] repeat

Could be add a "Process yield" in the loop to keep the system responsive when facing complex finalization routines? Or would that just post-pone the problem? We could add support for having many-many small finalizers, which add up to a big amount of time to finalize. Like Morphic's deferred UI message handling does.

What about priorities? At the moment, we have to ways to specify the priority at which priority Object >> #finalize is called.

Has this finalization mechanism been used extensively in some project?

Best,
Marcel

Hi Marcell,

On Mon, 11 Apr 2016, marcel.taeumel wrote:

The finalization process runs at priority 50, so #yield wouldn't make the
UI more responsive at all, only delays would.

> problem? We could add support for having many-many small finalizers, which
> add up to a big amount of time to finalize. Like Morphic's deferred UI
> message handling does.

Finalization will change as soon as the VMs support ephemerons. It might
be the case that they already do.

>
> What about priorities? At the moment, we have to ways to specify the
> priority at which priority Object >> #finalize is called.
>
> Has this finalization mechanism been used extensively in some project?

In a Trunk image Files, Sockets and HostWindowProxies use the finalization
process. Files rely on the higher priority of it. They keep forcing GCs
until there's a new file descriptor available, which only works when the
finalization process is able to release one. So, I think currently there
would be a problem when a higher priority process were trying to open
files and all file descriptors were in use.

Levente

Hi Levente,

think about sound playing, not the GUI. Right now, sound player runs at 50, too.

Best,
Marcel

Well, it would be possible to do something about it, but there's a limit
of achievable granularity. E.g. you have no control over what an executor
will actually do. So even a single executor may take seconds to finish its
job.
By the way, is this an actual problem or just a theoretical one?

Levente

On Mon, 11 Apr 2016, marcel.taeumel wrote:

Hi Levente,

this is just a theoretical problem.

You are right, a single executor can take any time. However, what about supporting a vast load of small executors? We could add support for that with a delay or a yield.

Best,
Marcel