CN101021800A - Virtual machine monitoring - Google Patents

Abstract

The invention relates to a system and method for monitoring the internal operation of a virtual machine ('VM'). VM is operated to interpret and implement a procedure. The internal operation of state information is stored to the internal memory buffer during VM operating period. Subsequently, the above information is extracted from the internal VM operation at a favorable external position.

Description

virtual machine monitoring

technical field

The present invention relates generally to virtual machines, and in particular, but not exclusively, to monitoring the internal operations of virtual machines.

Background technique

Enterprise software has more or less changed the way businesses of all kinds approach and manage their day-to-day work. Merchants utilize enterprise software (eg, web-based application servers) to control production planning, purchasing and logistics, warehouse and inventory management, production, supplier management, customer service, accounting, personnel management, and other basic business activities. As the enterprise software industry continues to mature, the multiple application software and hardware resources utilized to facilitate this diverse collection of tasks are consolidated into robust, highly integrated solutions (e.g., SAP NetWeaver, SAP xAPPs, mySAP Business Suite, etc.).

In order to integrate various hardware and software resources, developers of enterprise software have leveraged cross-platform engines that can minimize or even cut off the dependence of enterprise solutions on service platforms. The Java 2 Platform, Enterprise ^Edition ("J2EE") (eg, J2EE Specification, Version 1.4) is a Java-based solution powered by the Java Virtual Machine ("JVM") engine. J2EE simplifies application development and reduces the need for programming and programmer training by creating standardized and reusable modular components. The popularity of Java-based solutions is evident, as is the information technology ("IT") world's attraction to the Java language.

As enterprise software is woven into the fabric of modern business, the failure of an enterprise solution is no longer just a nuisance, but can cause catastrophic disruption to the business. Therefore, solid, reliable software is always critical. The enterprise software industry is moving toward the ultimate goal of self-healing software capable of sustaining, uninterrupted operation without human intervention. To achieve this goal, IT technicians can benefit from traditional tools that can monitor the health of their enterprise software. With the proper monitoring tools in place, IT technicians can take timely action to ensure the health of their software, or spot erroneous applications to prevent repeat mistakes. Currently, JVMs do not provide sufficient mechanisms to monitor their internal operations in real time.

Contents of the invention

A system and method of monitoring internal operations of a virtual machine ("VM") is described. VM is operated to interpret and execute a program. During operation of the VM, state information about the internal operation of the VM is stored in an internal memory buffer. The state information is then extracted from an internal memory buffer during operation of the VM in order to monitor the operation of the VM from a vantage point external to the VM.

In one embodiment, status information is accumulated by executing monitoring code embedded in the program. The execution of the monitoring code may be interleaved with the execution of the program code of the program.

During program execution, objects are created and stored on the heap. An automatic garbage collector (garbage collector) erases unreferenced objects when the program no longer references them. In one embodiment, the state information includes garbage collection activity information.

In one embodiment, a native VM monitor is invoked to retrieve status information from an internal memory buffer. The retrieved status information may then be communicated to a monitoring console for display on the monitoring console.

In one embodiment, a VM monitor is interpreted and executed on a VM. The VM monitor program is dedicated to collecting at least a portion of state information from components of the VM and storing the portion of state information to an internal memory buffer.

In one embodiment, internal memory buffers are isolated from VM failures. If a VM fails, the internal storage buffers can be accessed after the failure for postmortem investigation into the cause of the VM failure.

Embodiments of the invention may include all or some of the features described above. The above features can be implemented by computer programs, methods, systems or devices, or any combination of computer programs, methods or systems. These and other details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below.

Description of drawings

Non-limiting and non-exhaustive embodiments of the present invention will be described with reference to the following drawings, wherein like reference numerals refer to like parts throughout the various drawings unless otherwise indicated.

1 is a block diagram of a system for monitoring internal operations of a virtual machine ("VM") according to one embodiment of the present invention.

2 is a block diagram illustrating a software system including a VM capable of providing internal state information to an external entity for monitoring the VM, according to one embodiment of the present invention.

