18. GVM Application Guest OS Guest Virtual Memory Guest OS page table Guest-virtual to guest-physical Guest Physical Memory Hypervisor Guest-physical to host-physical Host Physical Memory Overview of Virtualization Layer of Memory Management
19. Virtualization layer GVM Applications Guest OS Layer2 PT – Maps guest virtual address space to guest physical address space Host Physical Memory … Guest PM … Guest VM … Guest VM … GVM Applications Guest OS Guest VM Guest PM … Layer2 PT – Maps guest virtual address space to guest physical address space Guest VM Address Translation Between Applications, Guest OS and Virtualization Layer Layer1 PT – Maps guest physical address space to host physical address space
38. Bill Venners, Inside the Java Virtual Machine 2nd Edition, Computing McGraw-Hill, May 2000.
39. Cliff Click, Gil Tene, Michael Wolf, The Pauseless GC Algorithm. In proc. of ACM June 11–12, 2005, Chicago, Illinois, USA.
40. Dykstra, L. Srisa-an, W. Chang, J.M, An analysis of the garbage collection performance in Sun’s HotSpotTM Java Virtual Machine. In proc. of 21st IEEE International conf. 2002, pp. 335-339.
41. Richard Jones, Rafael Lins, Garbage Collection: Algorithms for Automatic Dynamic Memory Management, John Wiley & Sons Inc. ISBN 0-471-94148-4, August 1996.
42. HamidMcheick, AymenSioud, Comparison of Garbage Collector Prototypes for C++ Applications, IEEE/ACS International Conference on Computer Systems and Applications, AICCSA 2009, pp. 668-674.
43. Mark Stillwell, David Schanzenbach, Frederic Vivien, Henri, Resource Allocation Algorithms for Virtualized Service Hosting Platforms. In Journal of Parallel and Distributed Computing, June 1 2010.
44. PawelGarbacki, Vijay K. Naik, Efficient Resource Virtualization and Sharing Strategies for Heterogeneous Grid Environments, 10th IFIPIEEE International Symposium on Integrated Network Management, 2007.
45. Peter Baer Galvin, VMware vSphere vs. Microsoft Hyper-V: A Technical Analysis – CTI Strategy White paper, Rev. 4.0/Nov 2009.
47. Sun Microsystems, Memory Management in the Java HotSpot Virtual Machine, https://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf, Apr. 2006.
49. Tim Lindholm, Frank Yellin, The Java Virtual Machine Specification 2nd Edition, Prentice Hall, April 1999.
50.
Editor's Notes
A virtualized environment consists of one or more GVMs, in which guest OS resides. Guest OS runs one or more applications; host OS is the operating system on which the virtualization takes place by leveraging the beneath physical hardware. Virtualization layer presents virtual hardware to different GVMs.Note: Hypervisors will be freely shipped as a Hardware component – Hypervisor that ships in the firmware. Software component – Hypervisor included inside host OS as a feature called virtual machine engine, with the ability for virtualization.The features of virtualization and the effect it has on application implementation, datacenter facility implementation and management. The impact that future server technology will have in driving virtualization, based on datacenter requirements to achieve optimal resource use and application performance.Decision criteria to use when and how to virtualize datacenter. Analysis of the current state of the virtualization and best practices to consider when deploying virtualized infrastructure.Virtualization is supported either through hardware or software:- Hardware-assisted virtualization is an important aspect in the reliability and performance of virtualization. It can be supported by having advanced hardware features that make the job of virtualizing the hardware more easier for virtualization software. Hardware-assisted virtualization reduces the virtualization code. The CPUs reduces the amount of virtualization code, the number of tasks the software has to perform and the resources the software uses by offloading the software. Virtualization is supported inside the host OS by running a software called VMM (Virtual Machine Monitor).
GVM is a logical hardware, which gives an illusion to the users that they have an entire hardware at their disposal. In fact, more than one GVM can be hosted on a physical hardware. Due to the GVMs isolation, neither the guest OS is aware that it is running inside a GVM nor it is aware about the state of the other GVMs running on the same host. Multiple GVMs facilitate different users to execute their programs either parallely, concurrently or sequentially.
Optimized Runtime PlatformMore effective use of resources (10s of cores, 100s of GBs)Scales smoothly over a wide range (from 1 GB to 1 TB) Greater stability, resiliency and operating rangeRecord-breaking ScalabilityCompletely eliminates GC-related barriers Practical support for 100x larger heaps (e.g. 200-500+ GBs) Sustain 100x higher throughput and allocation ratesSimplified Java App Deployments Better app stability with fewer, more robust JVMs Zero-overhead runtime visibility ?Application-aware resource control In a single JVM, applications are attempting to allocate 10GBs of heap memory considering the fact into account that JVM should not crash only result into pauses. But certain sanitation tasks, occurs with minimal frequency take significantly longer causing JVM pauses. “You can run everybody’s JVM today, Sun, Hotspot, OpenJDK, on a 300 gigabyte heap if you choose to. The reason nobody deploys anything above two to three, or four or six gigabytes if they are really courageous, is because JVMs will pause and stop periodically, and the size of the stop, and the length of the stop, will depend on the size of the heap. So, with a 2 gig JVM, you should expect a roughly 15 second pause every once in a while. With a 4-gigabyte JVM you need to expect a half a minute pause. With a ten gigabyte JVM you might have a pause of a minute and a half.”Scalability: Inability to scale beyond few GBs of memory and handful of cores. However, over the years JVM has gone several changes. Today, a JVM can scale memory to a larger extent [2]. Nevertheless, larger the scalability, the larger will be the onerous on GC. Thus, it directly influences the responsiveness.Rigidity: It supports a fixed memory allocation size for each JVM instance. Thus, preventing applications taking the benefit of elasticity. However, modern JVMs will have variable memory allocation size for meeting all its changing requirements.Instability: It shows inconsistent behavior outside operating range, particularly under load conditions. This applies equally well to the later versions of JVM. Complexity: It is of poor visibility and management within and across a “proliferation” of JVMs. In general, it holds to all generation of JVMs. Topology: It is ill suited for performance-centric virtualized and cloud deployments. Nevertheless, JVM has gone several changes to support virtualized deployment.
Scalability: Inability to scale beyond few GBs of memory and handful of cores. However, over the years JVM has gone several changes. Today, a JVM can scale memory to a larger extent [2]. Nevertheless, larger the scalability, the larger will be the onerous on GC. Thus, it directly influences the responsiveness.Rigidity: It supports a fixed memory allocation size for each JVM instance. Thus, preventing applications taking the benefit of elasticity. However, modern JVMs will have variable memory allocation size for meeting all its changing requirements.Instability: It shows inconsistent behavior outside operating range, particularly under load conditions. This applies equally well to the later versions of JVM. Complexity: It is of poor visibility and management within and across a “proliferation” of JVMs. In general, it holds to all generation of JVMs. Topology: It is ill suited for performance-centric virtualized and cloud deployments. Nevertheless, JVM has gone several changes to support virtualized deployment.
![Virtualization ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)