DOCSLIB.ORG

The Design and Implementation of a Java Virtual Machine on a Cluster of Workstations

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Design and Implementation of a Java Virtual Machine on a Cluster of Workstations The Design and Implementation of a Java Virtual Machine on a Cluster of Workstations by Carlos Daniel Cavanna A thesis submitted in conformity with the requirements for the degree of Master of Applied Science Edward S. Rogers Sr. Department of Electrical and Computer Engineering University of Toronto 2003 c Copyright by Carlos Daniel Cavanna 2003 ABSTRACT The Design and Implementation of a Java Virtual Machine on a Cluster of Workstations by Carlos Daniel Cavanna Master of Applied Science Edward S. Rogers Sr. Department of Electrical and Computer Engineering University of Toronto 2003 We present the design, implementation, and evaluation of a Java Virtual Machine (JVM) on a cluster of workstations, which supports shared memory in software. More specifically, we first extend the Jupiter JVM infrastructure to support multithreading on Symmetric Multiprocessors (SMPs). We then extend this multithreaded Jupiter to deal with memory consistency, private memory allocation, and the limitations on the use of some resources on a 16-processor cluster of PCs interconnected by a Myrinet network; which supports Shared Virtual Memory and a pthreads interface. Our experimental evaluation is performed using standard benchmarks. On a 4-processor SMP, it indicates that the performance of the multithreaded version of Jupiter is midway between a na¨ıve and a state-of-the-art implementations of a Java interpreter. Our evaluation on the cluster demonstrates that good speedup is obtained. iii For Mariela, my beloved wife; and my dear parents. v ACKNOWLEDGEMENTS First, I would like to thank my supervisor, Professor Tarek Abdelrahman, for his constant guidance and encouragement during the development of this work. His high standards, attention to detail and confidence placed this work among the most interesting and challenging experiences I have ever had. I would also like to thank Patrick Doyle, for the long and productive discussions about Jupiter, his support during the initial stages of this project and for providing such a good system to work with. And Peter Jamieson, for the long hours we spent solving development issues in the SVM system when enabling Jupiter to run on the cluster, and debugging the newly released Linux version of CableS. I must extend my appreciation to Professor Angelos Bilas for providing the resources to make this project advance, and Rosalia Christodoulopoulou and Reza Azimi for continuously improving VMMC. I am also thankful to all my friends, who were always present when I needed them. In particular to Diego Novillo, who constantly provided accurate suggestions throughout this work, and to Professors Gerardo Castillo and Andrea Lanaro, who I have always considered very good friends, for motivating me so strongly to follow this path. Last, but not least, I want to express my deepest gratitude to my wife for her understanding, patience and love; and my family, without whose support, endless love, and lifelong encouragement I would not have accomplished this achievement. vii TABLE OF CONTENTS DEDICATION ........................................ v ACKNOWLEDGEMENTS ................................ vii LIST OF TABLES ..................................... xiii LIST OF FIGURES .................................... xv CHAPTERS 1. Introduction .................................... 1 1.1 Objectives and Contribution . ....................... 2 1.2ThesisOrganization............................. 4 2. Background and Related Work ........................ 5 2.1TheJavaModel............................... 5 2.2TheJupiterJVM.............................. 6 2.3MemoryConsistency............................ 6 2.4Clusters.................................... 9 2.5SharedVirtualMemoryClusters...................... 9 2.5.1 The Myrinet Cluster, VMMC, GeNIMA and CableS . 10 2.5.2 ProgrammingusingCableS................... 12 2.6RelatedWork................................ 14 2.6.1 JavaParty............................. 14 2.6.2 JESSICA/JESSICA2....................... 15 2.6.3 Java/DSM............................. 16 2.6.4 cJVM............................... 17 2.6.5 Kaffemik.............................. 17 2.6.6 Hyperion.............................. 18 ix 3. Multithreading Extensions ........................... 19 3.1MultithreadinginJVMs.......................... 19 3.1.1 ThreadHandling......................... 19 3.1.2 Synchronization.......................... 21 3.1.3 Wait-SetsandNotification.................... 21 3.2MultithreadinginJupiter.......................... 22 3.2.1 ThreadingModules........................ 25 3.2.2 ThinThread ............................ 27 3.2.3 Thread and Monitor Modules.................. 29 3.2.4 Monitor Support for Recursive Calls . ........... 31 3.2.5 Monitor and Spurious Wake-ups . ............... 31 3.2.6 ThreadJoining.......................... 34 3.2.7 WaitingonNon-DaemonThreads................ 34 3.3InitializationRoutines............................ 36 3.4MutableDataandSynchronization.................... 37 3.5MultithreadedQuickOpcodes....................... 39 3.5.1 Quick Opcodes Overview . ................... 39 3.5.2 MultithreadedQuickOpcodeReplacement........... 42 4. Shared Virtual Memory Extensions ..................... 49 4.1DesignIssues................................. 49 4.2MemoryConsistency............................ 50 4.2.1 LockingonJavaClassCreation................. 51 4.2.2 Locking on Java Object Access . ............... 52 4.2.3 LockingonJavaObjectCreation................ 53 4.2.4 VolatileFields........................... 53 4.2.5 ArgumentPassingatSystemThreadCreation......... 54 4.2.6 MemoryConsistencyatJavaThreadCreation......... 57 4.2.7 MemoryConsistencyatJavaThreadTermination....... 60 4.3PrivateMemoryAllocation......................... 60 4.3.1 Private and Shared Memory Sources . ........... 61 4.3.2 ThreadStack........................... 63 4.3.3 JNI(JavaNativeInterface)................... 64 4.3.4 ThreadHandling......................... 65 4.3.5 OpcodeInterpretation...................... 66 4.3.6 ClassParsing........................... 66 4.4 Limitation of Resources ........................... 66 4.5BarrierImplementation........................... 68 4.6GarbageCollection............................. 69 4.7TheJavaMemoryModel.......................... 70 x 5. Experimental Evaluation ............................ 71 5.1TheBenchmarks............................... 71 5.2TheExperimentPlatforms......................... 74 5.2.1 MeasurementMethodology................... 75 5.3SMPEvaluation............................... 76 5.3.1 Single-Threaded Jupiter vs. Multithreaded Jupiter . 77 5.3.2 Multithreaded Jupiter vs. Reference JVMs ........... 78 5.3.3 Speedup.............................. 79 5.4ClusterEvaluation.............................. 81 5.4.1 EvaluationRemarks....................... 83 5.4.2 OneProcessorperNode..................... 84 5.4.3 TwoProcessorsperNode.................... 85 5.4.4 PerformanceImpactoftheSVMSystem............ 86 6. Conclusions ..................................... 99 6.1SummaryandConclusions......................... 99 6.2 Future Work . ............................... 101 APPENDICES A. Benchmark Details ................................ 107 A.1SPECjvm98................................. 107 A.2JavaGrande................................. 108 B. Stack Design .................................... 113 B.1 Java Stack Overview . ........................... 113 B.2Variable-SizeStackSegment........................ 114 B.3ExperimentalEvaluation.......................... 116 BIBLIOGRAPHY ......................................119 xi LIST OF TABLES Table 5.1 SPECjvm98BenchmarkApplications....................... 72 5.2 JavaGrandeBenchmarkApplications...................... 72 5.3 SMPExperimentPlatform............................. 74 5.4 ClusterExperimentPlatform........................... 75 5.5 JVMs........................................ 77 5.6 Execution Times for the Multithreaded Jupiter with Respect to the Single- ThreadedJupiterUsingtheSPECjvm98Benchmarks.............. 77 5.7 Execution Times for the Multithreaded Jupiter with Respect to the Reference JVMsUsingtheSPECjvm98Benchmarks.................... 79 5.8 Execution Times for the Multithreaded Jupiter with Respect to the Reference JVMsUsingtheJavaGrandeBenchmarks(SizeA)............... 80 5.9 Stress Tests for the Multithreaded Jupiter with Respect to the Reference JVMs UsingtheJavaGrandeBenchmarks........................ 81 5.10 Added Execution Times for the Multithreaded Jupiter and the Reference JVMsUsingtheJavaGrandeBenchmarks(SizeA)............... 82 5.11 Average Speedup for the Multithreaded Jupiter and the Reference JVMs Using theJavaGrandeBenchmarks(SizeA)...................... 82 5.12 Execution and Benchmark Times for the Cluster-Enabled Jupiter on One Pro- cessorperNodeUsingtheJavaGrandeBenchmarks(SizeA)......... 87 5.13 Execution and Benchmark Times for the Cluster-Enabled Jupiter on One Pro- cessorperNodeUsingtheJavaGrandeBenchmarks(SizeB)......... 88 xiii 5.14 Average Speedup for the Cluster-Enabled Jupiter on One Processor per Node UsingtheJavaGrandeBenchmarks(SizeA).................. 89 5.15 Average Speedup for the Cluster-Enabled Jupiter on One Processor per Node UsingtheJavaGrandeBenchmarks(SizeB)................... 89 5.16 Execution and Benchmark Times for the Cluster-Enabled Jupiter on Two Pro- cessorsperNodeUsingtheJavaGrandeBenchmarks(SizeA)......... 92 5.17 Execution and Benchmark Times for the Cluster-Enabled Jupiter on Two Pro- cessorsperNodeUsingtheJavaGrandeBenchmarks(SizeB)......... 93 5.18 Average Speedup
Load more

