https://issues.dlang.org/show_bug.cgi?id=12844

--- Comment #1 from Orvid King <blah38621@gmail.com> ---
Just let it run to 12.4gb with no end in sight.

--

https://issues.dlang.org/show_bug.cgi?id=12844

--- Comment #2 from Orvid King <blah38621@gmail.com> ---
Also, dat and planePattern in the foreach loop should actually be swapped, but it never gets to the point where it actually reports this error.

--

https://issues.dlang.org/show_bug.cgi?id=12844

Justin Whear <justin@economicmodeling.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |justin@economicmodeling.com

--- Comment #3 from Justin Whear <justin@economicmodeling.com> ---
I tested it out to 174GB before killing it.  Perf says the top offenders are
`Dsymbol::isTemplateMixin()`, `Dsymbol::pastMixin()`, and
`CompoundStatement::interpret(InterState*)`.

--

https://issues.dlang.org/show_bug.cgi?id=12844

--- Comment #4 from Orvid King <blah38621@gmail.com> ---
Alright, had someone else test on a machine with 256gb of memory, they ended up killing it after it hit 174gb of ram.

--

https://issues.dlang.org/show_bug.cgi?id=12844

Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh@gmail.com

--- Comment #5 from Dmitry Olshansky <dmitry.olsh@gmail.com> ---
Matters are that made much worse by the fact that at CTFE all of [0-9] character sets get rebuilt for each occurrence, because charset cache is thread-local (no luck at CTFE). The memory leak itself though is a compiler issue.

Hm, I could try and have an extra cache local to the scope of each regular expression compilation.

--

https://issues.dlang.org/show_bug.cgi?id=12844

--- Comment #6 from Orvid King <blah38621@gmail.com> ---
Perhaps it would be possible to simulate a character set cache by using a template to represent the set of characters included?

For the runtime version, is there any real reason to force the charset cache to be thread local? Could it perhaps be global with dirty read and a possible re-calculation?

>From my experience, most nievely implemented caching mechanisms fail to
understand that a best-effort cache is usually more than enough.

--

https://issues.dlang.org/show_bug.cgi?id=12844

Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://github.com/D-Progra
                   |                            |mming-Language/phobos/pull/
                   |                            |2234

--- Comment #7 from Dmitry Olshansky <dmitry.olsh@gmail.com> ---
Might help: https://github.com/D-Programming-Language/phobos/pull/2234

It still runs out of 4Gb on my machine over here though...

--

https://issues.dlang.org/show_bug.cgi?id=12844

--- Comment #8 from Orvid King <blah38621@gmail.com> ---
Just let it run to 7gb even with that PR.

--

https://issues.dlang.org/show_bug.cgi?id=12844

Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennytm@gmail.com

--- Comment #9 from Dmitry Olshansky <dmitry.olsh@gmail.com> ---
*** Issue 7442 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=12844

Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|nobody@puremagic.com        |dmitry.olsh@gmail.com

--