Will,

does this help?

• Use-of-GARBAGECOLLECT-to-avoid-shared-memory-errors-1478611846970

It's been many years since I have had to be concerned about BASIC garbage collection - (nor since Ardent days). and the methodology is not exposed. Noting that Garbage Collection in WebDE is something very different to do with WWSTATE file housekeeping and the methodology and use of WWSESSION is fairly well known.

I'll leave it up to Rocket regarding any specifics on the methodology, though there are stong indications s the above knowledge article.

Regards

JJ

This article seems to do with external connections.

I was more interested in the use of garbage collection vis a vis multi-user internal connections

Such as, when you connect (login by telnet or a directly connection terminal) it assigns you a workspace, and this is thrown away when you log out.

Within your workspace there are various buffers which can point to strings in attached extended workspace and when these become unused, all the attached workspace is also thrown away.

The article on garbage collection seems to be assuming single-user systems.  Multi-users systems have more issues.

WIll,

While shared access is provided for shared resources - e.g. record. file and process locks - each individual user process runs in its own private workspace. In that sense, garbage collection of an individual database shell is the sole responsibility of that shell. Similarly, The BASIC runtime engine manages its own garbage collection wholly independently in each individual database session as and when required depending upon demand for contiguous memory buffers, any currently fragmented space and free memory, 

In past days on some MV implementations the GARBAGECOLLECT command could be used to force a garbage collection at a point in time for that individual BASIC program instance (EXECUTE did not exist at that time so we can ignore execute sub-levels). Overall this resulted in processes taking longer as garbage collection ran more often than it needed to, however it offered a benefit on strained systems of replacing  any slightly longer and less frequent garbage collection delays which might be perceptible by users with more frequent but much shorter delays. While overall the system was slightly slower this smoothed over occasional delays and gave better responsiveness by making the delays so short as to be beyond human detection. It also came in handy when using real-time communications and both TCP and X.25 MV bridging applications which had very strict timing requirements at the 10ths of a millisecond level. Nowadays it is a non-issue to all intents and purposes in anything I have used since around 1998.

Was there a specific concern? If so the  application profiling may be able to assist. 

In this context, garbage collection is the same for a single user environment and a multi-user environment - which is really just a collection of multiple single user  sessions. The U2 database daemon processes largely take care of redundant shared resource cleanup when processes terminate by cleaning up internal tables mapping currently running processes against the shared resources that are flagged as belonging to these processes. As an example - see the cleanup daemon.

Regards

JJ

------------------------------
John Jenkins
Thame, Oxfordshire
------------------------------