Hi Eliot,
When you get a chance, please take a look at System-dtl.1446 in the
inbox (especially the comments). I don't think you have seen it yet.
The VM I am using is 5.0-202311211431-64bit.
Dave
On 2024-02-03 03:12, Eliot Miranda wrote:
> Hi Dave,
>
>> On Feb 2, 2024, at 3:12 PM, lewis(a)mail.msen.com wrote:
>
>> Hi Eliot,
>>
>> MemoryPolicy deserves its own class (and comments). LowSpaceWatcher is
>> the mechanism of reacting to a low space condition and implements no
>> policy.
>
> Of course it implements a policy. It decides to interrupt the current
> running process. And it does so based on examining parameters after the
> mechanism of signaling the low space semaphore has fired, itself
> controlled by a parameter. These parameters can happily live inside a
> MemoryPolicy object, as experience shows (c.f. VisualWorks).
>
>> I'm basically just trying to clarify the existing and/or prior
>> mechanism, and potentially to get some ancient cruft out of
>> SmalltalkImage. Anything related to policy is still sitting in
>> SmalltalkImage.
>
> Si why not avoid the sad pitfall of a one method class, something Pharo
> did hilariously and pathetically with Smalltalk endianness, and start
> on the right track implementing MemoryPolicy, something seriously
> lacking on n Squeak atm?
>
>> But I have to note for the record that the low space watcher does not
>> actually do anything for any configuration I can come up with on my
>> Linux PC. The mechanism works (signal the semaphore and the process
>> reacts with notifier etc), but I can't get the semaphore to be
>> signalled either directly from the VM or as a result of an allocation
>> primitive failure.
>
> That may just be an out-of-date VM. I had to fix something recently to
> get the mechanics working.
>
> Dave
>
> On 2024-02-02 15:24, Eliot Miranda wrote:
>
> David, all,
>
> please do not extract lowSpaceWatcher to a class called
> LowSpaceWatcher. This would be a *serious* mistake. Instead, extract it
> to a class called MemoryPolicy. There is low space, growing &
> shrinking the heap, and soon enough rate control of the incremental old
> space collector to manage.
>
> _,,,^..^,,,_ (phone)
>
> On Jan 28, 2024, at 5:19 PM, lewis(a)mail.msen.com wrote:
>
> I decided to give this idea a try, and I think that it does help with
> the documentation. Please try loading System-dtl.1445 from the inbox,
> then evaluate "HelpBrowser openOn: LowSpaceWatcher". Let me know what
> you think of it :-)
>
> Dave
>
> On 2024-01-27 18:51, Jaromir Matas wrote:
> Hi Dave,
>
> Interesting, I wondered why the low space watcher doesn't have its
> class :)
>
> best,
> Jaromir
>
> On 27-Jan-24 4:53:59 AM, lewis(a)mail.msen.com wrote:
>
> On 2024-01-26 08:32, Taeumel, Marcel via Squeak-dev wrote: Hi Jaromir
> --
>
> What would be a good place to document the current state and intentions
> about low-space watcher? I mean, what would have helped you in this
> case?
>
> Best,
> Marcel
>
> One way to document the low space watcher might be to turn it into a
> proper object with
> a good class comment.
>
> The low space watcher process is currently attached to a class variable
> in class
> SmalltalkImage. This is reasonable and appropriate, but it would be
> just as reasonable
> to have a LowSpaceWatcher object attached to the class variable, and
> let the LowSpaceWatcher
> own the process and implement methods related for that process. The
> semaphore and
> primitive calls could also move from SmalltalkImage to LowSpaceWatcher.
>
> Class SmalltalkImage has a lot of responsibilities already, so moving
> the responsibility
> for managing low space handling to a new class called LowSpaceWatcher
> might be a reasonable
> thing to do. A happy side effect would be to let this new class serve
> as documentation for
> the intended behavior of the low-space watcher process.
>
> Dave