Towards safer, simpler computing
It's ironic Java's sandbox security model is designed to protect clients from unsafe/malicious code while its success is primarily on servers, where Java's security model is woefully inadequate. It can't protect against things like unbounded CPU, Memory or IO usage, things that cause serious server problems. Not to mention the security model complicates everything in the VM (class loaders, byte code verifiers, and doobledy gook plier frakers) even if you don't actually need any security.
I just had that conversation with a friend before he left for JavaOne. He's frustrated by a number of things in Java, which all go back to the needs of the security model - his point being that it has less relevance for a server side application. I'm running this application on a Smalltalk server, where arbitrary code could be loaded in at any time. Here's the catch though - only two people have permissions on the system. So in order to mount such a code loading attack, one of the two of us would have to do it. Hmm - seems unlikely.
Instead of complex VM security models applied to general purpose languages, we'd be better off using domain specific languages that are by design limited to provably safe activities. I see a future more about simple and small special purpose languages that can be connected easily, and less about giant bloated do-it-all beasts like C# and Java.
Posted May 21, 2006 7:54 PM
Comments
This was one of the things that kicked my ass (and continues to in some cases!) when writing Tornado server. Because Tornado is a web app server, each time a user requests a page, and action (Java class) is created and run. If you make a goober mistake (like I regularly do!) and build an infinite loop, you can't actually kill the thread. This sucks bigtime. You used to be able to, but Thread.kill() has been deprecated in later releases of Java because it is "unsafe". I say infinite loops are more dangerous than the ability to murder a thread.
Brendon Upson, May 22, 2006 12:15 AM
Infinite loops are murder on a server and killing threads is quite dangerous in Java, largely because of the shared state threading model.
I think this may be why hosted Java is so rare compared to PHP. PHP is far safer and simpler to host for an ISP.
Damien, May 22, 2006 1:54 PM
Agreed, especially concerning the doobledy gook plier frakers. However, it's not necessary to construct domain specific languages to get many of the benefits you mention.
Python and Ruby systems usually have just one server application per operating system process, giving system administrators a simple way to control each application's use of CPU, memory and IO. It also removes the complications of Java's much-abused security model. Unfortunately, Java's per-process memory overhead means that this always isn't an option, and the Java standards are going to have to continue to attempt to support multiple applications per JVM.
Alan Green, May 22, 2006 7:17 PM
Indeed. I investigated a hosted version of Tornado but due to the restrictions mentioned above, it's not easy to completely isolate each application instance.
I use some custom classloaders so there is a level of protection, but not enough isolation that I would recommend it in a hosted environment. It does work brilliantly where you trust all your programmers ;-)
Brendon Upson, May 23, 2006 3:14 AM
Currently, the right way to limit CPU, memory and I/O is to get help from the kernel. Virtual servers (like http://linux-vserver.org) are pretty good at enforcing limits.
You've got to have fully isolated processes before you can safely recover from infinite loops, excessive or infinite recursion, excessive memory consumption, excessive swapping, native library bugs, filesystem errors, kernel bugs, and so on. Java creates an illusion that its simple thread model approaches the beauty of isolated processes. Don't believe it! Rely more on processes and less on threads, and make the processes fail gracefully when they can't talk to each other.
Shane Hathaway, May 25, 2006 11:27 PM
I agree entirely. I'm actually working on a domain-specific language for network code in my spare time. My next question: what other low-hanging problems could be attacked with a domain-specific programming language?
Sam Kaufman, June 1, 2006 12:42 PM
Post a comment