On Sun, Aug 19, 2018 at 8:23 PM Hobart Spitz <orexx...@gmail.com> wrote:
> 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%.
>
> Not really possible. The only way to actually know the amount of available
free space is to perform a garbage collection first, which is a very
expensive operation that we try to avoid. The algorithm does include heap
expansion when the ratio of live to free storage falls below a threshold.
>
> 1.
> 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.
>
> Again, not possible. Garbage collections get performed whenever we're
unable to satisfy an allocation request.
>
> 1. 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.
>
> There are no reference counts on objects, and in general, reference
counting garbage collection systems are really not feasible because
circular references are possible (for example, an array that contains a
reference to itself).
>
> 1. 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.
>
> Again, reference counts are not possible. Defection of live objects is
done by tracing and marking objects from a few root references. The free
storage is "swept up" by scanning memory looking for unmarked objects and
reclaiming that storage. Adjacent dead objects are already recombined into
larger blocks.
Rick
> 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
>
------------------------------------------------------------------------------
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
