It's might be too late in the game to make these kinds of comments, but
I'll pose them in case it's not. Failing that, the discussion might be
useful as input to future requirement(s). I have not looked into the
current code for allocation and garbage collection, so my bad if this is
redundant or too far afield.
Have one, more, or all of these features, singly or in combination, added:
1. A statement/function/hostcommand/option to force garbage collection
if the amount of free space was less than a specified amount and/or
percentage. It would be issued before entry into a time-critical section
of code. I would propose a default percentage of 50%.
2. A statement/function/hostcommand/option to stop automatic garbage
collection if the amount of space freed was greater than a specified amount
and/or percentage. It would be issued before sections of code where short
delays can be tolerated, but the long delays associated with full garbage
collection would be less so. I again propose a 50% default.
3. A modification (possibly applying to certain objects only, e.g.
large) that would maintain a linked list of free space elements populated
each time an eligible object (e.g. large) is completely DROPped (ref count
= 0). A reference count might need to be added to the relevant object
types as part of the modification. The feature would allow the garbage
collection to terminate quickly if there were enough space in the
free-space list. A first-fit algorithm might be appropriate here.
4. The addition of a reference count, or similar, and a linked-list of
free-space elements, sorted by address. Elements would be added
opportunistically where it is known that the object had no additional
usage; e.g. local variables in a PROCEDURE, ::ROUTINE, or ::METHOD not
passed to another block. Adjacent free-space elements would be combined as
detected.
An advantage, in addition to more consistent timing, might the reduction in
working set size, page reference, and page modification in paging virtual
memory systems. Shortened garbage collection events could enable an
operating system to treat the process more favorably, either by policy or
of incidentally, than if a full-blown garbage collection were done.
The above capabilities might allow greater use of OOREXX in new areas,
where timing is critical, and potentially even up to operating system
components.
OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.
On Sun, Aug 19, 2018 at 6:29 PM, Rick McGuire <object.r...@gmail.com> wrote:
> After the recent discussion about freeing large array storage, I decided
> to take another crack at fixing this problem. My largeobject sandbox branch
> is my latest attempt at this. This version is actually simpler than the
> current one, which never really fixed the issues. This version treats "big"
> objects differently and will return the memory to the system when the
> object is garbage collected. A "big" object is currently defined as greater
> than 1/2 meg for the 32-bit version and 1 meg for the 64-bit version.
> Debugging this also uncovered a couple of bugs in the current memory
> manager (already fixed).
>
> A big part of the simplification came from removing a bit of baggage from
> the original OS/2 code that doesn't really apply any more. Removing that,
> allowed a lot of additional code to be deleted that probably was never
> getting used any way. I'm fairly happy with this version, though I might
> tweak some of the tuning parameters a little as I throw some additional
> tests at it.
>
> Rick
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
