Jump to content

Allocating more Memory for OSBot JAR


Vag

Recommended Posts

Okay, so this is going to be very easy and simple, yet useful guide.

I know, there are some other ways for this, but this is the one I found the easiest to do.

 

What you gotta do is the following

 

Step 1. Create a new folder to your Desktop etc. and name it OSBot

 

Step 2. Download the latest OSBot.jar from official OSBot website (the Download button). Rename the JAR file to OSBot.jar

 

Step 3. Open a notepad. Paste this text into it.

java -Xmx1024m -jar OSBot.jar

Save as Run.bat (ALL FILE EXTENSIONS)

 

What this text does is the following

java -Xmx1024m

Allocates a MAXIM. off 1024 megabytes of RAM memory for JVM. You can change the 1024 to 2048, etc to allocate more memory.

-jar OSBot.jar

So that Java knows that JAR-file it opens. You could also use /path/to/file/OSBot.jar, if your OSBot JAR is not located in the same file folder as the Run.bat file you just created.

Link to comment
Share on other sites

Don't. Just don't. Java will consume as much memory as it wants. More memory does not mean faster programs in general, it just means fewer GCs in theory.

Only raise memory when you need to (encountering an OutOfMemException), or you feel collections are occuring too frequently (which chances are, you need to manage your object creation better, not your memory).

For a better idea: objects will stay in heap until memory is needed. If there is still memory to be used, there is no reason to free up memory by "sweeping" dead objects. This means dead objects sit in heap until the memory they consume is actually needed. Raising the memory will do nothing but make your application a memory hog, unless it's actually needed.

  • Like 1
Link to comment
Share on other sites

Don't. Just don't. Java will consume as much memory as it wants. More memory does not mean faster programs in general, it just means fewer GCs in theory.

Only raise memory when you need to (encountering an OutOfMemException), or you feel collections are occuring too frequently (which chances are, you need to manage your object creation better, not your memory).

For a better idea: objects will stay in heap until memory is needed. If there is still memory to be used, there is no reason to free up memory by "sweeping" dead objects. This means dead objects sit in heap until the memory they consume is actually needed. Raising the memory will do nothing but make your application a memory hog, unless it's actually needed.

 

Sorry to let you down, but JVM is not allowed to consume "as much memory as it wants". If this was the case we would not meet an OutOfMemException. The maximium heap size can be configured inside the program itself, or forcing the JVM to allocate more memory by running it via batch file.

Link to comment
Share on other sites

Sorry to let you down, but JVM is not allowed to consume "as much memory as it wants". If this was the case we would not meet an OutOfMemException. The maximium heap size can be configured inside the program itself, or forcing the JVM to allocate more memory by running it via batch file.

Not sure what you mean by "we would not meet an OutOfMemoryException". I think you're misunderstanding what I'm saying.

The VM doesn't free up memory until it has to. If you give the VM more memory, it will have no need to free-up memory as much (since there's still more memory to use). This means blindly increasing the heap size will result in your application consuming more memory than it actually needs to. This is because you are allowing it to consume more memory. That is what I mean by "as much memory as it wants", whch I guess is better worded as "as much memory as it needs", although you are technically giving it more than it needs.

Long story short, yes you can specify a max heap size to allow your program to consume more memory. But this can lead to a waste of memory, since the memory you are allowing it to consume is simply more room for dead objects.

You should not increase the heap unless you have to. If you are doing so, I suggest profiling the process to see the effects it's having. This option was made available for applications that have high memory requirements.

Edited by fixthissite
  • Like 2
Link to comment
Share on other sites

Not sure what you mean by "we would not meet an OutOfMemoryException". I think you're misunderstanding what I'm saying.

The VM doesn't free up memory until it has to. If you give the VM more memory, it will have no need to free-up memory as much (since there's still more memory to use). This means blindly increasing the heap size will result in your application consuming more memory than it actually needs to. This is because you are allowing it to consume more memory. That is what I mean by "as much memory as it wants", whch I guess is better worded as "as much memory as it needs", although you are technically giving it more than it needs.

