You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Run the above script in docker
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
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";
}
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.
Activity
fredemmott commentedon May 6, 2021
Thanks; filed internally and assigned to on-call - T90315482 for our reference
oulgen commentedon May 10, 2021
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.
fredemmott commentedon May 10, 2021
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.