[email protected] (John McKown) writes: > Java initially runs intepreted JVM byte code. As the program runs, the JVM > invokes a "just in time" compiler to transform the byte code into native z > series instructions. As I understand it, the common back end that is being > discussed for COBOL, PL/I, C/C++, et al. is this "just in time" > compiler/optimizer. > > I wish z/OS did for Java what the i does. The javac compiler creates a byte > code .class file. However, attached to this byte code file is actual > pSeries native instruction which is what is really run. The i has a lot of > interesting things. What blew me away was that the compilers produce TIMI > instructions (similar in concept to Java byte code). The first time a > program is run, the OS compiles the TIMI into native code and attaches that > code to the "program object" and thereafter runs the "program object" code. > Well, sort of. Because this compiler may be improved. If this happens, or > if the TIMI code is moved to another processor, the OS will recompile and > recreate the "program object". All automatically. Must drive auditors and > change control people up the wall.
I've been in some discussion about whether JAVA was done totally independent of spring ... or with some spring overloap ... from Spring documentation: A Client-Side Stub Interpreter Peter B. Kessler Abstract 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 ... Disclaimer: after leaving IBM ... we were asked about taking on turning Spring out as commercial product http://en.wikipedia.org/wiki/Spring_%28operating_system%29 and green reference: http://en.wikipedia.org/wiki/Java_%28software_platform%29 trivia: general manager of the sun business group that included JAVA had previously been VP of software development at MIPS ... done some startups before that ... and earlier had been at the Los Gatos VLSI tools group and one of two people responsible for what became IBM's vs/pascal (although I was in research, I also had offices and labs in LSG bldg). -- 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
