On Sat, Jun 29, 2019 at 11:56 PM David Walker <d...@mudsite.com> wrote:
>
>
> On Sat, Jun 29, 2019 at 15:52 Nikita Popov <nikita....@gmail.com> wrote:
>
>> On Sat, Jun 29, 2019 at 11:25 PM Benjamin Morel <benjamin.mo...@gmail.com
>> >
>> wrote:
>>
>> The leaked memory is an allocated but unused class
>> entry. We could plug that particular leak -- but I should emphasize that
>> the current behavior is incorrect and once the key collision issue is
>> resolved this will create a new class for each eval.
>
>
> To clarify; you’re saying that the behavior seen in the non scaled case is
> kind of “wrong” in the sense that it’s exposing the big in naming of the
> anon class. Once the bug is resolved, the two behaviors shown should mimic
> each other, wherein the memory footprint would grow as in the example
> eval() case.
>
What is the "non scaled case"? To repeat what I said earlier: Without eval
there is no and will not be a leak.
The bug is that eval() currently reuses an existing class instead of
creating a new one each time. Calling get_class(eval("return new class
{};")) should be returning a new string every time, while for OPs script it
currently does not.
tl;dr:
while (1) {
get_class(new class {}); // should always return the same
get_class(eval("return new class {};")); // should always return
different, currently may return same due to bug
}
Nikita
