That was what was alluded to in the "robust" qualifier.
see Chet's blog on the topic (in the commentary section)
http://weblogs.java.net/blog/chet/archive/2005/06/mmmmmm_vm.html
Briefly: there are two scenarios: native code in the JDK, and other native code:
1. Native code in the JDK, after all this time is pretty reliable, call it without protection - no changes needed.
2. For other code, add isolation logic to protect things (which adds overhead, lets be clear) so that a failure can be captured and the offending program notified/shut down. In some implementations this may be as simple as a signal to another process to pick up a payload and run it.
This needs to be turnoffable - there needs to be an option to run boldly without this (assuming there is some overhead cost worth avoiding).
The big problem with all of this seems to be that it is changing the plumbing in a major way, thus the risk/reward analysis reveals heavy risk. I, personally, thing the reward is sufficient, so I say, let move now, and add this as a default-off feature.
This is easy for me to say, since I'm not doing the work and won't be taking support calls if something slips through :)
Glenn |
java.net RSS Feeds
