![]() The following is what I have for my JVM arguments I don't run anything other than single player survivor mode typically: To start the FTB launcher I use applescript:ĭo script "cd ~/Desktop/ftb/ export JAVA_HOME=/System/Library/Frameworks/amework/Versions/CurrentJDK/Home java -jar FTB_Launcher.jar" Java: 7 Update 45 for OS X v10.8 or higher (using runtime parameters: -Xmx3072m -Xms3072) Although I haven't gotten this to work yet, I'm sure it will be worth my while. If you're profiling a mod outside of a pack, then visualvm is a good choice.Įyamaz, Thanks for the research and time that went into this. If you're profiling a mod in a pack, visualvm is not the choice, jprofiler is. (i use a heavily modified tieredcompilation to alleviate this at the offset that it does cause stuttering for the first 5 to 10 minutes.) On much faster computers, you may not even feel the difference, but on lower end machines it can kill your performance. When a class is interpreted it runs about 9.5 times slower than a class compiled into the C2 compiler. The next largest piece of "lag" that isn't really lag is from interpreted methods. The two biggest forms if lag from java that can be adjusted is from data tenuring through the different heap spaces and "stop the world" garbage collection. Using just visualvm you can monitor memory usage and allocation as well as gc cycles. This, however, is exremelty intensive and will slow the speed of the game down considerably. If you want to get into mod specifics, you're going to need something like jprofiler8 so you can identify the individual methods that are taking up the most resources. ![]() Eyamaz has far more information and experience adjusting compiler settings than I do. Yes, it can be a pain, but it's the only way I know of to determine if it is a garbage collection issue. That gives the garbage collection details, with time stamp this lets you read the logs, look for garbage collection operations that take a long time, and see if those match up with your "This is laggy now" observations. ![]() ![]() XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -Xloggc:GC.log But really, without some baselevel comparisons, that's not of much use unless "it just works" - for that, you need to read logs. Try adding -XX:+UseConcMarkSweepGC and see if there are any improvements. (If it happens in single player only, it may be rendering if it happens in SMP only, it's in the tick handling side.)īeyond that, something that causes tick spikes sometimes in mods, but not vanilla? Very possibly the garbage collection. If you are not generating new chunks, then it's a little less clear.ĭoes it happen both when you are a single player game, and when you connect to an SMP server on the local machine? An SMP server won't pause the tick speed for client rendering issues, so if it happens in one and not the other, that's something to look for. If you are running into this issue in areas where you are generating new chunks, I've found that both COG and UB are pains in 164 when they were very nice and happy in 152. ![]()
0 Comments
Leave a Reply. |