Ok, now I'm getting the expected out-of-memory error. Reworked a bit how
the live stack is managed and also added some predictive code to collection
class allocations to try to predict ahead of time how large the live stack
should be, which allows allocations error to (mostly) be handled as regular
here are my results ( slightly modified the script )
[enrico@enrico-mbp oorexx.tests]$./gc2.rx
grabbed10gb 21:40:58.682841
grabbed20gb 21:41:05.994087
grabbed30gb 21:41:13.765010
grabbed40gb 21:41:21.462267
grabbed50gb 21:41:29.247617
grabbed60gb 21:41:36.993362
I’m guessing that we were getting eom failures earlier with the old code
so we never reached the point of getting a livestock allocation failure.
On Sun, Aug 26, 2018 at 1:23 PM Erich Steinböck
wrote:
> I wonder why this is popping up only now. Wouldn't we always have had a
> good chance that t
I wonder why this is popping up only now. Wouldn't we always have had a
good chance that the liveStack needed expansion (because we now have more
active objects than before) when a terminal out-of-memory exception
triggered a GC? Why then did this work until now?
On Sun, Aug 26, 2018 at 7:00 PM
Yes, I understand, but the root cause of this problem is a failure trying
to expand the liveStack during a garbage collection. The call to
reportException() at that time causes a recursive allocation failure,
resulting in the eventual out-of-stack condition. I suspect the only real
way to handle th
The actual failure is stack overflow (due the the infinite recursion it
goes into)
Unhandled exception at 0x07FED88162FC (rexx.dll) in rexx.exe:
0xC0FD: Stack overflow (parameters: 0x0001,
0x000D3FC0).
Ah good, this confirms my suspicions about one of the things I need to fix.
It's actually amazing that this is the first time an issue has occurred
here in 25 years.
Rick
On Sun, Aug 26, 2018 at 9:40 AM Erich Steinböck
wrote:
> By reserving some memory in a program outside of the debugger befor
Ok, I was able to find the issue. With an object like a very big array that
holds lots of objects, it is necessary to expand the marking stack size
during the GC process. The failure was happening because this expansion was
failing. It looks like Windows terminated things because Windows itself was
>
> devenv /debugexe rexx.exe myprog.rex
> And just start it running by hitting F5
>
This works for the typical script, but for me running above memory exhaust
script will almost consistently take down devenv itself. After trying
repeatedly, the debugger once showed an exception in LiveStack::reall
Start the process in the debugger first. There are events that don't always
show up as traps. Do this using
devenv /debugexe rexx.exe myprog.rex
And just start it running by hitting F5. It will break if there is some
sort of terminating event.
Rick
On Sun, Aug 26, 2018 at 8:07 AM Erich Steinböc
>
> It still just runs to completion for me on Windows
>
Here's a version that should show the issue on any platform (it does for
me):
~~~
m = .Array~new(100)
chunk = 500e6
signal on syntax
-- grab memory chunks until almost exhausted
loop
m~append(.MutableBuffer~new(, chunk))
.stdout~charOut
It still just runs to completion for me on Windows. If this is dying to for
you, run it in the debugger to see why it is terminating.
Rick
On Sun, Aug 26, 2018 at 6:05 AM Erich Steinböck
wrote:
> The issue is about what happens when the loop *doesn't* complete, not
> when it *does*.
> If you've
The issue is about what happens when the loop *doesn't* complete, not when
it *does*.
If you've got 16 GB free, just add `m = .MutableBuffer~new(, 15e9)` as the
first statement and then run the loop.
When it doesn't complete due to lack of memory, with the latest 64-bit
trunk on Windows 7, Windows
I tried a similar experiment on Windows 10, same result. Each GC cycle took
longer because of the larger numbers of large objects in the array, but it
eventually completed.
Rick
On Sat, Aug 25, 2018 at 7:08 PM Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:
>
> >
> I notice that below code now just ends without any indication on Windows and
> will get automatically killed on Ubuntu after about 7 mio iterations (this is
> on 64-bit builds on some specific machines; you might need to tweak n
> depending on your system/memory configuration).
> … … ...
run
It runs all the way to completion for me on Windows (64-bit) without an
error. Could it be possible that Ubuntu is killing it because it is hitting
some per-process memory limit rather than returning a NULL for the memory
failure. This program really should have been much affected by the new code
e
I notice that below code now just ends without any indication on Windows
and will get automatically killed on Ubuntu after about 7 mio iterations
(this is on 64-bit builds on some specific machines; you might need to
tweak n depending on your system/memory configuration).
This used to raise error
On Wed, Aug 22, 2018 at 12:06 PM Mike Cowlishaw wrote:
Excellent! Will this affect stems' performance at all?
Probably not. This deals mostly with how the storage used for very large
objects are managed. Stems are composed of lots of small objects. The
effects would more likely be seen
*To:* Open Object Rexx Developer Mailing List
> *Subject:* [Oorexx-devel] A simple benchmark result of the new GC code.
>
> Just ran this simple program that has always caused issues with the
> garbage collector.
>
> str = "This is a test"
> add = "This is a test"~
Excellent! Will this affect stems' performance at all?
Mike
_
From: Rick McGuire [mailto:object.r...@gmail.com]
Sent: 21 August 2018 21:24
To: Open Object Rexx Developer Mailing List
Subject: [Oorexx-devel] A simple benchmark result of the new GC code.
Just ran this s
I can successfully run regression tests with a "largeobject" build.
With my testgroup selection memory footprint shrinks by 25% vs trunk (568
MB vs. 752 MB).
To repeat Rony: impressive :-)
--
Check out the vibrant tech comm
On 21.08.2018 22:24, Rick McGuire wrote:
> Just ran this simple program that has always caused issues with the garbage
> collector.
>
> str = "This is a test"
> add = "This is a test"~copies(100)
> do forever
>str = str add
>say str~length
> end
> I let it run on both trunk and and prototy
Just ran this simple program that has always caused issues with the garbage
collector.
str = "This is a test"
add = "This is a test"~copies(100)do forever
str = str add
say str~lengthend
I let it run on both trunk and and prototype until the sizes reached
about 28Mb per string.
On the tru
23 matches
Mail list logo
