[email protected] (David Crayford) writes: > That's because there are no viable alternatives. It probably wouldn't > be the case if there was a zIIP enabled Ruby on Rails, Python Django > or node.js framework available.
trivia when java came out ... the director of the business group was somebody use to work with at ibm (we were invited to the JAVA announcement party) He had been in the los gatos vlsi chip design group and was one of two people responsible for implementing mainframe pascal ... which was used internally for lots of chip design tools (requiring significant performance) ... eventually being released to customers as vs/pascal. the original mainframe tcp/ip product was also implemented in vs/pascal (and had none of the buffer length exploits that have been epidemic in c language implementations). He then left to do a 3270 clone controller startup ... TSO operation was so bad that they had a bunch of TSO stuff implemented in the controller ... which they figured would have big market ... but the IBM/PC overtook them. He then went on to be VP of MIPS software development ... and when SGI bought MIPS ... went to SUN. This was age when everybody seemed to be doing object-oriented operating systems ... apple had "pink" and sun had "spring". Before "spring" was shutdown ... we were approached about running the group and commercializing spring and turning it out as product ... but declined. When "spring" was shutdown ... all the people were moved over to JAVA. There was some amount of synergy between spring and green (which morphs into JAVA) ... a major objective of spring was highly distributed computing model http://en.wikibooks.org/wiki/Java_Programming/History from spring papers, gone 404, but live on at wayback machine http://web.archive.org/web/20030404182953/http://java.sun.com/people/kgh/spring/ A Client-Side Stub Interpreter We have built a research operating system in which all services are presented through interfaces described by an interface description language. The system consists of a micro-kernel that supports a small number of these interfaces, and a large number of interfaces that are implemented by user-level code. A typical service implements one or more interfaces, but is a client of many other interfaces that are implemented elsewhere in the system. We have an interface compiler that generates client-side and service-side stubs to deliver calls from clients to services providing location transparency if the client and server are in different address spaces. The code for client-side stubs was occupying a large amount of the text space on our clients, so a stub interpreter was written to replace the client-side stub methods. The result was that we traded 125k bytes of stub code for 13k bytes of stub descriptions and 4k bytes of stub interpreter. This paper describes the stub interpreter, the stub descriptions, and discusses some alternatives. ... snip ... 125kbytes of code was significant percent of real storage on many machines of the period. there were a couple operations in silicon valley that did a lot of work on JIT (just in time) compiling for various mainframe 370 emulators (on the fly translating 370 code segments into native code) ... eventually similar techniques start to appear for JAVA ... with increasing levels of performance. http://en.wikipedia.org/wiki/Java_performance -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
