Re: Gradual Growth of Memory Use?

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