3 is a flow diagram illustrating a process for monitoring the internal operations of a VM according to one embodiment of the invention.

Figure 4 is a block diagram illustrating a demo enterprise environment for implementing one embodiment of the present invention.

Figure 5 illustrates a demonstration processing system for implementing one embodiment of the present invention.

Detailed ways

Embodiments of systems and methods for monitoring the internal operations of a virtual machine ("VM") are described herein. 1 is a block diagram of a system 100 of the internal operations of a virtual machine ("VM") 105 in accordance with an embodiment of the present invention. The illustrated embodiment of system 100 includes VM 105, program 110, and monitoring station 115. Although only three programs 110 are shown operating on VM 105, more or fewer programs 110 may run concurrently in a time-division multiplexed manner.

VM 105 interprets and executes one or more programs 110 to generate output 120. VM 105 interprets program 110 by converting the program from an intermediate interpreted language (eg, bytecode) into a native machine language which is then executed. In one embodiment, VM 105 is a Java VM ("JVM"), and program 110 represents a Java program compiled to Java bytecode. Although embodiments of the present invention are described using the object-oriented Java programming language, the techniques described here are equally applicable to other interpreted languages, and VMs for interpreting and executing those languages.

During operation of VM 105, VM 105 may provide real-time status information 125 to monitoring station 115 for display thereon. State information 125 may provide detailed operational information of the internal workings of VM 105 during interpretation and execution of program 110 . An information technology ("IT") technician can directly browse the status information 125 displayed on the monitoring console 115 to determine whether the VM 105 is operating in a healthy state, is about to fail, and other aspects. Also, state information 125 can be accessed after a VM 105 failure/crash for postmortem investigation into the cause of the failure.

The status information 125 may be “pull” to the monitoring station 115 in response to a status query 130 issued by the monitoring station 115 , or the status information 125 may be “pushed” to the monitoring station 115 . Pushing status information 125 to monitoring station 115 may be event triggered or periodically triggered. The monitoring station 115 may be located locally on the same hardware machine that executes the VM 105, or advantageously executes on a remote machine communicatively coupled thereto. Status information 125 may include various data including, but not limited to, garbage collection activity, heap status, execution activity, thread activity, program activity, and the like.

2 is a block diagram illustrating a software system 200 including a VM 105 capable of providing status information 125 to an external entity for monitoring the internal operation of the VM 105, according to one embodiment of the present invention. The illustrated embodiment of the software system 200 includes an operating system 205 (e.g., Windows, Linux, Unix, MS-DOS, OS/400, OS/390, etc.), a native wrapper 210, a VM 105, and Native VM Monitor 215 .

Native wrapper 210 provides a runtime environment for VM 105 . In embodiments where VM 105 is a Java2 Platform, Enterprise Edition ^™ ("J2EE") compliant JVM (eg, J2EE Specification, Version 1.4), native wrapper 210 is commonly referred to as "JLaunch." Native wrapper 210 is native machine code (eg, compiled C++) executed and managed by OS 205 . When started, native wrapper 210 creates VM 105 within itself.

During operation, the illustrated embodiment of VM 105 includes internal storage buffer 220, internal application programming interface ("API") 225, native API 230, heap 235, heap manager 237, garbage collector 240, input/ An output ("I/O") system 243, and a number of threads 245 that maintain information associated with various tasks currently being executed by VM 105 (eg, programs 110, garbage collector 240, etc.). Thread 245 is not shown in all executable entities of FIG. 2 in order to make FIG. 2 appear less crowded and not to obscure the invention. Internal storage buffer 220 is used by VM 105 to store state information 125 collected from various internal components of VM 105 during operation of VM 105. Internal API 225 provides access to internal storage buffer 220 by various internal components of VM 105. In embodiments where VM 105 is a JVM, internal API 225 is referred to as the "Java API". Native API 230 provides entities external to VM 105 access to internal memory buffer 220, thereby providing access to status information 125 for monitoring the internal operation of VM 105 from an external vantage point. Native API 230 enables native machine code entities, such as native VM monitor 215, to access internal memory buffer 220 without being interpreted and executed on VM 105 itself. Although FIG. 2 illustrates that the native VM monitor 215 is internal to the native wrapper 210 , in some embodiments the native VM monitor 215 may also be external to the native wrapper 210 .

