Closed waneck closed 7 years ago
Another strange thing is that on Java, some Issue
modules are occupying 1+MB !
It just came to my mind that this can be a problem with our own unit tests (a bad behaving macro, perhaps?). @ncannasse, I know that you've been using the compilation server for some time now, can you try this on your bigger projects?
Good news - I made a simple project with a huge amount of trace("Hello,World");
and no leaks. Seems to have something to do with our unit tests macros then.
It'd be great if we can find what's going on then - and improve haxe --display memory
to include macro memory as well
The cache seems clean, 56MB is not much and there does not seem to be a leak there. There might be a leak in the macro context if we have a static var acccumulating some data (because the macro context is being reused between compilations, and is not listed in --display memory
)
PS: you should be able to confirm that by measuring the memory size of Typer.macro_interp_cache
How do I do that?
Or if you want a fine detail, you can try to list the Interp context globals one by one, while excluding all the others (for cross references)
Common.mem_size Typer.macro_interp_cache
Will do that. Thanks!
Measuring the size of a value by excluding some others in order to know its "own" size is a bit more tricky (see Main.display_memory code)
Okay, that'll be a nice addition anyway
Is this an issue or not?
This is an issue with our unit tests; Adding how much memory each module occupies when running --display memory
would be a great way to debug that; so I think we should still add this. This isn't however a 3.2 priority in any way
I think this has been fixed. Feel free to reopen if not!
At first I thought it was something wrong with Java/C# (and I think indeed it was - it had to do with I might be doing something wrong, and I think the libs weren't flushing, which indeed made the situation worst (btw, -swf-lib might have the same issue). But as I solved this (on e16c481474ed58ab58bd843b6d60db6ad9fd1b57 ), it still leaks memory.
I've also tried reverting to a revision before ca3a08430fc1cb11194e9eda95d5fa0a1c60ea6c , but sadly it still happens:
As you can see, the memory after a few runs is already occupying 1.5GB, even after
haxe --display memory
is invoked.--display memory
shows the following result:As the shell suggests, this happens on 8d6351f - which was before the compilation server changes. The same result happens on latest