Re: Gradual Growth of Memory Use?

Perhaps a tagging field could be used in Actor representations to specify which kind of Dispatch thread should be used to execute its behavior. This will necessarily limit the parallelism, splitting the Dispatch thread pool into two or more subgroups. But it might be worth examining.

BECOME presents an issue, since an Actor could BECOME a behavior that changes the nature of its Dispatch needs. So BECOME needs to also mutate the tags, or rather a BEHAVIOR needs to become an entity rather than just a simple functional closure.

But your description of SYSTEM:APPLY-WITH-ALLOCATION… leads me to believe that it needs the same kind of mechanism as is used for UNWIND-PROTECT, and CATCH. That once you exit the block causes an unwinding of the control conditions. 

And that is also at odds with Actors. Actors have no dynamic history. Yet their allocations must persist indefinitely. So even the concept of stack histories are at odds with Tasks as a separate thing from Threads. In actual fact, Actors don’t acknowledge the existence of Threads - those are simply a machine implementation detail beneath the Actor system. No Threads, no Locks, at the Actor level.



> On Mar 14, 2025, at 11:39, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> So, in an Actor-centric system, where the notions of Task and Thread are divorced, one should not use SYSTEM:APPLY-WITH-ALLOCATION-IN-GEN-NUM, since you have no way to know which machine thread executes any given Actor. 
> 
> But an Actor may have in mind, as holder of state, that its own allocations ought to be in some specific generation. Hence, either all Dispatch threads perform this SYSTEM:APPLY…, or none of them should.
> 
> It is perfectly understandable that a Call/Return architecture should choose to behave this way. But it really mixes up the concepts of Task vs Thread and makes them permanently enmeshed. And in the past, there was no concept of separation of Task and Thread.
> 
> Perhaps an Actor system needs a totally different architecture after all? I have a colleague attempting to do just this with FPGA’s. I am not personally ready to give into the purist view that “It’s Actors all the way down…”. There are substantial benefits to Call/Return architectures. And I have, so far, been able to blend the two worlds quite successfully.
> 
> - DM
> 
>> On Mar 14, 2025, at 11:04, Martin Simmons <[email protected]> wrote:
>> 
>>>>>>> On Thu, 13 Mar 2025 17:21:50 +0000, Tim Bradshaw (as tfb at tfeb dot org) said:
>>> 
>>> One thing to remember is that the control of allocation using system:apply-with-allocation-in-gen-num is, I am pretty sure, based on the dynamic *extent* not scope, so any allocation from other processes will also end up in that generation.  Again, Martin will know better than I do, of course.
>> 
>> system:apply-with-allocation-in-gen-num has dynamic scope on all 64-bit
>> LispWorks 8.x platforms, so it only affects the calling thread.
>> 
>> -- 
>> Martin Simmons
>> LispWorks Ltd
>> http://www.lispworks.com/
> 
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html