Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I wrote some simple tree/graph algorithms, but quickly ran into a lot of StackOverflowError exceptions with some pretty small data. It turns out the stack is 8KB by default on my Samsung Galaxy S3, which has 2GB of RAM. My computer 10 years ago had a 1MB stack. The Linux machine machine I'm using right now has 4GB RAM. My phone's RAM is only half the size of my computer's RAM, yet my phone's stack is over 1000 times smaller. Why?
What is the actual technical reason that the developers of Android had to limit the stack much more than other operating systems? E.g is it because some Android devices have a small amount of RAM like 1MB or 10MB? I haven't surveyed the range of devices, but I find it hard to believe that any device would be so small.
Just create a Thread with the stack size you want and run your code in it.
I believe that the default one of 8KB is due to the fact that it is most probably allocated on the heap, and a 32-bit architecture does not have a lot of VRAM to waste on it (with a 2GB memory split it's only 2GB per process available). Allocating a big stack would permanently take it out of the available VRAM of the process. This is different from the traditional native processes where the stack grows from top to bottom while the heap grows from the bottom to the top.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Context
Hi All,
I'm running a program called Firstrate 5 for work - its a simple java program to calculate thermal performance for buildings. After inputting a model the user presses Calculate and it computes the results. Some models are complex, and take in the order of minutes to calculate, which often as part of an iterative process is very time consuming. I had it on good authority that it was likely my old HDD slowing things down. It was time for an upgrade anyway, so I splashed out on a new computer with a SSD, faster CPU, 2x RAM. I was excited to see the performance improvement, so I decided to compare the time required to calculate the same model on my new an old machines. Lo and behold they both take exactly 3:15 seconds to calculate.
Question
What possible explanations are there for a java program to exhibit equivalent performance on a faster machine? Is this likely something to do with the way the software is coded, or could there be an equivalently sized hardware bottleneck on both systems? Does it have anything to do with the JRE? My main goal is to make the process faster, so any education or pointers you can give me may help me find a solution.
Old specs - (Toshiba Laptop Satellite L50-C) , Windows 10
CPU = Intel i7-5500U, 2 Cores #2.4GHz
RAM = 8GB (DDR3, 1600 MHz)
HDD = 5400 RPM
CPU usage during calculation ~ 54%
HDD usage during calculation ~ 20%
RAM usage during calculation ~ 53%
New specs - (PC Build), Windows 10
CPU = AMD Ryzen 5 2600X, 6 Cores #3.6 GHz
RAM = 16GB (DDR 4 2400 MHz)
SSD (Samsung 860 EVO)
CPU usage during calculation = 9.7%
HDD usage during calculation = 19%
RAM usage during calculation ~ 0%
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I've written a simple program in two different languages, and the result has astonished me!
My application is a simple program (Hello world!).
The C-Sharp program took about 3 MB of RAM, but in Java-FX it was about 78 MB.
Is Java really using that much memory?!
Is there a way to reduce the amount of memory?
Depending on the version of the java virtual machine, the default initial heap size is a reasonable minimum, varies by platform, and can be set at startup. So yes, you can reduce it.
About changing the size and more details: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc-ergonomics.html
About the default heap size: How is the default java heap size determined?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Correct me if I'm wrong, but in the C/C++ heap has no limit, you do not need to pass any argument to increase it.
So why java has a limit on the heap?
There are several reasons:
first you have the minimum heap size, which is there to prevent slow startup
the max heap size is there so that the GC knows when to start doing it's job, without it it would be much harder (but doable, you would just need to take into account different heuristics like number of allocations etc.)
the max heap size also prevents the JVM from hogging all the resources on the machine, which can be a really good thing
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In my experience, a C program that uses around 10 megabytes of resident memory may use around 40 to 50 MB when translated into Java, and around 100 in Clojure or Scala. My question is whether this JVM memory overhead scales linearly; if the C version used 1 gigabyte, would the Java version require 4 GB? Or is the JVM memory overhead more a constant factor, such that the 1 GB C program might only use 1.5 GB in Java?
I'm aware that I could benchmark this, but I think hearing people's experience regarding JVM memory use in production would be more informative than an artificial benchmark, which could be skewed to favour either result depending on how it was designed.
The overhead is about 10MB + 4xC-memory.
The 10MB is the JVM without anything. Java 7 64bit version uses about this much.
The 4x memory is obviously a "guesstimate" because it depends on which data types you use. If you use 100% references in java they take up about 4 times as much memory. The same difference there is between int and Integer.
If there are a lot of malloc/new in your C code there will be that in Java too, and Java's GC might not run when you want it to, so there's also an overhead of "dead references not yet cleaned up" that depends greatly on things out of your control (GC timing).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I run a mine craft server on a 32 bit Ubuntu system if I upgrade to64 bit what is the max memory I can give to java? I want it to have about 12 gig of ram but I can't do that on 32bit
There is effectively no maximum in the amount of ram a 64-bit system can address. You will be stopped only by your computer's hardware. I don't think java has a max amount of alloted RAM, either, provided you use the right switch in the command.
http://en.wikipedia.org/wiki/64-bit
Just to be clear, "hardware" includes paging / swap space, so if you actually require 12GB and only have 8GB of RAM, you'll need to be sure to have 4GB of spare swap space in order for Java to allocate additional memory successfully.
From the Java Tuning white paper:
For a 32-bit process model, the maximum virtual address size of the process is typically 4 GB, though some operating systems limit this to 2 GB or 3 GB. The maximum heap size is typically -Xmx3800m (1600m) for 2 GB limits), though the actual limitation is application dependent. For 64-bit process models, the maximum is essentially unlimited.
But truth is, such a huge heap memory usage (12GB) is counterproductive. After running for a long time, the time your application spends doing garbage collection will negate the effect of having so much memory available.