A lot of the above is speculation. The salient observation is when
scrolling, resizing or opening windows, the memory used as indicated
by the Windows 7 Process Monitor (see below) continues to climb and
never releases the additional memory used.
The in-memory tile cache uses SoftReferences for holding tiles. The
expected behavior is for the heap to be filled when using modules with
sufficiently large images; after that, some SoftReferences are
reclaimed to free up memory as needed. The memory usage shown in your
screenshot isn’t unexpected, or even that high—that’s only 205MB.
I think you’re seeing some other kind of problem. I’ll need more
details about what eaxctly you’re doing.
Well, the number never drops. Here it is after playing along further,
consuming 1.5GB and 79% of my physical memory. At this point, the
module is basically “locked-up”, many windows not repainting themselves,
pieces not selectable and so on.
To what are you setting your max heap for this module? I suspect that
you’re setting it far, far too high.
Perhaps I am… I didn’t know you could set the heap too high - I have it set to 1550 in the module, which is the maximum that VASSAL will allow me to set it to without giving me an error (see my P.S. below). I do see that the 1550 MB is about where the java.exe memory usage is limiting.
I still am curious why the old version of VASSAL 3.2 limited to a lower memory usage. (… ahh, just checked and I see, when I reinstall the older version, the heap limit is reset to only 512 MB.)
Anyhow, I’ve backed it off to 750 MB (is that a good setting?) in build 8186 and I’ll see how it goes this evening in my playtest. Thanks for the help J.
-Mark R.
P.S.
I have to admit the whole Heap thing has me confused - I’ve searched a number of times in the past for info on how and why to set it, but have never found a good explanation. I don’t really understand what it does or the difference between the JVM Heap settings found in the VASSAL module selection window and the JVM Heap settings in the module itself. Below is an example from the User’s Manual. From this explanation I can’t figure out what the heap is, whether to set it, why I might want to set it or what to base it’s settings on if I do set it. So, I figured it couldn’t hurt to just max it out (looks like I was wrong on that ).
JVM Initial Heap Size (in MB): Initial heap size of the Java Virtual Machine in megabytes.
JVM Maximum Heap Size (in MB): Maximum heap size of the Java Virtual Machine, in megabytes.
To what are you setting your max heap for this module? I suspect that
you’re setting it far, far too high.
Perhaps I am… I didn’t know you could set the heap too high - I have
it set to 1550 in the module, which is the maximum that VASSAL will
allow me to set it to without giving me an error (see my P.S. below). I
do see that the 1550 MB is about where the java.exe memory usage is
limiting.
I have seen only one module which needs more than 512MB with 3.2. 1550MB
is indeed far, far too much.
Here’s an explanation of the design: The in-memory tile cache has not
changed from 3.1. What has changed is that (1) there is now an on-disk
cache of pre-computed tiles at power-of-two scale factors (1, 1/2, 1/4,
etc.), (2) when we need tiles which fall between the pre-computed ones,
we calculate them on the fly from the nearest pre-precomputed ones
instead of from the full-size ones, and (3) we no longer load full map
images. The combination of these three things means that we don’t put
nearly so much pressure on the in-memory tile cache in 3.2. It’s quite
possible that a module which required a 1000MB heap in 3.1 now runs
with only 512MB heap or less, and scrolls and zooms more smoothly in
addition.
Due to the way the in-memory tile cache works, it will fill up the
heap space you allocate to Java. This isn’t a problem, so long as you
set a reasonable max heap. With 3.2, the advice we always used to give
people about increasing their max heaps when things don’t work is no
longer applicable. What I advise now is to leave it at the default
setting unless you’re getting an OutOfMemoryException, of you can see
that the tile cache is thrashing (i.e., tiles are being evicted right
after being painted).
Okay, thanks for that. I will set the heap to 512 (the default, I think) and see how that goes this evening.
Indeed, it’s the tiling improvements of 3.2 that even allows my module to exist. Due to it’s rather massive map-size, it would never run in 3.1 and I wouldn’t have started the project without the prospect of 3.2 tiling on the horizon. So, thanks for that!!
I have to admit the whole Heap thing has me confused - I’ve searched a
number of times in the past for info on how and why to set it, but have
never found a good explanation. I don’t really understand what it does
or the difference between the JVM Heap settings found in the VASSAL
module selection window and the JVM Heap settings in the module itself.
The heap is the chunk of memory used by a particular instance of Java.
A program running in a JVM will not use more memory than the maximum
heap size set for its JVM. The idea is that this is a security feature,
and it may be useful in some settings, but in actuality it is quite a
nuisance for desktop applications, because the heap cannot be expanded
once the JVM is running and also because it tosses memory management
into the lap of the user. (We have tens of thousands of lines of code
that we would not need to have if not for heap sizing. Thankfully, none
of this will be necesary with V4.)
The Module Manager and each Player are distinct processes, running in
different JVMs. Each JVM has it’s own heap. The heap settings you see
in the Module Manager are in the “Importer” tab, and determine the heap
size which will be used for converting a module from an external format
(such as ADC2). The Module Manager itself uses Java’s default heap
settings, and it’s unlikely that you would ever need to adjust that. The
heap settings you see in the preferences for each module apply to the
Player in which you load that module.
Below is an example from the User’s Manual. From this explanation I
can’t figure out what the heap is, whether to set it, why I might want
to set it or what to base it’s settings on if I do set it. So, I
figured it couldn’t hurt to just max it out (looks like I was wrong on
that ).
_
JVM Initial Heap Size (in MB): Initial heap size of the Java Virtual
Machine in megabytes.
JVM Maximum Heap Size (in MB): Maximum heap size of the Java Virtual
Machine, in megabytes._
Someone should add an explanation of what these mean.
I see. Thanks for taking the time to explain and I generally understand (I’m an electrical engineer with a pile of software experience, but I’ve never used Java and didn’t understand how java handled memory management or how VASSAL/java was using the heap settings.)
At first I figured it was just my in-progress module for Space Empires Close Encounters, but it happens in the older, 3.1.19 version of Space Empires that I released a few months back and in Band of Brothers, a module I did not make.
So maybe it’s not just me.
In the second image the MOVED icon still appears on the piece when it is moved as normal, despite the error.
The error seems to occur when either I open a piece property window from the editor or if I select a piece from the palette in either the editor or in game mode.
Played for over four hours with three players and not a single issue to be had; and that’s a first - so our issues were clearly related to oversizing the Heap. Thanks!
I haven’t had any major issues. I do get the “moved.gif” not found
error message pretty often but I think that is my fault.
Can you show me a module where that happens for you?
–
J.
At first I figured it was just my in-progress module for Space Empires
Close Encounters, but it happens in the older, 3.1.19 version of Space
Empires that I released a few months back and in Band of Brothers, a
module I did not make.
So maybe it’s not just me.
[1]
[2]
[3]
In the second image the MOVED icon still appears on the piece when it is
moved as normal, despite the error.
The error seems to occur when either I open a piece property window from
the editor or if I select a piece from the palette in either the editor
or in game mode.
The problem here is that VASSAL originally tacked “.gif” onto
extensionless image names, which was a poor design decision and one
which I’ve been trying to correct for several versions now. Apparently
I haven’t yet succeeded. I’ll try to track down tomorrow the reason my
last fix isn’t catching this case.
Great, thanks I was actually about to bring it back up again. It doesn’t appear to be a show stopper in any way but it is an error message that might confuse some players.
I’m seeing a problem with counters not centering properly. (I seem to recall this cropped up some time ago, and was generally resolved.) Exists on beta-1 and on svn8230.
Everything’s fine in the various existing modules I’ve seen, but I started a new one, put in a map, defined the hex grid… and the counters are snapping to a position that’s a bit high and off to the left.
You can check out the module here. Just start a new game, pick the first map choice, and fiddle with the counters from the Ships menu.
Joel, a few things I noticed that you might want to have fixed before 3.2.0 official release (this was using build 8255, possibly #1 already in 3.1.x):
Trying to start a game in online mode will abort with a unknown type bug when the server is unreachable (no Internet)
Starting a game by mistake in the game lobby (as opposed to opening a dedicated room first) now correctly gives a warning that it is not the right place to do it, but the game still starts (at least on the local computer)
When a second player enter the room synchronization starts automatically (nice) but it immediately says “Synchronization complete”, whereas
…a) on the “host” computer “sending data to …” appears somewhat later
…b) but the host never receives a “finished sending data to …” type of message
…c) some more time (minutes in MH case) need to go by before the actual “choose side” prompt finally appears for the remote computer
Therefore, I wonder: what if the host starts moving pieces around before the sending data actually finishes? Or does synchronization really take nanoseconds and the slownes mentioned above is just the normal game starting slowness for bulky modules (like MH)? Will it automatically resynchronize on the remote computer even if he still has to go through the side selection prompt?
Joel, a few things I noticed that you might want to have fixed before
3.2.0 official release (this was using build 8255, possibly #1 already in
3.1.x):
Trying to start a game in online mode will abort with a unknown type bug
when the server is unreachable (no Internet)
Starting a game by mistake in the game lobby (as opposed to opening a
dedicated room first) now correctly gives a warning that it is not the right
place to do it, but the game still starts (at least on the local
computer)
When a second player enter the room synchronization starts automatically
(nice) but it immediately says “Synchronization complete”, whereas
…a) on the “host” computer “sending data to …” appears somewhat later
…b) but the host never receives a “finished sending data to …” type of
message
…c) some more time (minutes in MH case) need to go by before the actual
“choose side” prompt finally appears for the remote computer
Therefore, I wonder: what if the host starts moving pieces around before the
sending data actually finishes? Or does synchronization really take
nanoseconds and the slownes mentioned above is just the normal game starting
slowness for bulky modules (like MH)? Will it automatically resynchronize on
the remote computer even if he still has to go through the side selection
prompt?
I’m seeing a problem with counters not centering properly. (I seem to
recall this cropped up some time ago, and was generally resolved.)
Exists on beta-1 and on svn8230.
Everything’s fine in the various existing modules I’ve seen, but I
started a new one, put in a map, defined the hex grid… and the
counters are snapping to a position that’s a bit high and off to the
left.
You can check out the module here[1]. Just start a new game, pick the
first map choice, and fiddle with the counters from the Ships menu.
Yes, something isn’t quite right here. When I turn on hex grid drawing,
the centers look dead-on, so it’s not the hex grid that’s misalligned.
But, I see the same thing with your module and 3.1.20-svn8251, which
makes me think this is either an old problem, or is a problem with the
module.
).