The various anecdotes I've heard and experienced about Oak and Java development regarding threads (and AWT and Swing) aside, the history of java.lang.Thread following JDK 1.0 makes the situation self-evident.
Thread.stop() and friends were promptly deprecated and all of the people doing formal methods work on the JVM (both academically and at the behest of Sun and the smartcard people) omitted threads entirely from their models. Why did that happen? Because it is immediately obvious there is no way to usefully analyze JVM behavior with a threading model that is totally unspecified wrt to bytecode processing. And although it is somewhat less of an indictment, we're all familiar with the even more subtle problems that Doug Lea pointed out given that their behavior wrt the memory model (even though specified) isn't correct in the presence of multiple processors. What's really sick is that from the very start we've had JVM implementations using green threads which, since they're internally the same as continuations, actually do the right thing. But because the JVM specification is defined in terms of the native thread API instead, we've been quite stuck as this thread has discussed. The switch away from having green threads as the default implementation (which it was in JDK 1.0 and I think 1.1) was the reason Thread.stop() had to be deprecated and was one of the many bad decisions Sun unilaterally made over Java. It was part of the delusional marketing controlled thinking in which "HotSpot will solve any possible performance issue". That finally fell to reality and we eventually (2002/2003) got NIO and RTJS (aka JSR-1). Of course the magnitude of those changes (NIO) are such that plenty of production systems are still on JDK 1.3 and 1.4. I'm not sure how innovative it is that we move forward by rolling the clock back 12 years. But then repairing the damage from those days and reclaiming some of Java's promise is what the Great Java Renaissance is about... http://ifcx.org/wiki/BeyondJava.html#section-BeyondJava-TheGreatJavaRenaissance2006 Jim Ted Neward wrote: > I'd be curious to hear why you think it was "slapdash"ed in. The more I dig > into the JVM, the more I realize that very little of its engineering is > anything but precise and deliberate. > > That said, I think the engineers at Sun would love to see alternate > threading implementations contributed by the community, possibly under > control of a -XX flag to decide which threading model to use, perhaps as a > new Innovator's Challenge project. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > >>-----Original Message----- >>From: [email protected] [mailto:jvm- >>[EMAIL PROTECTED] On Behalf Of Jim White >>Sent: Friday, April 11, 2008 12:54 PM >>To: [email protected] >>Subject: [jvm-l] Re: Emulating interruptible threads on the JVM >> >>John Rose wrote: >> >>>... >>>Bottom line: I think Java is stuck with explicit polling for >>>interrupts. >> >>It wouldn't be if we'd gotten continuations instead of the slapdash >>mashing of a native thread model into the JVM. >> >>http://ifcx.org/wiki/Continuations.html >> >>Now that Java is OSS, the next time someone does something like INRIA's >>Migratory Threads implementation it'll wind up in some flavor of the >>OpenJDK so the rest of us can use it. >> >>Jim >> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
