Re: Gradual Growth of Memory Use?

Are you misunderstanding what I meant when I wrote
"system:apply-with-allocation-in-gen-num has dynamic scope"?

system:apply-with-allocation-in-gen-num calls specified function and objects
allocated within the dynamic scope of that function will be in the specified
gen-num.  That doesn't mean the objects allocated within the function have
dynamic scope.

E.g. you could define

(defun cons-in-generation-3 (x y)
  (system:apply-with-allocation-in-gen-num :cons 3 'cons x y))

Or maybe I'm misunderstanding what you are saying?  Are you saying that Actor
code cannot predict the lifetime of any objects that it allocates, so it is
wrong to allocate them in a generation that lives longer than normal?

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/



>>>>> On Mon, 17 Mar 2025 07:04:26 -0700, David McClain said:
> 
> I think I can understand why these allocations are controlled by the dynamic wind on a thread stack. 
> 
> But truly, the allocations should belong to the data, and not to the dynamic state of the execution of a program. If execution state needs to affect the allocations, it can be signaled around the allocations and the data would hang onto the allocated state.
> 
> But data-centered state allows for allocations at some time, and to persist with that data until some possibly disconnected portion of the program decides that the state should be discarded.
> 
> 
> 
> > On Mar 17, 2025, at 06:30, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> > 
> > Yes, understood. 
> > 
> > But the Actor behavior model makes allocations and then exits the dynamic extent, wanting those allocations to remain in effect until some disconnected later time, when some randomly chosen other thread is likely to want to undo those allocations. You cannot control which machine thread executes an Actor behavior. And Actors have no dynamic extent - each is an island to itself. 
> > 
> > So not a good match for a dynamic wind on allocations.
> > 
> > 
> >> On Mar 17, 2025, at 04:52, Martin Simmons <[email protected]> wrote:
> >> 
> >> Putting all of the allocation from an Actor into a specific generation is not
> >> a good approach (e.g. if the Actor calls a generic function, you wouldn't want
> >> to put the generic function's method dispatch caches there).
> >> 
> >> I recommend using SYSTEM:APPLY-WITH-ALLOCATION-IN-GEN-NUM only for specific
> >> allocation, with functions such as CONS and MAKE-ARRAY.
> >> 
> >> -- 
> >> Martin Simmons
> >> LispWorks Ltd
> >> http://www.lispworks.com/
> >> 
> >> 
> >> 
> >>>>>>> On Fri, 14 Mar 2025 11:39:13 -0700, David McClain said:
> >>> 
> >>> 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
> 
> 

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