3 ms·
As in write to each requested memory location to guarantee physical allocation? No, that would be really slow. It’s not like heap memory where you probably want
by CraigJPerry 4y ago
As in write to each requested memory location to guarantee physical allocation? No, that would be really slow. It’s not like heap memory where you probably want to memset it first, with stack you have a stack pointer so you know whats been written by you and what’s random garbage.
Java just requests the memory and linux just smirks and always says “yes sure, whatever you need” - it can do that even while the OOM killer is trying to decide which process looks like it has completed the most useful work so far :-)
TLB entries dont really come into it (the size isnt an issue from our stack usage but even if it were, we could use larger pages).
TLB flushes could be an issue with that many threads floating around but that’s a different story and not really a memory usage so much as a performance and latency issue.
- chrisseaton 4y ago> As in write to each requested memory location to guarantee physical allocation? No you use the advisory bits when you map the memory. It does this so it isn't unable to commit more memory while trying to handle an exception. > Java just requests the memory and linux just smirks and always says “yes sure, whatever you need” Linux doesn't ignore even LOCKED does it? And it certainly can't ignore actual writes to pages, which is what for example pretouch_memory does.
- CraigJPerry 4y ago>> No you use the advisory bits when you map the memory. Is that really what’s happening when we create another thread? That doesn’t fit with my understanding here. When i create a new thread, i expect its stack to be allocated before the break so mlock wouldn’t come into it. Even on a jvm with Xms smaller than Xmx (i.e. so the jvm could have to request to move the break and grow the heap to accomodate my new threads private jvm stack), I’m expecting you would have to explicitly request this behaviour somehow (because it’s quite unneighbourly and probably counter productive for most apps). I don’t know how you would do that, maybe there’s a call available under the unsafe packages? I’m conscious I’m saying the jvm - i mean hotspot. >> so it isn't unable to commit more memory while trying to handle an exception Again this doesn’t fit with my understanding - you can receive a further OOME while handling an exception and that’s just bad luck. >> Linux doesn't ignore even LOCKED does it? And it certainly can't ignore actual writes to pages Sure but I’m going on the expectation that doesn’t apply here
- chrisseaton 4y ago> When i create a new thread, i expect its stack to be allocated before the break Why? Stacks are just memory like any other. You can put them wherever you want. > so the jvm could have to request to move the break and grow the heap The JVM allocates heap space using mmap, not by moving the break. > you can receive a further OOME while handling an exception and that’s just bad luck If you're being reasonable you don't - the JVM maintains emergency heap storage (pre-committed!) space so it can keep allocating even when out-of-memory.
- CraigJPerry 4y agoP.s is that you up ticking all my comments? Now i feel un-neighbourly not having done it back… fixing now