Recommended publications
  • Extending the UHC LLVM Backend: Adding Support for Accurate Garbage Collection
    Extending the UHC LLVM backend: Adding support for accurate garbage collection Paul van der Ende MSc Thesis October 18, 2010 INF/SCR-09-59 Daily Supervisors: Center for Software Technology dr. A. Dijkstra Dept. of Information and Computing Sciences drs. J.D. Fokker Utrecht University Utrecht, the Netherlands Second Supervisor: prof. dr. S.D. Swierstra Abstract The Utrecht Haskell Compiler has an LLVM backend for whole program analyse mode. This backend pre- viously used the Boehm-Weiser library for heap allocation and conservative garbage collection. Recently an accurate garbage collector for the UHC compiler has been developed. We wanted this new garbage collection library to work with the LLVM backend. But since this new collector is accurate, it needs cooperation with the LLVM backend. Functionality needs to be added to find the set of root references and traversing all live references. To find the root set, the bytecode interpreter backend currently uses static stack maps. This is where the problem arises. The LLVM compiler is known to do various aggressive transformations. These optimizations might change the stack layout described by the static stack map. So to avoid this problem we wanted to use the shadow-stack provided by the LLVM framework. This is a dynamic structure maintained on the stack to safely find the garbage collection roots. We expect that the shadow-stack approach comes with a runtime overhead for maintaining this information dynamically on the stack. So we did measure the impact of this method. We also measured the performance improvement of the new garbage collection method used and compare it with the other UHC backends.
    [Show full text]
  • Toward Harnessing High-Level Language Virtual Machines for Further Speeding up Weak Mutation Testing
    2012 IEEE Fifth International Conference on Software Testing, Verification and Validation Toward Harnessing High-level Language Virtual Machines for Further Speeding up Weak Mutation Testing Vinicius H. S. Durelli Jeff Offutt Marcio E. Delamaro Computer Systems Department Software Engineering Computer Systems Department Universidade de Sao˜ Paulo George Mason University Universidade de Sao˜ Paulo Sao˜ Carlos, SP, Brazil Fairfax, VA, USA Sao˜ Carlos, SP, Brazil [email protected] [email protected] [email protected] Abstract—High-level language virtual machines (HLL VMs) have tried to exploit the control that HLL VMs exert over run- are now widely used to implement high-level programming ning programs to facilitate and speedup software engineering languages. To a certain extent, their widespread adoption is due activities. Thus, this research suggests that software testing to the software engineering benefits provided by these managed execution environments, for example, garbage collection (GC) activities can benefit from HLL VMs support. and cross-platform portability. Although HLL VMs are widely Test tools are usually built on top of HLL VMs. However, used, most research has concentrated on high-end optimizations they often end up tampering with the emergent computation. such as dynamic compilation and advanced GC techniques. Few Using features within the HLL VMs can avoid such problems. efforts have focused on introducing features that automate or fa- Moreover, embedding testing tools within HLL VMs can cilitate certain software engineering activities, including software testing. This paper suggests that HLL VMs provide a reasonable significantly speedup computationally expensive techniques basis for building an integrated software testing environment. As such as mutation testing [6].
    [Show full text]
  • Improving Memory Management Security for C and C++
    Improving memory management security for C and C++ Yves Younan, Wouter Joosen, Frank Piessens, Hans Van den Eynden DistriNet, Katholieke Universiteit Leuven, Belgium Abstract Memory managers are an important part of any modern language: they are used to dynamically allocate memory for use in the program. Many managers exist and depending on the operating system and language. However, two major types of managers can be identified: manual memory allocators and garbage collectors. In the case of manual memory allocators, the programmer must manually release memory back to the system when it is no longer needed. Problems can occur when a programmer forgets to release it (memory leaks), releases it twice or keeps using freed memory. These problems are solved in garbage collectors. However, both manual memory allocators and garbage collectors store management information for the memory they manage. Often, this management information is stored where a buffer overflow could allow an attacker to overwrite this information, providing a reliable way to achieve code execution when exploiting these vulnerabilities. In this paper we describe several vulnerabilities for C and C++ and how these could be exploited by modifying the management information of a representative manual memory allocator and a garbage collector. Afterwards, we present an approach that, when applied to memory managers, will protect against these attack vectors. We implemented our approach by modifying an existing widely used memory allocator. Benchmarks show that this implementation has a negligible, sometimes even beneficial, impact on performance. 1 Introduction Security has become an important concern for all computer users. Worms and hackers are a part of every day internet life.
    [Show full text]
  • A Hardware Abstraction Layer in Java
    A Hardware Abstraction Layer in Java MARTIN SCHOEBERL Vienna University of Technology, Austria STEPHAN KORSHOLM Aalborg University, Denmark TOMAS KALIBERA Purdue University, USA and ANDERS P. RAVN Aalborg University, Denmark Embedded systems use specialized hardware devices to interact with their environment, and since they have to be dependable, it is attractive to use a modern, type-safe programming language like Java to develop programs for them. Standard Java, as a platform independent language, delegates access to devices, direct memory access, and interrupt handling to some underlying operating system or kernel, but in the embedded systems domain resources are scarce and a Java virtual machine (JVM) without an underlying middleware is an attractive architecture. The contribution of this paper is a proposal for Java packages with hardware objects and interrupt handlers that interface to such a JVM. We provide implementations of the proposal directly in hardware, as extensions of standard interpreters, and finally with an operating system middleware. The latter solution is mainly seen as a migration path allowing Java programs to coexist with legacy system components. An important aspect of the proposal is that it is compatible with the Real-Time Specification for Java (RTSJ). Categories and Subject Descriptors: D.4.7 [Operating Systems]: Organization and Design—Real-time sys- tems and embedded systems; D.3.3 [Programming Languages]: Language Classifications—Object-oriented languages; D.3.3 [Programming Languages]: Language Constructs and Features—Input/output General Terms: Languages, Design, Implementation Additional Key Words and Phrases: Device driver, embedded system, Java, Java virtual machine 1. INTRODUCTION When developing software for an embedded system, for instance an instrument, it is nec- essary to control specialized hardware devices, for instance a heating element or an inter- ferometer mirror.
    [Show full text]
  • Techniques for Real-System Characterization of Java Virtual Machine Energy and Power Behavior Gilberto Contreras Margaret Martonosi
    Techniques for Real-System Characterization of Java Virtual Machine Energy and Power Behavior Gilberto Contreras Margaret Martonosi Department of Electrical Engineering Princeton University 1 Why Study Power in Java Systems? The Java platform has been adopted in a wide variety of devices Java servers demand performance, embedded devices require low-power Performance is important, power/energy/thermal issues are equally important How do we study and characterize these requirements in a multi-layer platform? 2 Power/Performance Design Issues Java Application Java Virtual Machine Operating System Hardware 3 Power/Performance Design Issues Java Application Garbage Class Runtime Execution Collection LoaderJava VirtualCompiler MachineEngine Operating System Hardware How do the various software layers affect power/performance characteristics of hardware? Where should time be invested when designing power and/or thermally aware Java virtual Machines? 4 Outline Approaches for Energy/Performance Characterization of Java virtual machines Methodology Breaking the JVM into sub-components Hardware-based power/performance characterization of JVM sub-components Results Jikes & Kaffe on Pentium M Kaffe on Intel XScale Conclusions 5 Power & Performance Analysis of Java Simulation Approach √ Flexible: easy to model non-existent hardware x Simulators may lack comprehensiveness and accuracy x Thermal studies require tens of seconds granularity Accurate simulators are too slow Hardware Approach √ Able to capture full-system characteristics
    [Show full text]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Apache Harmony Project Tim Ellison Geir Magnusson Jr
    The Apache Harmony Project Tim Ellison Geir Magnusson Jr. Apache Harmony Project http://harmony.apache.org TS-7820 2007 JavaOneSM Conference | Session TS-7820 | Goal of This Talk In the next 45 minutes you will... Learn about the motivations, current status, and future plans of the Apache Harmony project 2007 JavaOneSM Conference | Session TS-7820 | 2 Agenda Project History Development Model Modularity VM Interface How Are We Doing? Relevance in the Age of OpenJDK Summary 2007 JavaOneSM Conference | Session TS-7820 | 3 Agenda Project History Development Model Modularity VM Interface How Are We Doing? Relevance in the Age of OpenJDK Summary 2007 JavaOneSM Conference | Session TS-7820 | 4 Apache Harmony In the Beginning May 2005—founded in the Apache Incubator Primary Goals 1. Compatible, independent implementation of Java™ Platform, Standard Edition (Java SE platform) under the Apache License 2. Community-developed, modular architecture allowing sharing and independent innovation 3. Protect IP rights of ecosystem 2007 JavaOneSM Conference | Session TS-7820 | 5 Apache Harmony Early history: 2005 Broad community discussion • Technical issues • Legal and IP issues • Project governance issues Goal: Consolidation and Consensus 2007 JavaOneSM Conference | Session TS-7820 | 6 Early History Early history: 2005/2006 Initial Code Contributions • Three Virtual machines ● JCHEVM, BootVM, DRLVM • Class Libraries ● Core classes, VM interface, test cases ● Security, beans, regex, Swing, AWT ● RMI and math 2007 JavaOneSM Conference | Session TS-7820 |
    [Show full text]
  • A Post-Apocalyptic Sun.Misc.Unsafe World
    A Post-Apocalyptic sun.misc.Unsafe World http://www.superbwallpapers.com/fantasy/post-apocalyptic-tower-bridge-london-26546/ Chris Engelbert Twitter: @noctarius2k Jatumba! 2014, 2015, 2016, … Disclaimer This talk is not going to be negative! Disclaimer But certain things are highly speculative and APIs or ideas might change by tomorrow! sun.misc.Scissors http://www.underwhelmedcomic.com/wp-content/uploads/2012/03/runningdude.jpg sun.misc.Unsafe - What you (don’t) know sun.misc.Unsafe - What you (don’t) know • Internal class (sun.misc Package) sun.misc.Unsafe - What you (don’t) know • Internal class (sun.misc Package) sun.misc.Unsafe - What you (don’t) know • Internal class (sun.misc Package) • Used inside the JVM / JRE sun.misc.Unsafe - What you (don’t) know • Internal class (sun.misc Package) • Used inside the JVM / JRE // Unsafe mechanics private static final sun.misc.Unsafe U; private static final long QBASE; private static final long QLOCK; private static final int ABASE; private static final int ASHIFT; static { try { U = sun.misc.Unsafe.getUnsafe(); Class<?> k = WorkQueue.class; Class<?> ak = ForkJoinTask[].class; example: QBASE = U.objectFieldOffset (k.getDeclaredField("base")); java.util.concurrent.ForkJoinPool QLOCK = U.objectFieldOffset (k.getDeclaredField("qlock")); ABASE = U.arrayBaseOffset(ak); int scale = U.arrayIndexScale(ak); if ((scale & (scale - 1)) != 0) throw new Error("data type scale not a power of two"); ASHIFT = 31 - Integer.numberOfLeadingZeros(scale); } catch (Exception e) { throw new Error(e); } } } sun.misc.Unsafe
    [Show full text]
  • Java in Embedded Linux Systems
    Java in Embedded Linux Systems Java in Embedded Linux Systems Thomas Petazzoni / Michael Opdenacker Free Electrons http://free-electrons.com/ Created with OpenOffice.org 2.x Java in Embedded Linux Systems © Copyright 2004-2007, Free Electrons, Creative Commons Attribution-ShareAlike 2.5 license http://free-electrons.com Sep 15, 2009 1 Rights to copy Attribution ± ShareAlike 2.5 © Copyright 2004-2008 You are free Free Electrons to copy, distribute, display, and perform the work [email protected] to make derivative works to make commercial use of the work Document sources, updates and translations: Under the following conditions http://free-electrons.com/articles/java Attribution. You must give the original author credit. Corrections, suggestions, contributions and Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license translations are welcome! identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/2.5/legalcode Java in Embedded Linux Systems © Copyright 2004-2007, Free Electrons, Creative Commons Attribution-ShareAlike 2.5 license http://free-electrons.com Sep 15, 2009 2 Best viewed with... This document is best viewed with a recent PDF reader or with OpenOffice.org itself! Take advantage of internal
    [Show full text]
  • Solution Brief JVM Performance Monitoring
    Solution Brief Monitoring the Health & Performance of Java Virtual Machines (JVM) Total Performance Visibility JVM: The Cornerstone of Java Enterprise Applications The Java Virtual Machine (JVM) forms the core of the Java application architecture. It plays the crucial role of interpreting and translating Java byte code into operations on the host platform. Since Java middleware (application servers such as Tomcat, JBoss EAP, JBoss AS, WildFly, WebSphere, and WebLogic) runs on the JVM, a performance issue at the JVM level has a major impact on business services supported by it. Monitoring of the JVM must be an integral part of any Java application performance monitoring strategy. IT Ops and DevOps teams use JVM Key Benefits performance metrics to troubleshoot server-side bottlenecks. Developers and architects can also benefit from JVM monitoring by uncovering code- Proactively detect and resolve level issues. Java application problems to ensure high service uptime and business continuity Key JVM Performance Questions to Answer Troubleshoot faster: Real-time • Is there any runaway thread hogging the CPU? Which line of code is it alerts pinpoint the exact line executing, in which class, and which method? of code that is impacting Java • Is the JVM heap and non-heap memory sized correctly? applications • Are there any out-of-memory-exceptions or memory leaks? In-depth analytics enable architects to optimize Java • When does garbage collection happen, and how much memory is applications to scale and support freed up each time? additional users • Are there any thread deadlocks happening that are causing Single pane of glass to monitor application processing to be hung? everything Java—from application server, JVM and database, all the way down to server and storage End-to-End JVM Monitoring with eG Enterprise infrastructure eG Enterprise is a comprehensive performance monitoring, diagnosis and reporting solution for Java application infrastructures.
    [Show full text]
  • A Study of Cache Performance in Java Virtual Machines, the University of Texas at Austin, 2002
    Cache Performance in Java Virtual Machines: A Study of Constituent Phases Anand S. Rajan, Juan Rubio and Lizy K. John Laboratory for Computer Architecture Department of Electrical & Computer Engineering The University of Texas at Austin (arajan, jrubio,[email protected]) Abstract This paper studies the cache performance of Java programs in the interpreted and just-in- time (JIT) modes by analyzing memory reference traces of the SPECjvm98 applications with the Latte JVM. Specifically, we study the cache performance of the different components of the JVM (class loader, the execution engine and the garbage collector). Poor data cache performance in JITs is caused by code installation, and the data write miss rate can be as high as 70% in the execution engine. In addition, this code installation also causes deterioration in performance of the instruction cache during execution of translated code. We also believe that there is considerable interference between data accesses of the garbage collector and that of the compiler-translator execution engine of the JIT mode. We observe that the miss percentages in the garbage collection phase are of the order of 60% for the JIT mode; we believe that interference between data accesses of the garbage collector and the JIT execution engine lead to further deterioration of the data cache performance wherever the contribution of the garbage collector is significant. We observe that an increase in cache sizes does not substantially improve performance in the case of data cache writes, which is identified to be the principal performance bottleneck in JITs. 1 1. Introduction Java[1] is a widely used programming language due to the machine independent nature of bytecodes.
    [Show full text]
  • Java and C I CSE 351 Autumn 2016
    L26: JVM CSE351, Spring 2018 Java Virtual Machine CSE 351 Spring 2018 Model of a Computer “Showing the Weather” Pencil and Crayon on Paper Matai Feldacker-Grossman, Age 4 May 22, 2018 L26: JVM CSE351, Spring 2018 Roadmap C: Java: Memory & data Integers & floats car *c = malloc(sizeof(car)); Car c = new Car(); x86 assembly c->miles = 100; c.setMiles(100); c->gals = 17; c.setGals(17); Procedures & stacks float mpg = get_mpg(c); float mpg = Executables free(c); c.getMPG(); Arrays & structs Memory & caches Assembly get_mpg: Processes language: pushq %rbp Virtual memory movq %rsp, %rbp ... Memory allocation popq %rbp Java vs. C ret OS: Machine 0111010000011000 code: 100011010000010000000010 1000100111000010 110000011111101000011111 Computer system: 2 L26: JVM CSE351, Spring 2018 Implementing Programming Languages Many choices in how to implement programming models We’ve talked about compilation, can also interpret Interpreting languages has a long history . Lisp, an early programming language, was interpreted Interpreters are still in common use: . Python, Javascript, Ruby, Matlab, PHP, Perl, … Interpreter Your source code implementation Your source code Binary executable Interpreter binary Hardware Hardware 3 L26: JVM CSE351, Spring 2018 An Interpreter is a Program Execute (something close to) the source code directly Simpler/no compiler – less translation More transparent to debug – less translation Easier to run on different architectures – runs in a simulated environment that exists only inside the interpreter process . Just port the interpreter (program), not the program-intepreted Slower and harder to optimize 4 L26: JVM CSE351, Spring 2018 Interpreter vs. Compiler An aspect of a language implementation . A language can have multiple implementations . Some might be compilers and other interpreters “Compiled languages” vs.
    [Show full text]