6

I understand that there is no way to get the stack size of a thread in Java at runtime (see Can one obtain actual stack size used by a thread in Java after some time of running?).

For example, if we create a java.lang.Thread specifying a stack size of 64*1024, the JVM is free to give us a thread with any stack size.

However, I believe that actually knowing the actual size of the stack is very useful for certain applications which requires this kind of information.

What is the reason that we do not have a method which tells us the actual number of bytes used for the stack?

Is there some kind of limitation in the architecture that makes it impossible to get the actual number of bytes for a thread?

Community
  • 1
  • 1
Pacerier
  • 86,231
  • 106
  • 366
  • 634
  • 1
    "However, I believe that actually knowing the actual size of the stack is very useful for certain applications which requires this kind of information." Do you have any examples? – Mark Byers Feb 11 '12 at 21:03
  • @MarkByers For example, a web server or an OS. – Pacerier Feb 11 '12 at 21:07
  • 2
    Why would a web server need to know the stack size? – Bombe Feb 11 '12 at 21:19
  • 1
    That's an example of an application, not an example about *why* it would be useful to know that. – Greg Hewgill Feb 11 '12 at 21:19
  • @Bombe It is possible to do tuning if we have info on the actual stack size. For example if I wanted to do intense calculation, different algorithms could be selected dynamically based on the size of the stack. – Pacerier Feb 11 '12 at 21:24
  • Why does the stacks size have influence on your algorithms? Sorry, but this whole thing just doesn’t make much sense to me. Either my stuff runs, or it doesn’t. Knowing the stack size hasn’t helped me once in 15 years. – Bombe Feb 11 '12 at 21:46
  • @Bombe Because some algorithms are recursive and require a larger stack size than non-recursive ones e.g. http://stackoverflow.com/q/8342101/632951. I recognize your superiority. I was suggesting an example because you wanted a *reason*. Is there some kind of limitation in the architecture that makes it impossible to get the actual number of bytes for a thread? – Pacerier Feb 11 '12 at 21:52

1 Answers1

3

The only things that are stored on the stack are primitive types and references. Objects are always created on the heap, so the data types that would be stored on the stack are

  • Local Variables of type byte, char, int, long, float, double the longest of these are double which is 8 bytes
  • References to objects are 4 bytes on 32 bit vm, 8 bytes on 64 bit vms (possibly shorter, 48 bit references are used to save space)

Note that arrays are objects types so they are stored on the heap, also if you have a primitive that is a field in a class then the primitive is part of an object and therefore will be stored on the heap.

So its pretty hard to run out of stack space for a thread unless you have runway recursion. I would imagine that is the reason why the Java designers don't give you a way to find out the stack size.

Another reason not to give the stack size is that it would be an implementation details that you can't really do anything with, you can't change the size of a thread stack after you have created the thread, and you can't do pointer arithmetic so what the point of knowing the stack size?

ams
  • 60,316
  • 68
  • 200
  • 288
  • I'm a thread pool, I want to create 30 threads when I'm borned, each with a stack size of 64Kb. However if the JVM ignores my stack size request and creates each thread with stack size of 1Mb, then I do not wish to create 30 threads. If each thread has a stack size of 512Kb, I would instead create 15 threads. Else if each thread has a stack size of 1Mb, I would instead create 10 threads (and so on). However there's no way for me to query the stack size, and the best I can do now is to assume. – Pacerier Feb 11 '12 at 23:00
  • @Pacerier the stack size is so small relative to the heap size, therefore the issue with having more threads is not stack size of an individual thread but by the amount of heap memory used by each thread. The more threads the more heap you will probably need. What type of hardware are targeting to run your app on that you are concerned about KB of memory? – ams Feb 12 '12 at 00:00
  • am I misunderstanding something, because threads do not take up any heap memory by themselves. If I have 10 instances of MyThreadPool and each MyThreadPool has 30 threads and each thread has 1Mb stack size that is a total of 300Mb memory. On the other hand, if each thread has 64Kb stack size it would only take 18.75Mb memory. That's a huge difference even with an above-average computer – Pacerier Feb 12 '12 at 00:16
  • @Pacerier I am pointing out that each thread that you run will presumably be doing something, and whatever the thread is doing it will consume heap space along with stack space, I am assuming that the thread will consume more heap space than it will stack space in the normal course of the execution of the thread. Thus my comment that the more threads you have the more heap you will likely need. – ams Feb 12 '12 at 00:30
  • @Pacerier in the example you gave with 10 threads pools, and 30 threads per thread pool you have 300 threads which is a lot of threads, CPU and Heap will probably become an issue long before you run out of stack. Why are you so concerned about the stack size as a percentage of total memory usage. Also keep in mind that there is a difference between allocated memory and committed memory, so even if the JVM called malloc() and asked for 1MB of stack all that means is the JVM can safely do pointer arithmetic the OS won't allocate the memory until the JVM writes to it. – ams Feb 12 '12 at 00:34
  • Because in a heavily-threaded app the memory for stack is not negligible indeed. Memory is more scarce than CPU, we won't run out of CPU before we run out of memory. Since each box would probably have up to 16GB of virtual memory shared by all processes, each app should reasonably not use more than 1GB memory. 300MB memory takes away 30% of that. – Pacerier Feb 12 '12 at 01:02
  • This is actually an issue in microservices. They need to keep threads for request isolation. So there are high amount of threads, that wait 99% of the time. And all of them are consuming stack. Would be really nice to have means to analyze how much of the stack space is used. – Imaskar Jun 17 '19 at 15:12