I know that Java uses a controlled mechanism to allow threads to be paused. If I understood correctly, they put a read from a protected page at the end of e.g. loops, and change the protection of that page if they want the thread to be paused.

What I don't understand is why this is necessary and whether this can even work. The only reason I can think of to make this necessary is that you don't have to have all pointers on the heap, and you can also just have them in registers. However, if you'd use the TSS, wouldn't you have the same data too?

However, what I find more interesting is how they handle system calls. What happens when the thread is doing a slow read of a file over e.g. a network? Does the GC way? Does the GC forgo a run and try again a moment later? What happens when the system call takes very long?

  • System calls are easy: when you're in a system call you aren't modifying the state of the Java world. You just need to have whatever objects you're using pinned (which is something that has to happen in any JNI call). – kdgregory Jun 13 '14 at 17:26
  • As for specific mechanism for JIT-compiled code (because suspending an interpreter is also trivial), I suspect that depends on specific version of the JVM. All of which begs the question: why does this matter to you? If it's just interest, I'd suggest reading the source. – kdgregory Jun 13 '14 at 17:27
  • I'd like to know because I'm writing a JIT and GC for a hoby project. Anyway, this means that the advantage would be that you don't have to keep all pointers on the stack and you can temporarily keep them just in registers. Is that a fair conclusion? – Pieter van Ginkel Jun 13 '14 at 18:02
  • If I interpret your question correctly, you're asking whether having specific sync points inside JIT-compiled code will allow you to put object pointers in registers while you're in that code. If that's correct, then yes, that seems reasonable to me. Moreover, I think you have to do this anyway, since I don't believe that X86 (is that your platform?) supports double-indirection-with-index off the stack (but it's been nearly 30 years, so I could be very wrong about that). – kdgregory Jun 13 '14 at 18:18
  • Perhaps they want to avoid suspension at arbitrary points in the code. With code the suspension can only happen at a few well defined points. – CodesInChaos Jun 13 '14 at 18:22

If you don't pause the world, the object graph can be modified concurrently to the GC's work. New objects are added, existing references are rewritten under your feet, already-marked objects become unreachable, and not all of these modifications might become visible to the GC at the same time or in the same order. For example, consider this code:

Object b = new Something();
// Now the GC reaches obj and scans its fields.
obj.next = b;
b = obj;
// Now the GC decides to scan the stack of this thread.
// It finds that b refers to an object it has already seen,
// so the new Something() is never marked and wrongly GC'd.

Like almost any concurrency problem, correctly solving it is quite complicated and has much potential for subtle and hard-to-find errors. There are algorithms that can do it, and they are used in some advanced VMs, but they're far more complicated and usually have lower throughput. It's far simpler to just use the most coarse synchronization available.

  • I understand this. However, what I would like to understand is why Java uses the described mechanism, and doesn't just put the threads to sleep. – Pieter van Ginkel Jun 13 '14 at 18:06
  • @PietervanGinkel How would you "just put the threads to sleep"? – user7043 Jun 13 '14 at 18:18
  • @delnan On windows there is SuspendThread – CodesInChaos Jun 13 '14 at 18:19
  • @CodesInChaos Read the remarks in the MSDN for SuspendThread: "This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization." – Andrew Medico Jun 13 '14 at 18:28
  • but there is the Thread.halt() built into the JVM – ratchet freak Jun 13 '14 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.