Long story short, yes you can specify a max heap size to allow your program to consume more memory. But this can lead to a waste of memory, since the memory you are allowing it to consume is simply more room for dead objects.

You should not increase the heap unless you have to. If you are doing so, I suggest profiling the process to see the effects it's having. This option was made available for applications that have high memory requirements.

 

 

Profiling the process means profiling osbot.

 

We didnt write osbot, so its pointless.

I am guessing that this is intended for people using the client, running multiple scripts.

You wouldn't want to run 8 scripts using the default heap size, it just doesn't make sense.

 

There are obviously cases where you want to increase the max heap size.

Who cares if you are "Wasting" memory by increasing the max heap size. If you have 16 or 32 gigs of ram, you wont miss 2 gigs to increase the max heap size.

Link to comment
Share on other sites

Profiling the process means profiling osbot.

We didnt write osbot, so its pointless.

I am guessing that this is intended for people using the client, running multiple scripts.

You wouldn't want to run 8 scripts using the default heap size, it just doesn't make sense.

There are obviously cases where you want to increase the max heap size.

Who cares if you are "Wasting" memory by increasing the max heap size. If you have 16 or 32 gigs of ram, you wont miss 2 gigs to increase the max heap size.

This is a general Java aspect which can be tested with any Java program, not just OSBot (testing in isolation helps achieve more percise benchmarks anyways).

Don't assume everyone has 16 to 32gb of ram. I only have 4gb. My point is, what are you gaining from increasing heap? He is telling people how to do it, and I'm sure many will blindly do this assuming it'll make their clients run "better", when really it's having no real effect (other than consuming more memory than needed).

What I'm trying to say is don't touch heap size unless you are required to. Encouraging others to do things without justifiable reason behind it will result in questions about why a script is consuming so much memory (or posts along those lines). He should at least tell people when it would be a good idea to increase the heap size.

If memory is being wasted (and there is no reason behind it), I'd most definitely care, and I would hope other devs would care as well.

Edited by fixthissite
Link to comment
Share on other sites

Profiling the process means profiling osbot.

 

We didnt write osbot, so its pointless.

I am guessing that this is intended for people using the client, running multiple scripts.

You wouldn't want to run 8 scripts using the default heap size, it just doesn't make sense.

 

There are obviously cases where you want to increase the max heap size.

Who cares if you are "Wasting" memory by increasing the max heap size. If you have 16 or 32 gigs of ram, you wont miss 2 gigs to increase the max heap size.

 

jmc with java 1.8u40 and up can give you a pretty good idea on whats going on in your script. OSBot is pretty lean to be honest, mostly its your script that ends up doing stuff that increases GCs or memory pressure. I've managed to keep my client with under 250mb (I use 300mb for a lil cushion generally) just by using jmc and seeing whats causing the memory pressure. jmc or "Java Mission Control" is built right into the JDK, so just run `jmc` or search for "Java Mission Control".

 

Note jmc can't be used with older versions than 1.8u40 due to some flags that had to be compiled into the code. Now those flags can be added after compile, via jmc.

Link to comment
Share on other sites

Sorry if I seemed a bit jumpy at first, but I've heard too mamy people recommending this without justifiable reason (basically ever since I got here). You should always give reason as to why you'd wanna to something.

To get a better idea of how memory is managed in HotSpot, check out the white paper pdf. You should not blindly increase heap. Increasing heap is usually followed by tuning generations, to ensure that memory you are giving is used efficiently.

The only reason you should touch heap is to increase the amount of bots, which at that point should be calculated based on a script's settings and set dynamically. Any other reason (such as storing a bunch of path data in memory) usually calls for a weak data structure.

Edited by fixthissite
Link to comment
Share on other sites

If you do Xmx1M I guarantee your bots will make 1M as soon as you log in.

 

If you do Xmx10M it'll be 10M.

 

And so on.

 

On a serious note:

I'd have to agree with fixthissite on this. Unless your OSBot's dying with OOM when you're running more bots, increasing the max heap size won't really help much.

 

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...