Heap 235 is established by VM 105 as a pool of reserved memory for future use by programs 110 and VM monitor program 250 (discussed in detail below) as they are loaded. The heap 235 is managed by the heap manager 237 of the VM 105 for allocating and deallocating memory when requested by the program 110, and for storing objects 255 created by the program 110 (or the VM monitor program 250).

In embodiments where programs 110 are object-oriented programs (eg, Java programs), they generally include objects and classes. When program 110 is loaded and executed by VM 105, object 255 is created and then stored to heap 235. Classes include methods that perform tasks and return information when they complete those tasks. Objects are essentially reusable software parts that simulate pieces of a software program in terms of characteristics and behavior. Classes are used to instantiate objects with these properties and behaviors. In other words, each object 255 inherits their properties and behavior from the class that instantiated (eg, created) the particular object 255 .

As program 110 consumes heap 235 by adding objects 255 to heap 235, memory in heap 235 that can accept new objects may become scarce. Thus, the garbage collector 240 implements a disciplined procedure for returning consumed memory to the heap 235 . In one embodiment, the garbage collector 240 is executed automatically by the VM 105 to reclaim dynamically allocated memory without requiring explicit instructions from the programmer of the program 110 to execute. When there are no longer references to an object 255 in the heap 235, the particular object 255 is marked for garbage collection. Then, when the garbage collector 240 executes, the memory consumed by the marked objects 255 is reclaimed. Regularly performing garbage collection can help avoid resource leaks when available memory in the heap 235 becomes scarce.

However, when available memory in the heap 235 becomes scarce, the performance of the VM 105 can suffer due to garbage collection activity. For example, if the heap 235 exceeds 80% capacity, the garbage collection activity of the garbage collector 240 can cause the computational output (eg, output 120 , see FIG. 1 ) that the VM 105 can produce to be compacted to a near halt. While the garbage collector 240 does a relatively good job of removing unreferenced objects 255 to reclaim consumed memory, not all free objects 255 are reclaimed for various reasons. Therefore, the older (older) VM 105 is more likely to be damaged during a lengthy garbage collection event.

In one embodiment, various entities of VM 105 are "instrumented" with monitoring code to accumulate/generate at least a portion of state information 125 and copy the portion of state information to internal memory buffer 220. Execution of the monitoring code may be interleaved with execution of the entity's regular program code. A portion of the state information 125 accumulated/generated by the monitored code may include when processing for each entity started and stopped, processing elapsed time for each thread 245 executing the entity, number of objects 255 created by a particular entity, memory consumed by the entity amount, and so on. Each entity is equipped to accumulate and/or generate various state information 125 related to the operation and execution of the particular entity. These entities may include garbage collector 240, heap manager 237, I/O system 243, and the like. The monitoring code installed in each of these entities has the purpose of collecting at least a portion of the vast amount of state information available in VM 105 and reporting it to internal memory buffer 220.

In one embodiment, garbage collector 240 is equipped with monitoring code 265 to accumulate/generate at least a portion of state information 125 and copy the portion of state information 125 to internal storage buffer 220 . Execution of monitoring code 265 may be interleaved with execution of regular garbage collection activities by garbage collector 240 . In one embodiment, monitoring code 265 is executed in response to a garbage collection event. A portion of status information 125 accumulated/generated by monitoring code 265 includes various garbage collection related information. Such garbage collection related information may include: timestamps and elapsed times of garbage collection events performed by garbage collector 240, counts of garbage collection events, counts of the number of objects 255 collected from heap 235 during each garbage collection event , the amount of memory reclaimed in the heap 235 during each garbage collection event, the amount of memory available in the heap 235, the hit ratio of objects 255 in the heap 235 by the requestor (e.g., the programmer 110), the Utilization etc. Furthermore, monitoring code 265 may maintain a history of recent garbage collection events in internal storage buffer 220 and index each garbage collection event into some or all of the aforementioned garbage collection-related information.

