Memory leak with reified generics

[ssandler]

Describe the bug Each call to a function that uses reified generics appears to increase the memory usage of hhvm. This memory doesn't get reclaimed and this can continue until the program crashes.

Standalone code, or other way to reproduce the problem

$ cat /tmp/test.hack
<<__EntryPoint>>
function main(): void {
    $iterations = (int) (vec(\HH\global_get('argv') as Container<_>)[1] ?? 0);
    echo "iterations is $iterations\n";
    $obj = new Foo();
    for ($i=0; $i<$iterations; $i++) {
        get_classname_wrapper<Foo>($obj);
        if ($i % 1000 === 0) {
            echo "$i memory usage: ".memory_get_usage(true)."\n";
        }
    }
    echo "memory usage: ".memory_get_usage(true)."\n";
}

function get_classname_wrapper<<<__Enforceable>> reify T as Foo>(T $obj): string {
  return 'hi';
}

class Foo {}

$ docker run -v /tmp/test.hack:/tmp/test.hack hhvm/hhvm:4.108-latest hhvm /tmp/test.hack 1000000

Steps to reproduce the behavior:

1. Run the above script in docker
2. Observe that memory usage increases linearly

Expected behavior

Memory usage stays constant with repeated calls.

Actual behavior

Memory usage increases with each call.

Environment We first observed this with HHVM 4.56 on Ubuntu 18.04, but reproduced it on the latest public hhvm docker container hhvm/hhvm:4.108-latest

[fredemmott]

Thanks; filed internally and assigned to on-call - T90315482 for our reference

[oulgen]

The memory regression is not related to reify and/or jit/interp. I simplified your above code and executed with and without reify keyword, as well as, trying with and without jit. The memory regression is identical/comparable.

<?hh

class Foo {}

function get_classname_wrapper<reify T>(T $obj) {
  return 1;
}

<<__EntryPoint>>
function main(): void {
  $obj = new Foo();
  echo "memory usage: ".memory_get_usage(true)."\n";
  for ($i=0; $i<10000; $i++) {
    get_classname_wrapper<Foo>($obj);
  }
  echo "memory usage: ".memory_get_usage(true)."\n";
}

[fredemmott]

Sorry, we don't really have good next steps: the leak is very small, which makes it difficult to track down; it's unlikely we're going to be able to dedicate more time to this, especially as the memory should be freed between requests.