Persistent Reusable Java Virtual Machine Dipl.-Inf. Marc Beyerle

1. Persistent Reusable Java Virtual Machine Dipl.-Inf. Marc Beyerle IBM Forschung und Entwicklung, Böblingen Prof. Dr.-Ing. Wilhelm G. Spruth Institut für Informatik, Universität Leipzig Schickard Institut für Informatik, Universität Tübingen CECMG, Ulm, 23. April 2004

2. Leading Edge Technology • Einzigartige zSeries und z/OS Eigenschaften: • Architektur: Hardware Protection Key (Buffer Overflows) • Hardware-Technologie - Zuverlässigkeit • Ein-/Ausgabe-Architektur * • Clustering, Sysplex, Coupling Facility * • Partitionierung und PR/SM LPAR Mode * • Goal-orientierter Workload-Manager • Persistent Reusable Java Virtual Machine • * (siehe Veröffentlichung)

3. Nutzung von Java für Business-Logik Backend Anwendungen Alternative zu CICS – Cobol J2EE Standard Wahrung der ACID Eigenschaften: Atomicity, Consistency, Isolation, Durability

6. Keine Performanz ohne Multiprogrammierung Nutzung von Java Threads innerhalb einer Java Virtuellen Maschine ACID Bedingungen einhalten

7. The existing application isolation mechanisms, such as class loaders, do not guarantee that two arbitrary applications executing in the same instance of the JVM will not interfere with one another. Grzegorz Czajkowski, Laurent Daynès: Multitasking without Compromise: a Virtual Machine Evolution.http://research.sun.com/projects/barcelona/papers/oopsla01.pdf Siehe auch: Bo Sandén, Coping with Java Threads. Computer, Vol. 37, Nr. 4, April 2004, p. 20

9. z/OS Unix System Services JVM

10. Überschriebene statische Variablen Geladene native Bibliotheken

11. Bei der Initialisierung einer JVM werden etwa 60 System Klassen geladen sowie 700 Array-Objekte und über 1000 non-Array-Objekte allokiert und angelegt. Pfadlänge “between 20 and 100 million instructions” Lösung: JVM mit Reset Methode - ResetJavaVM Persistent Reusable Java Virtual Machine (PRJVM)

12. Es ist möglich, dass die Ausführung einer Transaktion die PRJVM in einen Zustand unresettable versetzt. Dies kann auf einem asozialen, jedoch legalen Verhalten der Tansaktion beruhen. Beispiele   ·übrig gebliebene geöffnete Files, ·noch existierende „user threads“ ·Referenzen in den Transient Heap durch lokale Variablen.   Wenn eine dieser Bedingungen auftritt, erzeugt der Aufruf ResetJavaVM den Rückgabewert false .

13. Master JVM startet Worker JVM mit dem Aufruf • JNI_CreateJavaVM • mit der Option -Xresettable

14. Ablaufsteuerung der PRJVM

15. Speichernutzung der PRJVM Gemeinsame Nutzung des System Heaps

17. Byte-Codes and JITed Code shared between multiple JVMs Middleware is written to have a native launcher application which manages life-cycle and re-use of PR- JVMs Launcher uses an augmented set of JNI APIs to manage PRJVMs and inject work into them

18. Mehrfache PRJVMs in einem virtuellen Adressenraum

19. Garbage Collection des Middleware Heap

20. Architekturanalyse der Java VirtualMachine unter z/OS und Linux Diplomarbeitvorgelegt von Marc Beyerle Eberhard-Karls-Universität TübingenWilhelm-Schickard-Institut für Informatik 29. September 2003

21. PRJVM Performance Test - Anwendung

22. Test Konfiguration

23. Vergleichsmessungen IBM zSeries Rechner, 1 CPU

24. Test Ergebnis Reguläre JVM 0,8 Transaktionen/Sek PRJVM 260 Transaktionen/Sek.

27. CICS Nutzung der PRJVM

28. WebSphere

29. CICS

32. Ausblick ► PRJVM derzeitig als Bestandteil von WebSphere 5.0 und der CICS und IMS Transaction Server unter z/OS verfügbar. ► Ergebnisse sind vielversprechend für den zukünftigen Einsatz von Java und der PRJVM in Hochleistungs-Transaktionssystemen. ► Der Ansatz, in jedem Augenblick nur eine Transaktion pro JVM zuzulassen, dürfte ohne die Möglichkeit einer seriellen Wiederbenutzbarkeit in vielen Fällen zu nicht akzeptablen Transaktionsraten führen.

33. Literatur Marc Beyerle : Architekturanalyse der Java Virtual Machine unter z/OS und Linux.Diplomarbeit, Schickard Institut für Informatik, Universität Tübingen, 2003. Sam Borman, Susan Paice, Matthew Webster, Martin Trotter, Rick McGuire(*), Alan Stevens, Beth Hutchison, Robert Berry: A Serially Reusable Java(tm) Virtual Machine Implementation for High Volume, Highly Reliable, Transaction Processing. IBMTechnical Report TR 29.3406. D. Dillenberger, R. Bordawekar, C. W. Clark, D. Durand, D. Emmes, O. Gohda, S. Howard, M. F. Oliver, F. Samuel, R. W. St. John: Building a Java virtual machine for server applications: The JVM on OS/390. IBM Systems Journal, Volume 39, Number 1, 2000. P. Herrmann, U. Kebschull, W.G: Spruth: Einführung in z/OS und OS/390.Oldenbourg-Verlag, 2. Auflage, 2004, ISBN 3-486-27393-0. New IBM Technology featuring Persistent Reusable Java Virtual Machines. IBM Form No. SC34-6034-01, October 2001.  Matthew Webster: The IBM Persistent Reusable JVM.SHARE Technical Conference, Nashville, TN, March 3- 8, 2002http://www.share.org/proceedings/sh98/data/S8351.PDF

34. Veröffentlichungen Udo Kebschull, Paul Herrmann, Wilhelm G: Spruth:Einführung in z/OS und OS/390.Oldenbourg-Verlag, 2. Auflage, 2004, ISBN 3-486-27214-4. Wilhelm G. Spruth, Erhard Rahm: Sysplex-Cluster Technologien für Hochleistungs-Datenbanken.Datenbank-Spektrum, Heft 3, 2002, S. 16-26. Joachim Franz, Wilhelm G. Spruth:Reengineering von Kernanwendungssystemen auf Großrechnern. Informatik Spektrum, Band 26, Nr. 2, April 2003, S. 83-93. Helge Lehmann, Wilhelm G. Spruth: Eigenschaften einer modernen Ein-/Ausgabe Architektur. it - Information Technology (vormals it+ti), 2003, Volume 45, Issue 01, S. 20-29. Joachim von Buttlar, Wilhelm G. Spruth: Virtuelle Maschinen. zSeries und S/390 Partitionierung. IFE - Informatik Forschung und Entwicklung, to be published. Die meisten Veröffentlichungen sind unter http://www-ti.informatik.uni-tuebingen.de/~spruth/publish.htmlverfügbar