In one embodiment, a VM monitor 250 may be interpreted and executed on the VM 105 with the primary purpose of collecting state information 125 and copying the state information 125 to the internal storage buffer 220. A VM monitor program 250 may be provided separately to perform monitoring duties. VM monitor program 250 may collect/generate some or all of the status information 125 described above, as well as other monitoring information. Writing a separate program dedicated to the monitoring task allows the monitoring program to be written long after the program 110 and garbage collector 240 are designed without requiring the program 110 and garbage collector 240 to be updated. VM monitor program 250 enables developers to create special monitor programs to investigate problems or "bugs" in VM 105 or program 110 until after VM 105 and/or program 110 have been written and released to the public only became obvious. In fact, many software problems do not become apparent until the software build is released to a larger user base. Accordingly, VM monitor 250 may be designed to aid in alpha testing of program 110 and/or VM 105, or even be included in a beta release of program 110 and/or VM 105. VM Monitor 250 provides an efficient mechanism for implementing monitoring code that is later developed for execution on VM 105.

Monitoring code and VM monitor program 250, including monitoring code 265, accesses internal storage buffer 220 through internal API 225 to copy state information 125 therein. In one embodiment, the internal API 225 abstracts access to the internal storage buffer 220 using function calls. Each component of VM 105 that wants to copy state information 125 to internal storage buffer 220, "calls" one or more functions internally published to VM 105 via internal API 225, and transfers the accumulated/generated Status information 125 is passed to the calling function. The called function then copies the state information 125 to the appropriate slot or location in the internal memory buffer 220 .

The native VM monitor 215 acts as a proxy for various external entities (eg, the monitoring station 115), requesting access to the internal storage buffer 220 to monitor the internal operation of the VM 105. In one embodiment, native VM monitor 215 may receive status request 130 and provide status information 125 or a portion thereof in response. Alternatively, or additionally, the native VM monitor 215 may negotiate a reporting contract with the monitoring station 115 to provide status information 125 on a regular or periodic basis without requiring a status request 130 . Therefore, the local VM monitor 215 can either push the status information 125 to the monitoring console 115 or the monitoring console 115 can pull the status information 125 from the local VM monitor 215 .

Using the internal API 225 to abstract access to the internal storage buffer 220, the content of the internal storage buffer 220 can be isolated from the rest of the VM 105, thereby protecting the content of the internal storage buffer 220. Even if the VM 105 crashes, enters an infinite loop, or otherwise fails, the state information 220 can be protected from damage by the failure. Since the native API 230 is executed using native code, the native API 230 is not interpreted and executed by the VM 105. Thus, if a VM 105 fails, the native VM monitor 215 can still access the internal storage buffer 220 to obtain the latest state information just updated before the VM 105 failed. Accordingly, the contents of internal storage buffer 220 may be retrieved for postmortem investigation to determine the cause of VM 105 failure.

FIG. 3 is a flow diagram illustrating a process 300 for monitoring the internal operations of VM 105, according to one embodiment of the invention. At processing block 305, program 110 is interpreted and executed on VM 105. In a Java embodiment, program 110 is Java bytecode that is interpreted and converted to native machine code in real time. The translated machine code is then executed.

During execution of the program 110, the monitoring code updates the internal storage buffer 220 with state information 125 pertaining to the operation of the particular program 110, the resource consumption of the particular program 110, and other internal workings of the VM 105 (processing block 310). As noted above, the monitoring code may execute in an interleaved fashion with the program code of various sub-entities within the VM 105. In one embodiment, the monitoring code invokes the internal storage buffer 220 through a function call to the internal API 225 and passes the collected/generated state information 125 to the called function.

As program 110 executes, object 255 is created and stored to heap 235 (processing block 315). As long as the heap 235 has memory available to store the new object 255, the program 110 will continue to execute and create the new object 255 as needed. However, if the heap 235 is approaching its capacity, and the available memory in the heap 235 to accept the new object 255 becomes scarce (decision block 320 ), then process 300 continues to processing block 325 .

