I don't see any issue when I run the mutable buffer program on 64-bit. It
slows down greatly once the buffer gets larger than 1e9, but does complete
without error. Set and breakpoint on reportException and see where the
problem is coming from.
Rick
On Fri, Jun 30, 2017 at 9:00 AM, Erich Steinböck <erich.steinbo...@gmail.com
> wrote:
> OK, thanks.
>
> What about the MutableBuffer scenario? How is that becoming fragmented?
> Aren't we fully allocating a MutableBuffer with the given size at creation
> time? Should we?
>
> Adding s[1e9] = "x"; s~delete(1) after buffer creation will allow the
> appends to successfully complete.
>
> On Fri, Jun 30, 2017 at 2:47 PM, Rick McGuire <object.r...@gmail.com>
> wrote:
>
>> Rewrite the garbage collector so to use a compacting algorithm (a MAJOR
>> effort with a lot of portability concerns). Were I still handling this, I
>> would answer this as "won't fix". I've spent many, many hours on trying
>> various tweaks on this situation and it is a hard problem to solve with out
>> some level of compaction.
>>
>> The basic problem is every time it is necessary to expand the heap, you
>> end up with bits of storage that won't be large enough to satisfy future
>> requests. Eventually the process storage gets fragmented enough that the OS
>> is no longer able to find a contiguous piece of storage for further
>> expansion.
>>
>> One thing I've toyed with is trying to find and return memory segments
>> that don't have any objects allocated. This has always proved to be be
>> tricky and did not really seem to help the situation.
>>
>> Rick
>>
>> On Fri, Jun 30, 2017 at 8:38 AM, Erich Steinböck <
>> erich.steinbo...@gmail.com> wrote:
>>
>>> Rick, I've opened [bugs:#1465]
>>> <https://sourceforge.net/p/oorexx/bugs/1465/> which shows a (memory
>>> fragmentation?) issue with both String and MutableBuffer appends.
>>>
>>> Any ideas welcome if/how this can be fixed.
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> 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
>
>
------------------------------------------------------------------------------
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
