what is the exact meaning of {Property.get 'gc'}.size ?
The documentation says: "Current heap size in bytes". This is not the
current *maximum* heap size, but what is currently in use.
>
> I have a large
problem that consumes quite a lot of memory. When I look into the Task
Manager, I can see that the emulator consumes say 100MB of memory, but
at the same time, {Property.get 'gc'}.size tells me that the heap size
is just about 10 MB.
Possibly your program creates a large amount of temporary data.
True, peak consumption within a loop can be about 600 MB. But it nicely
drops back to (well, almost back to :-)) about 20-30 MB.
IIRC there is no known memory leak in the last release. Anyway if you
find one, please send a bug report with a small program the reproduces
the bug.
I suggest to check your program first. Are you building very huge data
structures that you keep in a global variable? Are you using a port
whose stream is kept in a global variable (pretty common mistake)? Or
an infinite amount of threads waiting on each other?
The 'global' data is not huge. Some of it is static, and the dynamic
content grows in accordance with the heap size (grows from 5 MB at
startup to about 20 MB when at about 30% of the problem is solved, quite
linearly). I use ports, but they are not global (I used to, but I
changed them to local ports). I also create a 'server' thread in each
loop that listens on the port, but it always terminates before the loop
ends.
I added some more debug prints after the loop: {Property.get
'memory'}.code, {Property.get 'memory'}.atoms and {Property.get
'memory'}.names all return constant values, {Property.get
'threads'}.runnable returns 1. How do I tell how many threads are
blocked? I do not create many threads myself, but of course, there are
many propagators created during the loop.
I thought that blocked threads might be the cause of the "heap size not
matching memory consumption" observation. I created artificial tests
that create blocked threads, and it seems that they are included in
'active heap size' (so the blocked threads is not the problem). In these
tests, physical memory consumption is always about say 'active heap
size'+10MB. What I observe in my program is:
active heap size 7 MB = 35 MB physical memory
active heap size 9 MB = 54 MB physical memory
active heap size 16 MB = 206 MB physical memory
active heap size 20 MB = 300 MB physical memory
etc.
That's why I thought of memory leaks in the emulator. But of course this
could also be a result of memory fragmentation (can this occur?) or
garbage collection running in a separate thread (or does System.gcDo
wait for GC to finish its job?)
Thank you for your comments!
Cheers,
Filip
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