At processing block 325 , garbage collector 240 performs automatic garbage collection to delete unreferenced objects 255 and reclaim memory consumed in heap 235 . As noted above, in response to a garbage collection event, monitoring code 265 updates internal storage buffer 220 with state information 125 containing garbage collection information (processing block 330). In one embodiment, monitoring code 265 accesses internal storage buffer 220 through function calls to internal API 225.

At processing block 335, the native VM monitor 215 retrieves some or all of the state information 125 from the internal storage buffer 220 via the native API 230. In one embodiment, the native VM monitor 215 invokes the internal memory buffer 220 through a function call to the native API 230. In processing block 340 , the retrieved status information 125 is transmitted to the monitoring station 115 . As described above, status information 125 can be pushed to the monitoring station 115 , or can be pulled from the native VM monitor 215 by sending a status request 130 . The monitor station 115 may execute on the same hardware as the VM 115 is executing, or on remote hardware communicatively coupled to the local VM monitor 215 via a network or other communication medium.

FIG. 4 is a block diagram illustrating a demo enterprise environment 400 for implementing an embodiment of the present invention. The illustrated embodiment of the enterprise environment 400 includes a coupling cluster 405 to service requests from client nodes 410 . Cluster 405 may include: one or more service nodes 415 each supporting one or more application server ("AS") instances 417; message server nodes 420 supporting message server 422; database nodes 425 , support database 427; and network dispatcher (dispatcher) 430.

The AS instance 417 may be a network application server, such as SAP's network AS, Microsoft's .NET, and so on. Each AS instance 417 may include one or more VMs 105 to execute programs 110. Programs 110 executed by VMs 105 within AS instance 417 may collectively provide logic for implementing various sub-layers of AS instance 417 (eg, business layer, integration layer, presentation layer, etc.). It should be understood that various components of AS instance 417 have been excluded from FIG. 4 for the sake of clarity so as not to obscure the invention. In one embodiment, VM 105 may be a JVM conforming to the J2EE standard to execute Java programs. In one embodiment, VM 105 may conform to the .NET framework from Microsoft to execute .NET programs. The AS instance 417 may even include a VM 105 that complies with both the J2EE standard and the .NET framework.

Network distributor 430 implements a load balancing mechanism that distributes service requests from client nodes 410 among server nodes 415 in cluster 405 . For example, network distributor 430 implements a round-robin load balancing mechanism or similar mechanism. The network distributor 430 may be one of the server nodes 415 having the task of distributing service requests among the server nodes 415 of the cluster 405, or an independent hardware node. Service requests are processed by server nodes 415 and then provided to database nodes 425 . Database node 425 provides the requested data to server node 415 , which in turn processes and formats the results for display on client node 410 . Each AS instance 417 also includes its own allocator mechanism to distribute service requests assigned to it among its various VMs 105.

In embodiments where VM 105 is a JVM, program 110 may be a servlet that provides server-side logic to generate a graphical user interface ("GUI") on client node 410, and may also include A Java Server Pages ("JSP") serving dynamic content in the GUI. Program 110 may also include business applications providing business logic of Enterprise JavaBean ("EJB"), applets providing client logic, and the like.

A client node 410 may execute the monitoring console 115 to provide remote monitoring of the AS instance 417, particularly of each VM 105. If an IT technician notices that one of the VMs 105 has low heap utilization, overly active garbage collection activity, etc., the IT technician can take appropriate action, including resetting the offending VM 105.

5 is a block diagram illustrating an exemplary processing system 500 for executing any of VM 105, software environment 200, process 300, or for implementing client node 410, server node 415, message server node 420, or Any of the database nodes 425. The illustrated embodiment of processing system 500 includes one or more processors (or central processing units) 505, system memory 510, non-volatile ("NV") memory 515, DSU 520, communication link 525, chipset 530. The illustrated processing system 500 may represent any computing system, including desktop computers, notebook computers, workstations, handheld computers, servers, blade servers, and the like.

