Would 16GB of RAM help?
- Thread starter Recon
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
I think I read somewhere that it defaults to 3 unless otherwise specified. *shrugs*
My setup was found on this very forum I think, I just forget where.
Wow, y'all... and people wonder why we Windows developers hate Java so much.
Many thanks for giving me parameters I can paste into my game though!
The setup applies even if you're running the game on Linux, etc. So the hate for java may be OS-independent.
I still urge you to set up a separate SMP server on the same computer though, as opposed to using SSP. I personally don't encourage hosting the server on the same computer, but I still think that's better than using SSP. Lol.
Well, I can try it again. I know it was horrible how long it took to load when I did that before. The biggest problem is that I was actually logged in for about 30 seconds BEFORE the game came up. That means my character was on the server, frozen, until my client decided to give me control. Typically the most frustrating way this went down is that I would be out caving or wandering around at night, and get in a fight with some mobs, then the game would crash. If I logged back on, the mobs would kick my ass for 30 seconds likely killing me BEFORE I could even respond. So then, all my valuable items get spilled on the ground in the middle of nowhere and I have 5 minutes to try and recover them before they despawn. What a pain in the ass that was to go through many times. I even got in the habit of setting an alarm to go off 10 minutes after the crash so I could log back on in daytime and not get attacked when trying to load.
Hopefully it won't do that this time. Plus with the new JVM stuff I'm using the game seems MUCH more stable now. I've been playing it for hours without a single crash, and I got Sphax textures plus about 110 mods running just fine.
Hopefully it won't do that this time. Plus with the new JVM stuff I'm using the game seems MUCH more stable now. I've been playing it for hours without a single crash, and I got Sphax textures plus about 110 mods running just fine.
Well if it's working fine for you now, then just keep it as it is. I would feel bad if you got your a$$ handed to you due to lag. Lol.
Do you have any spare machines that is capable of hosting a local server? My personal FTB server is hosted on a really shitty 2ghz Core Duo laptop and it works fine. Lol. I just have 1 GB allocated to FTB out of 3GB ram total, server is placed on a 700mb ramdisk, with the remaining ram left as overhead for Java (i.e., the XMX setting isn't a hard cap, and you can still sometimes see that it exceeds the amount of RAM you limit it to, which is why you need some overhead to prevent swapping with the HDD) and the laptop's OS (Lubuntu).
You may also consider stuff like TickThreading under the server admin area which apparently drastically helps with parallel tick processing, etc.
I only ever recommend running a server and client on the same computer if you have a multicore processor. After you start the server, set its affinity to your odd number cores. once you load your client (to the title screen, not just the launcher) set its affinity to the even number cores. its not always a guaranteed lag prevention, but it can help. also ad NOGUI to the very end of the startup file for your server, after the .jar.
I did the affinity trick when I ran SMP, and it helped a LOT. I used 0-3 for the server and 4-7 for the client. Then when the client inevitably crashed, I'd start it back up and immediately set the affinity to the newest java process to 4-7. <javarant>Why on earth can't the processes be named something other than java.exe? How retarded </javarant>
Ramdisk loads the game slightly faster. it doesnt effect game rendering, but some people it magically helped. servers yes its always good to have it in ram. An SSD is fine too with 10 people. youd need a couple dozen for a ramdisk to really make a significant difference unless it was a terrible SSD. However if you have the ram its slightly better even with 2 people I guess.
Wow, y'all... and people wonder why we Windows developers hate Java so much.
All those options should not even have to be specified. Heck, people just add crap they found on stackoverflow to their options without even knowing what the problem is.
There are simply two reasons Java can run out of permgen space:
- The application really uses more classes than the default space can contain (unlikely)
- There is a memoryleak because some part of the software does funky classloading shit.
It's easy enough to see which of the two is the case:
- Does your application crash during startup or soon after: you don't have enough permgen space.
- Does it crash after a while: you have a memory leak.
Unfortunately FTB is just adding more and more mods without any regards of the quality of the code. With more mods, especially ones added by java amateurs, the chances of mistakes increase. And because a lot of them think "Garbage collection means I don't have to worry about disposing my crap" the chances of bugs are high.
I also find it rather funny people are messing with garbage collector options when there are memory leaks. The whole problem with memory leaks is that the memory is not being marked as 'free'. No matter how many threads you assign to the GC (4, really?), the GC will never ever touch that memory simply because it's not free.
Also trying to use JRockit instead of the default VM doesn't do anything. Just because JRockit doesn't have a separate permgen space it doesn't mean you won't get an out of memory error. It will just complain it runs out of heap space instead of permgen space.
From my personal experience, running out of permgen space due to class loading is indeed the issue and modpacks indeed crash directly on startup. There generally are no memory leaks in stable mod versions. In fact, I can't recall a single one since switching to 1.5.x. Your mileage may vary, of course, since you might play different mods/modpacks.
Also, using JRockit doesn't improve performance because of permgen memory management, but because JRockit is significantly more responsive and lower latency in actually processing stuff.
Also, using JRockit doesn't improve performance because of permgen memory management, but because JRockit is significantly more responsive and lower latency in actually processing stuff.
using jrocket is moot. as of java7/8, jrockit and hotspot are slowly being merged into a single JVM.
apparently you dont know how java memory allocation works. you can't "dispose of your crap" manually in java. java doesnt allow you to allocate memory space like you must do in Cpp/# or other compiled languages, therefore there is no way to "dispose" of it. this is the SOLE PURPOSE of the GC.
Having worked as a professional Java dev for 15 years I can say I know damn well what you do and do not need to do. It's very possible to create memory leaks in Java, especially when low level stuff is involved.
There's still a tangible difference between Java 7 and JRockit. But yes, Java 8 aims to integrate all those improvements into the vanilla JVM anyone can get. It'll be awesome for the Minecraft community
Too bad they pushed it back till 2014.
get the prerelease of u40. it lacks several security patches as of this moment, but u26 - u40 have had several performance enhancements.
DISCLAIMER:i dont ever recommend a prerelease of java for general use as they do not have necessary security patches to help protect the end-user.
DISCLAIMER:i dont ever recommend a prerelease of java for general use as they do not have necessary security patches to help protect the end-user.
I never refuted the ability to create memory leaks. i refuted that, with most things in java, you cant just dispose of what you create. once an object is created, the programer has no real control over when it gets unloaded. java does this. so if you've been a java programer for 15 years, why would you even come down on a modder (even amateur) for thinking "i don't have to dispose of my crap," when that is one of the fundamental aspects of how java works.
sorry if i missed something important, ive only been into java for less than a year, but i have over 20 years in c/cpp. the way java does some things appalls to my better senses.
It's a dangerous thinking. First of all; many beginning programmers forget to actually unreference stuff they don't need anymore. They simply 'keep' objects that they no longer need. I've seen plenty of nested-hashtable-hells where the developer had no idea what he was doing. And especially when people think they don't need to care about it, they don't.
Just like in C++ where you need to dispose stuff, you need to unreference things you don't need anymore.
Aside from that: you still need to make sure to clean up after yourself when using stuff likes files and connections. There are loads of developers that 'forget' to .close() a file stream and then you're going into 'undefined' territory where what happens totally depends on the VM implementation and the OS you're running on.