Page 3 of 7
The immortal objects correspond pretty much to what people actually do as standard practice in realtime coding today. Generally when people are doing serious realtime work they pre-allocate everything. And then they sort of go into their realtime reading windows with the things which realtime never, ever allocates. Because it turns out that almost all the allocators in the world actually have non-deterministic timing.
See, almost everybody's malloc() or free routine has non-deterministic timing. And so in general, people don't use them for the intense realtime application.
So the whole no-heap thing/immortal objects, if you describe that to an average Java programmer, they'd say, "Oh my God, this
is really awful." But if you describe it to somebody who's been doing realtime programming, their reaction is sort of, "Gee,
that's what I do today. It's not a big problem."
But it gives them the advantage of this universe where people doing these really time-critical things can actually interact with the other world that is done in Java, and get all the advantages of writing programs in Java, and also get all the portability stuff. That's really the most important piece.
JavaOne Today: How do the new scheduling capabilities work?
Gosling: With scheduling, there are some new objects introduced and one is called the scheduler. And a scheduler determines when threads should get started up. And one of the parameters of the scheduler is if it's a no-heap thread, it can then start while the garbage collector is running.
But normally, the scheduler is similar to what happened in the typical thread scheduler. It's looking at the queues of threads that are available to be one. They picked one, and in most everyday computer systems these fairly simple priority-based schemes work pretty well.
In realtime systems, generally you've got a notion of a deadline when this particular computation has to be done. And so there are ways to associate properties with threads like what its deadline is, what the expected amount of work is. And that gives a scheduler more information to sort of trade off which things to run now.
It's an open-ended framework, so that people can invent new schedulers and plug them in. There's also hooks in there for doing what people in the realtime world call feasibility analysis. Namely, you've got a set of threads, and you ask the question, "So does this make any sense?" If you've got three or four threads, each of which wants 100 percent of the CPU all the time, it makes no sense at all because you'd need three or four CPUs. Or three or four times as much CPU as you've got.
So you can do things like back out or not start systems, or go into some sort of fail-safe mode. JavaOne Today: What do you mean by "back out"?
Gosling: Like not start the system. It's application dependent. When the feasibility analysis fails, what do you do?
JavaOne Today: So the VM does the feasibility analysis before it starts? Or does the application do it?
Gosling: The application effectively is in charge of invoking it. Because what the application does is it sets up a set of threads. And then it asks the scheduler "Is this feasible?" And if it is, then the system carries on. If it's not, then the application decides what to do. And it may do things like decide to cut back on its workload somehow. Or it may just even refuse to start.