The elements of processing system 500 are interconnected as follows. Processor 505 is communicatively coupled to system memory 510, NV memory 515, DSU 520, and communication link 525 through chipset 530 to send instructions or data to or receive instructions or data from them. In one embodiment, NV memory 515 is flash memory. In other embodiments, NV memory 515 includes any of read only memory ("ROM"), programmable ROM, erasable programmable ROM, electrically erasable programmable ROM, and the like. In one embodiment, system memory 710 includes random access memory (“RAM”) such as dynamic RAM (“DRAM”), synchronous DRAM (“SDRAM”), double data rate SDRAM (“DDR SDRAM”) ”), Static RAM (“SRAM”), etc. DSU 520 represents any storage device for software data, applications, and/or operating systems, but is most typically a non-volatile storage device. The DSU 520 optionally includes one or more Integrated Drive Electronics (“IDE”) hard drives, Enhanced IDE (“EIDE”) hard drives, Redundant Array of Independent Disks (“RAID”), Small Computer System Interface (“SCSI”) hard disk, etc. Although DSU 520 is shown as being internal to processing system 500, DSU 520 may also be coupled externally to processing system 500. Communication link 525 couples processing system 500 to a network so that processing system 500 can communicate with one or more other computers over the network. Communications link 525 may include a modem, Ethernet card, Gigabit Ethernet card, Universal Serial Bus ("USB") port, wireless network interface card, fiber optic interface, or the like.

It should be understood that various other elements of processing system 500 have been excluded from FIG. 5 and this disclosure for the sake of clarity. For example, processing system 500 may also include graphics cards, additional DSUs, other persistent data storage devices (eg, tape drives), and the like. Chipset 530 may also include a system bus and various other data buses for interconnecting subcomponents, such as memory controller hubs and input/output ("I/O") controller hubs, and also include data buses such as , peripheral component interconnect bus) for connecting peripheral devices to the chipset 530 . Accordingly, processing system 500 may also operate without one or more of the illustrated elements. For example, processing system 500 need not include DSU 520.

Reference in this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described with respect to the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase "in one embodiment" or "in an embodiment" in various places in the specification are not necessarily referring to the same embodiment. Also, specific features, structures, or characteristics may be combined in an appropriate manner in one or more embodiments.

Process 300 illustrated above is described in terms of computer software and hardware. The described techniques may constitute machine-readable instructions embodied in a machine (eg, computer)-readable medium, which, when executed by a machine, cause the machine to perform the operations described. Furthermore, process 300 may also be embedded in hardware, such as an application specific integrated circuit ("ASIC") or the like. The order in which some or all of the processing blocks appear in process 300 should not be considered limiting. Rather, those of ordinary skill in the art, given the light of this disclosure, should understand that some processing blocks may be performed in various orders not illustrated.

The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to one particular form. In some of the above instances, to avoid obscuring certain aspects, well-known structures, materials or operations have not been shown or described in detail. Specific embodiments, or examples, of the invention are described herein for illustrative purposes, and various equivalent modifications are possible within the scope of the invention, those skilled in the relevant art will recognize.

These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and claims. Instead, the scope of protection of the present invention is determined entirely by the following claims, which should be construed in accordance with the terms determined by the interpretation of the claims.

Claims (23)

