I've noticed that there is excessive generation of "nursery" garbage on minecraft 1.8.1 single player when loading new chunks into the visible range.
This causes lag when running fast, lag when loading a new map, and lag when running through portals (i.e. ender portals or nether portals.)
I have not tested for this on a client/server setup, and I have not tested this on earlier versions. If you wish I can do so.
I have verified this with various JavaVM settings including default. This is how I narrowed it to the garbage collector after memory usage patterns (rapid fluctuation of slightly less than the nursery size) indicated the issue.
The most effective command line (minus debug options) at reducing adverse affects from this is:
"-d64 -Xincgc -XX:+AggressiveOpts -XX:+UseLargePages -XX:MaxGCPauseMillis=20 -Xmx4G -Xms4G -Xmn256M"
To give a list of the functions:
-d64: Use 64bit mode (allows for 4GB of memory and higher. 32bit limit on Linux is 4GB - VM verhead or approximately 4000MB according to Oracle.)
-Xincgc: Enable secondary incraemental Garbage collector (disabled by default.) Added processor usage trade off for less dependence on primary garbage collector.
-XX:+AggressiveOpts: Do agressive optimizations in bytecode compiling, reduced processor overhead, and reduced garbage creation (by optimization out of temporaries) at the cost of possible bugs; no such bugs encountered.
-XX:+UseLargePages: Use large pages to allocate memory; reduces malloc overhead on load, reduces chance of OS swapping pages. Usually on by default, just being sure in case my distro doesn't ship a standard compile.
-XX:MaxGCPauseMillis=20: Reduces the prefered amount of time per garbage collection cycle dramatically. This is a "soft" limit, that it tries to attain. When this low, it reduces the amount of garbage collected per a cycle, and increases cycles per a minute, thus reducing thread-lock time.
-Xmx4G -Xms4G: Set maximum memory size, and initial memory size to 4GB, prevents constant allocation of deallocation of memory on the OS level, increases maximum memory to 4 times the default, to reduce the dumping of assets.
-Xmn256MB: Set the nusury size to 256MB, twice the default for Minecraft, and 4 times the default for Java. This value seems to be ideal, neither causing frequent nursury overflow (forcing agressive garbage collection) nor causing an inflation of the nursury (causing eventual garbage collection batches to be too large.)
As a disclaimer, just because these settings work on my system, doesn't mean they will work on yours. Garbage collector tuning varies on a lot of features, including core count, available memory bandwidth, available memory, available processor time, as well as your OS. I can't stress this enough, every computer is different, MY SETTINGS MAY NOT WORK FOR YOU!
More to the point, if anyone has additional tips, or could point me to a relevant bug report, if one exists, could the please help.
If I need to file a bug report myself, this is more advanced than any bug report I've filed on any project, so I'd like some pointers about what to include.
p.s. I hope I didn't go over everyone's head here. I appologize if I did, and if anyone needs some clarification, I would will gladly fill in the information that I presumed someone familiar with JVM programming would know.
This causes lag when running fast, lag when loading a new map, and lag when running through portals (i.e. ender portals or nether portals.)
I have not tested for this on a client/server setup, and I have not tested this on earlier versions. If you wish I can do so.
I have verified this with various JavaVM settings including default. This is how I narrowed it to the garbage collector after memory usage patterns (rapid fluctuation of slightly less than the nursery size) indicated the issue.
The most effective command line (minus debug options) at reducing adverse affects from this is:
"-d64 -Xincgc -XX:+AggressiveOpts -XX:+UseLargePages -XX:MaxGCPauseMillis=20 -Xmx4G -Xms4G -Xmn256M"
To give a list of the functions:
-d64: Use 64bit mode (allows for 4GB of memory and higher. 32bit limit on Linux is 4GB - VM verhead or approximately 4000MB according to Oracle.)
-Xincgc: Enable secondary incraemental Garbage collector (disabled by default.) Added processor usage trade off for less dependence on primary garbage collector.
-XX:+AggressiveOpts: Do agressive optimizations in bytecode compiling, reduced processor overhead, and reduced garbage creation (by optimization out of temporaries) at the cost of possible bugs; no such bugs encountered.
-XX:+UseLargePages: Use large pages to allocate memory; reduces malloc overhead on load, reduces chance of OS swapping pages. Usually on by default, just being sure in case my distro doesn't ship a standard compile.
-XX:MaxGCPauseMillis=20: Reduces the prefered amount of time per garbage collection cycle dramatically. This is a "soft" limit, that it tries to attain. When this low, it reduces the amount of garbage collected per a cycle, and increases cycles per a minute, thus reducing thread-lock time.
-Xmx4G -Xms4G: Set maximum memory size, and initial memory size to 4GB, prevents constant allocation of deallocation of memory on the OS level, increases maximum memory to 4 times the default, to reduce the dumping of assets.
-Xmn256MB: Set the nusury size to 256MB, twice the default for Minecraft, and 4 times the default for Java. This value seems to be ideal, neither causing frequent nursury overflow (forcing agressive garbage collection) nor causing an inflation of the nursury (causing eventual garbage collection batches to be too large.)
As a disclaimer, just because these settings work on my system, doesn't mean they will work on yours. Garbage collector tuning varies on a lot of features, including core count, available memory bandwidth, available memory, available processor time, as well as your OS. I can't stress this enough, every computer is different, MY SETTINGS MAY NOT WORK FOR YOU!
More to the point, if anyone has additional tips, or could point me to a relevant bug report, if one exists, could the please help.
If I need to file a bug report myself, this is more advanced than any bug report I've filed on any project, so I'd like some pointers about what to include.
p.s. I hope I didn't go over everyone's head here. I appologize if I did, and if anyone needs some clarification, I would will gladly fill in the information that I presumed someone familiar with JVM programming would know.