Hello. I just found out about this thread. I'm the guy responsible for those slightly out-of-date J6 memory settings recommended on the Mystcraft wiki for lower-end machines, as well as the guy tending to the minecraft forum version at
http://www.minecraftforum.net/topic.../page__st__120__gopid__24958185#entry24958185 -- and yes, my focus is on lowering memory usage in smaller modpack setups.
I'll expand a bit more since I'm here (ish) now. There are basically two types of blocks in minecraft. SimpleBlocks and TileEntities.
...
In SSP, the client technically does all the work. Both client and server calculations are done in a single MC thread and slow it down. -- snip --
It's my understanding that minecraft now has two threads even in "single player" -- that the server thread, and the GUI thread, are now separate, and that this was the whole 1.3.2 update mess.
Based on that, the effect of tile entities in SSP should be similar to the effect in a client/server setup, _if you are running both on the same machine_!
If you have some spare cores, this basically doubles the performance (client and server both get their own core, more-or-less). If you have a low-end machine, then yes, the same machine has to do both server calculations, and rendering calculations, and tile entities will increase the sever calculations.
A bit of feedback concerning your argument selection.
I have a dedicated SMP server for the world and my client running on the same machine. I am using your arguments on both the client and the server (16 GB system memory ought to be more than enough for everything). During normal gameplay, the server sits at 1 GB memory and the client at 2 GB in the task manager process view.
... but I discovered that going through a nether portal a lot is memory leaky for whatever reason. -- snip --
You aren't the only one to find nether portals _USUALLY_ leaky.
Nether portals,
Disconnecting/reconnecting to servers
Closing and reloading single player saves
All of these cost memory.
I don't know why the leak is there. I've even tried forcing the "soft reference" cleanup parameter down to zero (there is a documented bug that it can cause memory leaks and out-of-memory issues when it works perfectly as designed.) But yes, it does mean having to restart the client occasionally.
There are a few arguments that I want to add to the recommendations in this thread, if you are at all serious about tracking memory usage and needs:
-XX:+PrintGCDateStamps \
-XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \
-XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \
Optional:
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=10M \
What these do: Log your system's use of memory to a file. The "optionals" are recommended if you have a long-lived server, and are not needed for the client.
What the key data will look like:
Code:
Heap after GC invocations=1426 (full 23):
par new generation total 53248K, used 1409K [0000000007010000, 000000000be10000, 000000000be10000)
eden space 26624K, 0% used [0000000007010000, 0000000007010000, 0000000008a10000)
from space 26624K, 5% used [0000000008a10000, 0000000008b707c8, 000000000a410000)
to space 26624K, 0% used [000000000a410000, 000000000a410000, 000000000be10000)
concurrent mark-sweep generation total 123940K, used 79686K [000000000be10000, 0000000013719000, 0000000021e10000)
concurrent-mark-sweep perm gen total 41312K, used 32568K [0000000021e10000, 0000000024668000, 000000002b410000)
}
Note that in this case, the server is using tenured space of just under 80MB, out of about 123MB allocated (it was reset after yesterday's session, so this is just idle sitting there waiting for the first player since restarting). Also note that the code space is 32 MB used out of 41 MB allocated -- I use a much, MUCH smaller modpack than FTB.
But if you want to know how much space to allocate, you have to be able to track the actual usage, and you have to log the data to tell what you are actually using.
Client side, I see very different numbers -- here is from something running under magic launcher last night:
Code:
2013-10-13T00:00:03.539-0700: 723.479: [GC 723.479: [ParNew
Desired survivor size 28311552 bytes, new threshold 8 (max 8)
- age 1: 193488 bytes, 193488 total
- age 2: 416616 bytes, 610104 total
- age 3: 953168 bytes, 1563272 total
- age 4: 142680 bytes, 1705952 total
- age 5: 102096 bytes, 1808048 total
- age 6: 59456 bytes, 1867504 total
- age 7: 85616 bytes, 1953120 total
- age 8: 33024 bytes, 1986144 total
: 45041K->2356K(92160K), 0.0091470 secs] 290388K->247729K(378880K), 0.0092098 secs] [Times: user=0.02 sys=0.01, real=0.01 secs]
Heap after GC invocations=300 (full 9):
par new generation total 92160K, used 2356K [7e1e00000, 7e9600000, 7e9600000)
eden space 61440K, 0% used [7e1e00000, 7e1e00000, 7e5a00000)
from space 30720K, 7% used [7e7800000, 7e7a4d078, 7e9600000)
to space 30720K, 0% used [7e5a00000, 7e5a00000, 7e7800000)
concurrent mark-sweep generation total 286720K, used 245373K [7e9600000, 7fae00000, 7fae00000)
concurrent-mark-sweep perm gen total 83968K, used 71189K [7fae00000, 800000000, 800000000)
}
2013-10-13T00:00:03.549-0700: 723.488: [GC [1 CMS-initial-mark: 245373K(286720K)] 247729K(378880K), 0.0017413 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
2013-10-13T00:00:03.551-0700: 723.490: [CMS-concurrent-mark-start]
2013-10-13T00:00:03.675-0700: 723.614: [CMS-concurrent-mark: 0.123/0.124 secs] [Times: user=0.26 sys=0.00, real=0.12 secs]
2013-10-13T00:00:03.675-0700: 723.614: [CMS-concurrent-preclean-start]
2013-10-13T00:00:03.676-0700: 723.616: [CMS-concurrent-preclean: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2013-10-13T00:00:03.676-0700: 723.616: [GC[YG occupancy: 2625 K (92160 K)]723.616: [Rescan (parallel) , 0.0009740 secs]723.617: [weak refs processing, 0.0002759 secs]723.617: [class unloading, 0.0106787 secs]723.628: [scrub symbol & string tables, 0.0060800 secs] [1 CMS-remark: 245373K(286720K)] 247999K(378880K), 0.0209779 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
2013-10-13T00:00:03.697-0700: 723.637: [CMS-concurrent-sweep-start]
2013-10-13T00:00:03.786-0700: 723.726: [CMS-concurrent-sweep: 0.089/0.089 secs] [Times: user=0.09 sys=0.01, real=0.09 secs]
2013-10-13T00:00:03.786-0700: 723.726: [CMS-concurrent-reset-start]
2013-10-13T00:00:03.787-0700: 723.727: [CMS-concurrent-reset: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
par new generation total 92160K, used 4506K [7e1e00000, 7e9600000, 7e9600000)
eden space 61440K, 3% used [7e1e00000, 7e2019910, 7e5a00000)
from space 30720K, 7% used [7e7800000, 7e7a4d078, 7e9600000)
to space 30720K, 0% used [7e5a00000, 7e5a00000, 7e7800000)
concurrent mark-sweep generation total 286720K, used 163029K [7e9600000, 7fae00000, 7fae00000)
concurrent-mark-sweep perm gen total 83968K, used 70860K [7fae00000, 800000000, 800000000)
That's a lot of information. It starts with a dump of "how much memory is used by temporary data of a given age" -- that's controlled by the XX:MaxTenuringThreshold option. It then reports that 245 MB of long-term data (aka "tenured") data is stored. It then does a full CMS collection, and after that, only 160 MB of long-term data is used -- so about 80 MB of junk was sitting around. (It also happens to be when I shut down -- that final report is the "end of program" memory dump). Note that the client has a lot more code in the perm gen.
While Evamaz is correct in pointing out that permspace (for code) and heap space (for data) are separate, it's also important to keep track of Tenured, Eden, and Survivor -- especially when using CMS. You absolutely do not want survivor overflows to be common. Too much space in Tenured is just a waste. Putting more space in Eden reduces the rate of minor collections, letting more temporary stuff die off and not be tenured, reducing the need to do major collections -- but costing more system resources at the same time.
Permanent Generation – This contains non-compiled classes/methods
CodeCache – This contains compiled classes/methods
I use J6 (not 7), and have not seen any reference to CodeCache in the docs I can find. As far as I can tell, J6 puts even compiled code into the permgen.
Apple did/does maintain java 6 for the macs; primarily, they have this arrangement (As far as I can tell from official docs/press releases) so that Java apps can have a Macintosh look-and-feel, instead of a "partially Microsoft windows look-and-feel" (and no, java programs on Microsoft windows do not behave like native programs on Microsoft windows -- close, but not the same.) Java 7, however, is straight Oracle code, not given any Apple alterations.
Last time I checked, Macintosh's, Minecraft, and Java 7 was a broken combination.
I'm a week late, but thought I'd mention that Oracle does indeed support OSX for java 7, I currently am using 7u40 on OSX 10.8.5 with minecraft
10.7.5 here. Waiting for 10.9 to get the kinks worked out. Glad to know that this issue is resolved in the future.
-XX:SoftRefLRUPolicyMSPerMB=2048 once again. this is a TIME in MILLISECONDS and is set to TWICE the default value (1000) which will actually slow down your server once it gets "busy" THIS SHOULD STAY AT 1000.
CAUTION! If this value is non-zero you can get a memory leak.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6912889
Documents how, when this parameter works as described, memory leaks and is not collected.
Your comments on tiered compilation are interesting. I'd love to see those docs and your current test recommendations.
ermSize=1024m -XX:+TieredCompilation -XX:ReservedCodeCacheSize=2048m -XX:+UseCodeCacheFlushing -XX:CompileThreshold=1000 -Xms512m -Xmx2048m -jar MultiMCLauncher.jar "totte1015" "0d5cc1419bc64cce903e5711fa38d689" "MultiMC: Unleashed" "854x480" "Mojang"