1. A method comprising: Operate a virtual machine (“VM”) to interpret and execute a program; during VM operation, storing state information of the VM's internal operations to the VM's internal storage buffer; and During VM operation, the state information is fetched from the internal memory buffer to monitor the internal operation of the VM from outside the VM. 2. The method of claim 1, wherein said VM comprises a Java Virtual Machine ("JVM") and said program comprises Java bytecode. 3. The method of claim 2, wherein storing the state information to an internal storage buffer comprises accessing the internal storage buffer through a Java Application Programming Interface ("API"). 4. The method of claim 2, wherein said JVM is included in an application server instance, and said program comprises an enterprise application that services client requests. 5. The method of claim 1, further comprising: storing objects created during program execution to the heap; and using the automatic garbage collector to garbage collect objects that are no longer referenced by said program, The storing the state information of the VM in the internal storage buffer includes storing the garbage collection activity information in the internal storage buffer. 6. The method of claim 5, wherein the garbage collection activity information includes at least one of runtime of garbage collection, number count of garbage collection events, number of objects collected from the heap, and amount of available memory in the heap. 7. The method of claim 1, wherein extracting state information from an internal memory buffer of the VM comprises: Execute a VM monitor external to the VM to retrieve status information; access the VM through a native application programming interface (“API”); and The state information is retrieved to the VM monitor through a native API. 8. The method of claim 7, further comprising: calling a VM monitor to retrieve state information, wherein the VM monitor includes native machine code not interpreted by the VM; and The status information is transmitted to the monitoring platform for displaying on the monitoring platform. 9. The method of claim 7, further comprising accessing the internal storage buffer following a VM failure to investigate the failure. 10. The method of claim 1 , further comprising interpreting and executing a VM monitor program on the VM, the VM monitor program being dedicated to gathering at least a portion of state information from VM components and storing the portion of state information to an internal memory buffer . 11. A machine-accessible medium providing instructions which, if executed by said machine, will cause the machine to: interpret the program on a virtual machine (“VM”); Generate VM status information from within the VM; storing state information of the VM to an internal memory buffer of the VM during the interpretation of the program; and The state information stored in the internal storage buffer is accessed from outside the VM in order to monitor the internal operation of the VM. 12. The machine-accessible medium of claim 11, wherein said VM comprises a Java Virtual Machine ("JVM") and said program comprises Java bytecode. 13. The machine-accessible medium of claim 12, wherein storing the state information to the internal storage buffer comprises accessing the internal storage buffer through a Java Application Programming Interface ("API"). 14. The machine-accessible medium of claim 13, wherein the Java API isolates internal storage buffers from damage in the event of a VN failure. 15. The machine-accessible medium of claim 11 , wherein generating the state information of the VM comprises executing monitoring code embedded in a sub-entity of the VM to obtain the state information, and wherein storing the state information to the internal storage buffer comprises, Monitoring code is executed to store the state information to an internal memory buffer. 16. The machine-accessible medium of claim 15 , further providing instructions which, when executed by said machine, will cause the machine to further perform the following operations: The monitoring code and program code of sub-entities are interleavedly executed, wherein the sub-entities include one of a heap manager and an input/output system. 17. The machine-accessible medium of claim 11 , further providing instructions which, when executed by said machine, will cause the machine to further perform the following operations: store objects created by the program on the heap; and utilize the automatic garbage collector to garbage collect those objects that are no longer referenced by the program, The storing the state information of the VM in the internal storage buffer includes storing the garbage collection activity information in the internal storage buffer. 18. The machine-accessible medium of claim 17 , wherein the garbage collection activity information includes elapsed time of garbage collection, a count of the number of garbage collection events, the number of objects collected from the heap, and the amount of available memory in the heap. at least one. 19. The machine-accessible medium of claim 11 , wherein accessing state information from outside the VM comprises: Executing a VM monitor external to the VM; and Status information is retrieved from the internal memory buffer through function calls to the native application programming interface. 20. A system comprising: A server node that executes an application server ("AS") instance that includes logic executable by the server node's processor to: interpret the program on a virtual machine (“VM”); Generate VM status information from within the VM; storing state information of the VM to an internal memory buffer of the VM during the interpretation of the program; and The state information stored in the internal memory buffer is accessed from outside the VM in order to monitor the internal operation of the VM. 21. The system of claim 20, wherein said VM comprises a Java Virtual Machine conforming to the Java 2 Enterprise Edition standard, and said program comprises a Java program. 22. The system of claim 21 , wherein the logic executable by a processor of a server node to generate status information for a VM comprises monitoring code embedded in an automatic garbage collector executed to reclaim VMs that are no longer Heap memory consumed by objects referenced by Java programs. 23. The system of claim 21, further comprising: A client node, executing a monitoring console comprising logic executable by a processor of the client node, including: Send a status query to the server node; receiving status information from a server node in response to a status query; and Display the status information.

Images