US20050086662A1 - Object monitoring system in shared object space - Google Patents
Object monitoring system in shared object space Download PDFInfo
- Publication number
- US20050086662A1 US20050086662A1 US10/690,783 US69078303A US2005086662A1 US 20050086662 A1 US20050086662 A1 US 20050086662A1 US 69078303 A US69078303 A US 69078303A US 2005086662 A1 US2005086662 A1 US 2005086662A1
- Authority
- US
- United States
- Prior art keywords
- shared
- object space
- space
- shared object
- virtual machine
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000012544 monitoring process Methods 0.000 title abstract description 14
- 238000000034 method Methods 0.000 claims description 54
- 238000004883 computer application Methods 0.000 claims description 32
- 238000012545 processing Methods 0.000 claims description 23
- 230000001360 synchronised effect Effects 0.000 claims description 5
- 238000004590 computer program Methods 0.000 description 12
- 230000008901 benefit Effects 0.000 description 7
- 230000006872 improvement Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 5
- 230000009471 action Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000014509 gene expression Effects 0.000 description 2
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 description 2
- CCEKAJIANROZEO-UHFFFAOYSA-N sulfluramid Chemical group CCNS(=O)(=O)C(F)(F)C(F)(F)C(F)(F)C(F)(F)C(F)(F)C(F)(F)C(F)(F)C(F)(F)F CCEKAJIANROZEO-UHFFFAOYSA-N 0.000 description 2
- 239000011800 void material Substances 0.000 description 2
- 230000002411 adverse Effects 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003090 exacerbative effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
Definitions
- the present invention relates to a system for monitoring an object space shared among plural applications.
- Computer hardware and storage media can only create, store, and process binary information, i.e. information written using only two digits, “0” and “1”.
- a compact disc for example, has a surface subdivided into tiny sections that are either pitted (1) or not pitted (0) such that a laser can detect the presence or absence of pits.
- microprocessors have inputs and outputs to which a reference voltage either is (1) or is not (0) present.
- any computer program, as well as any data used in that computer program, must first be expressed in binary code for a computer to run the program or process the data.
- binary code is conceptually simple, its use to perform computerized tasks introduces two drawbacks.
- binary code is a relatively inefficient way to express information.
- the number “100” in decimal notation is expressed as “1100100” in binary code, and therefore must at a minimum occupy seven “pits” on a compact disc and/or occupy either a single input of a processor for seven cycles (if entered serially) or seven inputs for one cycle (if entered in parallel).
- bits the space that a piece of information occupies, or alternatively the number of time cycles a piece of information occupies. That is to say, the number “100” is a 7-bit number because it takes seven digits to express in binary code.
- the number “101” is also a 7-bit number, coded as 1100101, as is every number between “64” (1000000) and “127” (1111111).
- binary code is even more inefficient because computerized information is, by convention, typically expressed in multiples of 8 bits, e.g. 8-bit, 16-bit, 24-bit, etc.
- the reason for this convention is that a computer processing or storage device has no physical way of distinguishing when one number ends and another number begins. Accordingly, the convention is to write a program that specifies the bit-rate, i.e. the number of bits that each piece of data processed in the program will occupy. If a program is written in 8-bit code, for example, every piece of data occupies eight bits, e.g. the number 0 is coded as 00000000, the number 1 is coded as 00000001, and the number 255 is coded as 11111111.
- every piece of data has a value between 0 and 255 and every piece of data occupies 8 bits even if it could theoretically be represented by a single bit. If a program requires that any piece of data take on a value greater than 255, the bit-rate for the program must be increased incrementally to 16-bit, 24-bit, etc. as appropriate.
- a computer program operating in binary code may therefore use a tremendous amount of storage space and processor cycles, particularly when graphics are involved.
- a photographic quality image is often coded at 24-bits for every pixel. If the image resolution is 2 million pixels, as is common with today's digital cameras, each image would occupy 48 million bits, or 4 Megabytes, where a byte is defined as 8 bits per byte (due to the convention of expressing binary code in multiples of 8 bits). Manipulating that image would similarly require 48 million cycles of processor time for each manipulation.
- the amount of storage space and processing time increases exponentially when manipulating video because the computer system must process and store many such images every second.
- there are many other computer applications that are at least as intensive as image processing. Applications of such intensity tend to slow considerably as data is “bottlenecked” in the computer system.
- Another way of minimizing the impact of the inefficiency of binary code is to write computer programs and applications as efficiently as possible. Thus there is always an emphasis on writing computer code that achieves its outcome in as few steps or calculations as possible. Similarly, a computer program should not be written in 24-bit code when only 8-bit code is required for the application, and the computer program may compress data when appropriate.
- a second drawback of using binary code to perform computerized tasks is that it is impractical to write a computer program in binary code, particularly with complex programs.
- the first rudimentary computers for example, were operated by mechanically toggling electrical switches between on and off states to enter a sequence of binary instructions.
- Computer programs simply specified the sequence of binary instructions to enter. This method was feasible so long as the program was no more than about a hundred instructions long. Beyond that point, programming directly in binary code became too complex, and programs too difficult to correct, or debug.
- the binary instructions were dependent upon the particular electrical circuitry of the computer processor and related hardware, the programmer was required to know in detail the particular architecture of the computer being used by the program.
- object-oriented programming approaches a programming task in roughly the same way that a person's mind might approach that task—by abstracting a solution.
- an object-oriented program focuses first on a program's data, defining classes of data and objects, where an object is a particular instance of a class.
- An object-oriented oriented program still contains instructions, referred to as methods, which often are embedded within the classes or objects themselves.
- a box class is first defined having the variables of width, height, and depth (the term “double” identifies the type of number that the variable is allowed to be).
- the box class also defines a method to display the volume of an object box of this class by multiplying width by height by depth.
- the program defines a second class BoxDemo which includes two objects of the initial box class.
- the class BoxDemo then twice calls the method of the first box class for displaying the volume of a box, once to display the volume of mybox 1 and once to display the volume of mybox2.
- Java is the programming language used in the foregoing example.
- Java is the programming language used in the foregoing example.
- the reason Java has become so popular is its versatility in defining classes and objects, as well as its ability for one class or object to call functions in other classes and objects as well as to reuse data in other objects simply by referencing the function or the data. In Java, therefore, it is very easy to create multiple variations of a defined class, to create new variations of an old class, and to reuse a method previously defined by one class in a new class.
- C++ another object oriented programming language that has become popular is C++, which expands C to include the functionality of both object oriented programming and the instruction oriented programming of C.
- Java like any other programming language relies upon an interface to convert the program to the required binary instructions. With Java, this interface is called a “Virtual Machine” (VM) because the interface behaves as if it were a computer unto itself. Every time a Java based computer application is initiated, the application initiates a VM to run the application.
- VM Virtual Machine
- the Java VM will be described in much greater detail later in this specification, but several important principles will be introduced now.
- the output of a Java VM is customized to the particular platform, or operating system, that hosts the Java VM. In other words, every Java application must be customized to the host operating system so that the VM that it creates is capable of converting the Java programming language to the commands unique to the host operating system, which in turn issues the appropriate binary instructions to the computer.
- Java VMs are designed to be independent of one another. If two Java applications are running on the same computer, each application creates its own VM which is self sufficient, i.e. neither VM needs rely upon the VM of the other application. If one application should close, the other application will not be affected. This often becomes problematical, however. Recall that even with today's processors and storage devices, a computer's resources may still be strained by intensive applications. With multiple Java applications running simultaneously, each creating its own VM, system resources may be strained and slowdowns may result. In other words, there is often a trade off between the desired independence of multiple Java applications and the speed at which the applications may run.
- Sun Microsystems's Java VM is uniform across all platforms, an industry has blossomed by which Java applications may be truly customized to a host operating system whereby the features of the host operating system are more fully exploited, and custom tailored to the particular needs of the business or person running the application.
- an improved system for implementing object-oriented computer applications that both efficiently allocates computer hardware resources among multiple computer applications running simultaneously on the same computer or network of computers, or among multiple threads of a single computer application running on a computer or network of computers, while also preserving the independence of multiple, simultaneous applications.
- an improved system that is sufficiently flexible so as to be compatible not only with the diverse range of existing object-oriented computer applications, but also with object-oriented applications that are developed or modified in the future.
- FIG. 1 is a simplified architectural schematic of an existing VM.
- FIG. 2 is an expanded architectural schematic of the VM of FIG. 1 showing a memory region interposed between the class loader and the execution engine.
- FIG. 3 is a schematic of the heap shown in FIG. 2 .
- FIG. 4A is a diagram showing a prior art system for operating multiple VM applications on a host computer.
- FIG. 4B is a diagram showing a prior art system for the simultaneous operation of multiple instances of a VM application on several host computers connected through a network or internet server.
- FIG. 5 is a diagram showing a first improved system for operating multiple VM applications on a host computer.
- FIG. 6 is a diagram showing a first manner in which objects may be shared between applications using the system of FIG. 5
- FIG. 7 is a diagram showing a second manner in which objects may be shared between applications using the system of FIG. 5
- FIG. 8 is a second improved system for operating multiple VM applications on a host computer.
- FIG. 9 is an improved system for the simultaneous operation of multiple instances of a VM application on several host computers connected through a network or internet server.
- FIGS. 10 and 11 show a system for monitoring a shared object space to collect, store, graphically display, and analyze statistical or other data pertaining to the shared object space.
- FIGS. 1-4B show a simplified architectural schematic of an existing Java VM 10 , although it should be understood that other types of VMs besides Java may also have the features shown in FIGS. 1-4B .
- VM Java virtual machine
- FIG. 1 indicates a single class loader, in actuality, a Java VM may include multiple class loaders.
- the class loader 16 may be considered a subsystem that may involve many class loaders.
- the Java VM 10 has a flexible class loader architecture that enables a Java application to load classes in custom ways.
- the class loader 16 may comprise a system class loader and one or more user-defined class loaders.
- the system class loader is a part of the Java VM implementation and loads classes, including the Java application programming interface (API) class files 20 , in some default way and usually from the local disk of the host computer.
- API Java application programming interface
- the particular default manner in which the system class loader loads classes is specific to the particular VM implementation being used and may be customized.
- system class loader is sometimes referred to as a “primordial class loader”, a “bootstrap class loader”, or a “default class loader.”
- a Java application may also load application class files 22 in custom ways through user-defined class loaders, such as by downloading class files across a network. While the system class loader is an intrinsic part of the VM implementation, the user-defined class loaders are not. Instead, user-defined class loaders are written in Java, compiled to class files, loaded into the virtual machine, and instantiated just like any other object, becoming a part of the executable code of a running Java application.
- User defined class loaders enable a programmer to dynamically extend a Java application at run time. As the application runs, it can determine what extra classes are needed and load them through one or more user-defined class loaders. Because the user defined class loaders are written in Java, classes can be loaded in any manner expressible in the Java programming language.
- the virtual machine 10 For each class loaded by the virtual machine 10 , the virtual machine 10 records which class loader loaded the class. When a loaded class refers to another class, the virtual machine 10 requests the referenced class from the same class loader that originally loaded the referencing class. For example, if the virtual machine 10 loads the class “Volcano” through a particular class loader, it will attempt to load any classes to which Volcano referred with the same class loader. In this way, Java's architecture enables a programmer to create multiple “name spaces” inside a single Java application. Each class loader in the executing Java application has its own name space, which is populated by the names of all the classes it has loaded.
- the execution engine 18 executes instructions contained in the methods of loaded classes in “bytecode”, essentially Java's machine language.
- the Java specification describes what is to result from a given instruction retrieved from a Java method, but a programmer of a Java application determines the best way of achieving the result using software, hardware, or a combination of both.
- the execution engine 18 is an abstraction; Java is a programming language capable of simultaneously running multiple threads, i.e. distinct paths of execution, hence the execution of each thread can be considered an “instance” of the abstract execution engine 18 . Thus at any given time, there may be multiple “instances” of the execution engine 18 .
- the execution engine 18 receives a bytecode stream of instructions in a thread and executes the thread one instruction at a time.
- the execution engine 18 executes the actions requested by each thread, and whenever intended by the Java application, sends instructions to the operating system in the code that the operating system recognizes. From time to time, the execution engine 18 might encounter an instruction that requests a method written in some other language than Java, referred to as a “native method.” On such occasions, the execution engine 18 will attempt to invoke that native method by accessing native method libraries 36 through a native method interface 34 (shown in FIG. 2 ). When the native method returns, the execution engine 18 will continue executing the next instruction in the bytecode stream.
- the Java virtual machine 10 When the Java virtual machine 10 runs an application, it needs memory to store many items, including information it extracts from class files, objects that the program instantiates, parameters to methods, return values, local variables, and intermediate results of computations.
- the Java VM 10 organizes the memory it needs to execute a program into several runtime data areas, depicted in FIG. 2 . These runtime areas may include a method area 24 , a heap 26 , one or more Java stacks 28 , one or more program counter (PC) registers 30 , and one or more native method stacks 32 .
- PC program counter
- Each instance of a Java VM 10 has one method area 24 and one heap 26 . These areas are shared by all threads running inside the VM 10 . As each thread comes into existence, it receives its own PC register 30 and Java stack 28 . When the VM 10 runs a method contained in a thread, several things happen. First, the value of the PC register is used to tell the next instruction in the method's sequence to execute. Second, the thread's java stack 28 stores the state of each executing Java method in a stack frame, which includes the thread's local variables, the parameters with which it was invoked, its return value if any, and intermediate calculations.
- the VM 10 When the VM 10 has invoked a method in a thread and that method subsequently completes, the VM 10 discards the stack frame for that method from the Java stack 28 .
- the state of native method invocations is stored in the native method stack 32 in a manner dictated by the designer of the Java VM 10 .
- a data type refers to the format in which the data is expressed, e.g. an integer, a float, etc.
- a data type could also be an address of an op code within a method or a reference to an object on the heap 26 .
- the VM 10 uses the type information stored in the method area 24 as it executes the application it is running.
- the VM 10 For each data type the VM 10 loads, it should store the following kinds of information in the method area: (1) the fully qualified name of the type; (2) the fully qualified name of the type's superclass; (3) whether or not the type is a class or an interface; (4) the type's modifiers; (5) an ordered list of the fully qualified names of any direct superinterfaces; (6) the constant pool for the type; (7) field information; (8) method information; (9) all class variables declared in the type except constants; (10) a reference to class CLASSLOADER; and (11) a reference to class CLASS.
- Each of these kinds of information is well known to those in the art who design Java virtual machines and program in Java.
- the existing Java VM 10 has several disadvantages. First, it is inherently redundant. Referring to FIGS. 4A and 4B , a single computer when running multiple Java applications (or other applications that run in a VM) must create a separate VM for each application. Each VM, in turn, generates its own method area, heap, PC register, etc., using a good deal of the resources of the underlying computer. This is true even when each VM is running a separate instance of the same application where many of the objects created by the application will be identical. This is illustrated in FIG. 4B where three computers 46 , 48 , and 50 are running the same application 54 through a server 52 . In this instance, many of the runtime data areas may be located on the server 52 , creating the same kind of redundancy as seen in FIG. 4A .
- FIG. 5 shows an improved system for running VM applications, which broadly stated may comprise a shared object space 100 and a native access layer 102 operably connectable with a plurality of application programming interfaces (API) 104 , 106 of independent VMs or other applications such as the C/C++ application 112 .
- the access layer 102 permits each application 112 , 114 , through its associated, API 104 , 106 to load objects 108 into the shared object space 100 where the objects 108 may be read and/or modified by the particular applications 112 , 114 .
- the shared object space 100 permits an application to store an object 108 in the shared object space 100 instead of its own heap or other memory area, thus avoiding the redundancy of existing VM systems.
- Access to the objects 108 in the shared object space 100 may be synchronized using the methods that presently exist for controlling access to shared objects in a heap by multiple concurrently running threads. Further, the shared object space 100 will store an object 108 so long as a thread of any connected application is using the object 108 . In this manner, even if the application that placed a particular object in the shared object space 100 closes or crashes, that object will still be available to other applications as necessary.
- the shared object space 100 permits multiple applications running simultaneously on a system or network to enjoy the stability of existing VM systems, while providing a substantial boost in performance.
- the shared object space 100 is accessible to an application through the native access layer 102 .
- a Java application or other object oriented application will recognize the shared object space 100 as simply another native method accessible through the interface that already exists in Java and other object-oriented applications. Once accessed, all the functionality of the shared object space 100 will be instantly accessible to the connected application.
- the shared object space 100 does not need to be tied to a particular VM, but instead is backwards compatible with any individual VM, whether it is a standard Java VM provided by Sun Microsystems or a customized VM of a particular business, and forwards compatible with any VM including improvements that have yet to be developed. Thus the versatility of the shared object space 100 can not be overstated.
- the versatility of the shared object space 100 is furthered by its compatibility with a wide variety of application interfaces.
- the native access layer 102 provides access to the shared object space 100 by both Java applications and C or C++ applications. It should be understood that these examples are illustrative only, and that the native access layer 102 could provide access to the shared object space 100 by a number of other application types, whether object-oriented like Java or command oriented like C or C++.
- the advantages of the shared object space 100 are readily apparent, particularly with respect to applications that benefit from the ability of multiple, simultaneously running applications to update a shared object rather than simply read or copy a shared object.
- One such application might be online trading.
- trading exchanges are faced with ever-growing volumes of market data and concurrent trader activity.
- Systems that were built to handle moderate volumes now have to handle thousands of traders and billions of dollars in daily transactions.
- Such systems have to accommodate huge spikes in demand. For instance, a single trade may require thousands of traders to be notified. Many traders watch for these price changes, then jump in to sell or buy very quickly, causing even more notification demand and more trading volume.
- the faster a trading system reacts to changes the more transactions an exchange can execute, increasing its commissions while maximizing trader satisfaction with the service.
- Another example of the utility of the shared object space 100 might be its potential in improving speed of computerized activity in the telecommunications industry.
- Modem telecommunication networks have to process vast amounts of data very quickly. Every time a call is placed, for example, an application needs to access the customer's subscription information, apply any special discounts that may be applicable, monitor the call duration and establish a rate based on the time and distance to the terminating number. Given that the number of such calls can run into the thousands at any given moment, a memory based data sharing facility is a necessity. In the past, such telecommunications applications have been written from scratch in C at enormous expense.
- the availability of an off-the-shelf shared memory component that provides a shared object space 100 makes it possible to write such systems in Java or another object-oriented program more quickly, cheaply, and with less risk.
- the shared object space 100 provides an ideal caching facility for HTML and XML fragments, XML DOMs and streams, HTTP session information, and JDBC query results. It can also hold very fast page request queues and other operational data structures.
- the shared object space 100 may include multi-language support which may be exploited when connected to web servers, servlet engines, content management suites, and XML transcoders to speed up every phase of a sites operation.
- the shared object space 100 may be one element in a larger computing system 101 .
- the shared object space 100 along with its associated native access layer 102 may be used in conjunction with a console 118 , an administrative processor 120 , disk storage 122 and a display 124 suitable for displaying system statistics.
- the console 118 is used to configure and start the system 101 which may comprise a system manager 126 , the shared object space 100 , and the native access layer 102 .
- the system manager 126 creates and initializes the shared object space 100 , collects garbage, gathers statistics, and logs both system and user-defined events.
- the system manager 126 can also be used to browse the shared object space 100 , enable statistics collection from individual objects, and display the statistics graphically for analysis.
- the system 101 is preferably stored on a disk 122 in a default directory, e.g. “defaultSystem”, that holds the system's configuration file and log file.
- the system 101 may be included on an executable storage media such as a compact disk that include an installation tool that may be used to create the requisite directories on the disk 122 . Additional custom system directories may also be installed on the same disk 122 as desired.
- the system 101 includes a number of default tools that operate on the default system; however the console 118 and a command line utility may allow the user to specify a different system.
- the system 101 includes a library file in the default directory.
- Java applications should include a reference to this library (e.g. productdir/lib/gemfirejar) on its CLASSPATH.
- the library may be made available by adding productDir/bin to PATH and on Solaris, the library can be made available by adding productDir/lib to LD_LIBRARY_PATH.
- the system manager 126 then returns information that enables the application process to map the shared object space 100 into its address space.
- Each system 101 preferably maintains a global name space 116 in the shared object space 100 .
- the name space 116 provides a fast object registry in which applications can register and look up “root” objects by name. Objects that are referenced from this name space are protected from garbage collection.
- Stock myStock (Stock) myConn.lookup(“GSI”)
- a shared object like myStock always represents a current shared value; that is all threads in all VMs always see the same field values, just as all threads in a single VM see the same volatile field values for an object in that VM.
- the system 101 may include a Class Enhance tool that prepares an application class for sharing by modifying the class's bytecodes to provide transparent instantiation in shared memory and automatic read-through and write-through for field access methods.
- a Class Enhance tool that prepares an application class for sharing by modifying the class's bytecodes to provide transparent instantiation in shared memory and automatic read-through and write-through for field access methods.
- all fields may be shared, but a user may establish more selective policies by providing an XML description of the fields to be shared in each domain class.
- Once a class in enhanced, making an object of that class automatically puts the object into shared memory.
- the system 101 may support two methods of sharing objects, copy sharing and direct sharing.
- An object 128 that is copy shared is allocated twice, once in the local memory of an application and again in shared memory 100 .
- FIG. 6 shows an example of a copy sharing method where application A creates an object 128 in its local address space.
- the object 128 is shared by putting it into the shared name space 116 .
- the object 128 is not immediately written to a field in the shared object space 100 ; instead the object 128 is written to shared memory 100 only after a user “flushes”, i.e. updates the object to a new version, for the first time.
- application B is able to copy the object 128 to its local memory by accessing the shared object 128 by name in the shared name space 116 .
- Application B may modify the copy of the object 128 obtained from shared memory, but may not update the shared version of the object 128 . If application B wishes to see the most recently updated version of the object 128 , a refresh command may be used.
- FIG. 7 shows an example of a direct sharing method, which is a one-space model where some of all of the non-static fields of the shared object 128 reside only in shared memory. Static fields may be kept in the local heap of an application's VM for performance reasons. An assignment to a field of a directly shared object 128 is immediately visible to threads of other applications and each application is able to write to the shared object. When the field is read, the current state in shared memory 100 is returned; there is no need to refresh the local memory.
- FIG. 8 shows another system 201 that includes a shared object space 200 within a first Java VM 202 .
- the first Java VM 202 may include all the elements of a typical Java VM as previously described, i.e. a method area, a class loader, an execution engine, etc.
- the heap of the first Java VM acts as the shared object space 200 so as to be accessible by the execution engine 204 of a second Java VM.
- the first instance of an application may initiate a VM whose heap performs as a shared object space for subsequent instances of applications operating on the same computer.
- the shared object space 200 may have all the functionality of the shared object space 100 previously described.
- FIG. 9 shows another system 301 in which a shared object space 300 resides on a server 302 interconnecting independent computers 304 , 306 , 308 operating on the same or different platforms.
- Each computer 304 , 306 , and 308 is running a VM instance of a single application that reads and/or writes to data in a database on the server 302 .
- the server 302 may include a dynamic database for stock prices in a trading scenario where the connected computers 304 , 306 , and 308 may be used to complete stock transactions through the server using a uniform software package.
- an object space i.e. monitoring the state of a memory space, objects in that space, or methods that use objects in that space
- Two existing methods of monitoring an object space are typically employed.
- applications are programmed to periodically generate messages concerning the state of the objects they create, and these messages are then logged so that statistical data can be gathered relating to the use of those objects.
- This particular method adversely impacts performance, however, and takes up a large amount of disk and/or memory space; hence this method is typically used only for monitoring events that do not lend themselves to numeric representation.
- existing operating systems compile statistics used for monitoring an object space. These statistics, however, are chosen by the vendor of the operating system and cannot be easily customized.
- the disclosed shared object space may be conveniently monitored using a minimal amount of system resources and may be easily customized to suit the needs of a particular user.
- the disclosed system may include a console 402 having a display 404 and an interface such as the alphanumeric keyboard 406 and optionally a mouse 408 .
- the console 402 may be operationally interconnected with an administrative processor 410 and disk storage 412 .
- the console 402 in conjunction with the administrative processor 406 may be defined as an administrative system 401 and used to monitor a shared object space 400 by gathering statistics and providing access to the system and a user-defined event log, as well as monitoring shared object allocation rates, VM connections, lock acquisitions, shared queue sizes, and so on.
- the administrative system 401 may also be used to configure and initialize the shared object space 400 and permits an administrative user to dynamically discover which particular applications are utilizing the shared object space 400 , such as the applications 414 , 416 , and 418 as well as to monitor system health, throughput, and other custom statistics enabled by the application data.
- the administrative system 401 also may provide automated alerts for serious problems so that the console 402 can be used to take corrective action.
- the shared object space 400 may be associated with a distributed group management system having a distributed cache.
- the administrative system 401 preferably uses administrative interfaces in the distributed group management system of the shared object space 400 to become an adjunct member of the cache. This allows the administrative system 402 to make requests in cache nodes, such as gathering a snapshot of current contents of a distributed cache region, taking corrective action on a deadlock alert, gathering statistics for graphing, or requesting log file contents for display.
- the administrative system 401 preferably monitors the shared object space 400 so that any data or object, such as 420 , 422 , 424 , or 426 , in the shared object space 400 can be registered with the administrative system 401 for statistical monitoring and periodic backup to a compressed file on the disk storage 412 .
- the administrative system 401 takes a “snapshot” of all registered statistical data once every second and transfers that statistical data to the disk storage 412 where it can be analyzed later, even after the shared object space 400 no longer exists.
- a selected subset of the “snapshot” can also be simultaneously analyzed visually on the display 404 .
- the frequency of the monitoring system may be adjustable so that a user can cause the administrative system to record statistical data more or less frequently than once per second.
- the administrative system 401 preferably provides a framework for gathering application-defined statistics. For example, an application could identify any numeric field in a shared object class as a statistical field. The administrative system 401 may then immediately sample the field at designated intervals, log the results, and make the numbers available in a graphical tool on the display 404 . For example, if object 424 shown in FIG. 10 as “object R” tracks the number of matches performed by a trading system matching engine, that object might be registered with the statistics service with the command
- FIG. 11 is a simplified schematic of a system 403 for monitoring objects in a shared object space 400 where any application (such as applications 414 , 416 , and 418 ) including an administrative system 401 connected to the shared object space 400 may define what in the shared object space 400 is to be monitored.
- the system 403 includes a shared object space 400 that is being monitored by an administrative system 401 using two monitors 434 and 436 . The number of monitors used may be varied as desired.
- the shared object space 400 includes a monitored object space 428 that selectively contains any desired number of objects to be monitored, such as the objects 420 and 432 .
- the applications 414 , 416 , and 418 , as well as any other applications, including the administrative system 401 , connected to the shared object space 400 may insert references to existing shared objects to be monitored into the monitored object space, such as the objects 430 and 432 .
- the objects 430 and 432 are preferably simply references to shared objects, but in other embodiments may duplicate a shared object, such as 420 , 422 , 424 , or 426 , or may be a specific field in any of the shared objects in the shared object space 400 , or alternatively may be customized to be data or fields of data that pertains in any way to the state of any shared object in the shared object space 400 .
- An application may register an object to be monitored in the monitored object space in any desired manner, such as by making a single call with the object to be monitored as the only argument, inserting the registered monitored object, such as 430 or 432 into the monitored object space 428 .
- the size, or capacity, of the monitored object space 428 may be any desired portion of the shared object space 400 , and may be variable so as to expand or contract as necessary.
- the monitors 434 and 436 each record the state of the data in the monitored object space 428 at a desired frequency.
- the system 403 has a default frequency, such as once per second, which may be adjusted by a user or an application as necessary.
- the monitors 434 and 436 when directed by the administrative system 401 , may store recorded snapshots of the data to storage local to the administrative system 401 for graphical display and analysis in the manner previously described.
- the disclosed system for monitoring objects in a shared object space is highly flexible in that any application using the shared object space 400 , or an administrative user, has the ability to define data that may be monitored or statistics to be compiled. This represents a tremendous advantage over existing systems, such as existing operating systems whereby the vendor of the operating system defined the set of statistics gathered, which could then either not be modified, or only modified after a great deal of effort.
Abstract
The present invention relates to a system for monitoring an object space shared among plural applications.
Description
- The present invention relates to a system for monitoring an object space shared among plural applications.
- Computer hardware and storage media can only create, store, and process binary information, i.e. information written using only two digits, “0” and “1”. A compact disc, for example, has a surface subdivided into tiny sections that are either pitted (1) or not pitted (0) such that a laser can detect the presence or absence of pits. Similarly, microprocessors have inputs and outputs to which a reference voltage either is (1) or is not (0) present. (Microprocessors repeatedly measure the voltage at each input and output at regular intervals, or cycles—hence the speed of a processor is expressed in cycles per second, or “Hertz.”) Accordingly, any computer program, as well as any data used in that computer program, must first be expressed in binary code for a computer to run the program or process the data.
- Though binary code is conceptually simple, its use to perform computerized tasks introduces two drawbacks. First, binary code is a relatively inefficient way to express information. As a simple example, the number “100” in decimal notation is expressed as “1100100” in binary code, and therefore must at a minimum occupy seven “pits” on a compact disc and/or occupy either a single input of a processor for seven cycles (if entered serially) or seven inputs for one cycle (if entered in parallel). In technical terms, the space that a piece of information occupies, or alternatively the number of time cycles a piece of information occupies, is referred to in “bits.” That is to say, the number “100” is a 7-bit number because it takes seven digits to express in binary code. The number “101” is also a 7-bit number, coded as 1100101, as is every number between “64” (1000000) and “127” (1111111).
- In computer applications, binary code is even more inefficient because computerized information is, by convention, typically expressed in multiples of 8 bits, e.g. 8-bit, 16-bit, 24-bit, etc. The reason for this convention is that a computer processing or storage device has no physical way of distinguishing when one number ends and another number begins. Accordingly, the convention is to write a program that specifies the bit-rate, i.e. the number of bits that each piece of data processed in the program will occupy. If a program is written in 8-bit code, for example, every piece of data occupies eight bits, e.g. the number 0 is coded as 00000000, the
number 1 is coded as 00000001, and the number 255 is coded as 11111111. In 8-bit code, therefore, every piece of data has a value between 0 and 255 and every piece of data occupies 8 bits even if it could theoretically be represented by a single bit. If a program requires that any piece of data take on a value greater than 255, the bit-rate for the program must be increased incrementally to 16-bit, 24-bit, etc. as appropriate. - A computer program operating in binary code may therefore use a tremendous amount of storage space and processor cycles, particularly when graphics are involved. For example, a photographic quality image is often coded at 24-bits for every pixel. If the image resolution is 2 million pixels, as is common with today's digital cameras, each image would occupy 48 million bits, or 4 Megabytes, where a byte is defined as 8 bits per byte (due to the convention of expressing binary code in multiples of 8 bits). Manipulating that image would similarly require 48 million cycles of processor time for each manipulation. The amount of storage space and processing time increases exponentially when manipulating video because the computer system must process and store many such images every second. In addition, there are many other computer applications that are at least as intensive as image processing. Applications of such intensity tend to slow considerably as data is “bottlenecked” in the computer system.
- One way of minimizing the impact of the inefficiency of binary code has been to increase the amount of storage space and processing speed of computers. For example, personal computers sold commercially today offer up to 300 gigabytes (300 billion bytes) of hard drive storage, 4 gigabytes (4 billion bytes) of temporary memory storage, and processing speeds of over 4 gigahertz (4 billion cycles per second). Business computers, such those used in the motion picture industry are even faster and include more storage. In other words, as computer applications have demanded more storage space and processing time, the computers have become faster with higher storage capacity. Still, while these numbers are impressive, computer systems are not sufficiently fast as to eliminate all bottlenecks, and in fact, as computers become faster with more available storage, new applications are developed to take advantage of the improved technology so as to provide the need for even faster computers, even more storage space, etc.
- Another way of minimizing the impact of the inefficiency of binary code is to write computer programs and applications as efficiently as possible. Thus there is always an emphasis on writing computer code that achieves its outcome in as few steps or calculations as possible. Similarly, a computer program should not be written in 24-bit code when only 8-bit code is required for the application, and the computer program may compress data when appropriate.
- A second drawback of using binary code to perform computerized tasks is that it is impractical to write a computer program in binary code, particularly with complex programs. The first rudimentary computers, for example, were operated by mechanically toggling electrical switches between on and off states to enter a sequence of binary instructions. Computer programs simply specified the sequence of binary instructions to enter. This method was feasible so long as the program was no more than about a hundred instructions long. Beyond that point, programming directly in binary code became too complex, and programs too difficult to correct, or debug. Moreover, because the binary instructions were dependent upon the particular electrical circuitry of the computer processor and related hardware, the programmer was required to know in detail the particular architecture of the computer being used by the program.
- To accommodate computer programs of increasing complexity, as well as to facilitate the introduction of personal computers into the marketplace, modern operating systems were developed. Early computer operating systems, such as Microsoft DOS, essentially acted as an interface with a computer's hardware so that a user could issue specific commands or instructions to the computer written in more ordinary language. The operating system would recognize the commands, and automatically issue the instructions to the computer in binary code. For example, in Microsoft DOS, entering the command “MEM” into the computer would result in the computer displaying the types and amounts of computer memory available. The person issuing the command did not need to know anything about binary code or the manner in which the command being entered produced the desired result. The user simply needed to either memorize or look up a set of commands in an instruction manual.
- Further, early operating systems recognized simple programming languages, such as BASIC and FORTRAN, written in terms more intuitive than binary code. In these languages, commands such as WRITE, READ, LOOP, SET and other intuitive terms provided a means to write computer programs in a manner easily learned and perhaps more importantly, in a manner more easily readable when debugging the program. A simple computer program to calculate the area of a circle, for example, might have been written in BASIC approximately in this form:
10 PROGRAM 120 WRITE “This is a program to calculate the area of a circle.” 30 WRITE “Please enter the radius of the circle” 40 READ R 50 SET A=Π *R{circumflex over ( )}2 60 WRITE “The area of the circle is” R 70 END - In this example, after a person typed “
RUN PROGRAM 1”, the computer would execute the command lines in numerical sequence, whereby a person would be prompted to enter the value for a radius, defined as “R”, after which the computer would square that value, multiply the squared value by pi and print out the computed area. Writing this same program in binary code not only would have required much more time and effort on the part of the programmer, but the programmer also would have had to know the technical specifications of the computer processor. Obviously, the introduction of operating systems along with intuitive programming languages was a boon to both consumers and computer programmers. - A number of such operating systems and programming languages became prevalent. For example, Apple Macintosh and Microsoft Windows operating systems improved (from a consumer's perspective) upon simple text-based operating systems such as DOS by allowing user to issue instructions to the computer using a point-and-click graphical interface displayed on a computer monitor. Computer applications, such as word processing programs, computer games, and a host of others took advantage of this functionality to provide products that could be used more intuitively through the graphical interface. Today, a host of operating systems are used, such as many versions of Microsoft Windows 9x, Macintosh OS, Linux, Windows NT, among others.
- A wide variety of programming languages also became prevalent. At first, most new programming languages followed the model of the early FORTRAN language by structuring the programming language as a series of commands by which a programmer would issue instructions to a computer in a logical order. The most popular of these language types is a program called “C.” The creation of “C” is considered by many to have marked the beginning of the modern age of computer languages. “C” successfully synthesized what had seemed to be conflicting attributes of several existing programming languages, adding new attributes to form a single, powerful structured language that also happened to be easy to learn. Moreover, it was a programmer's language. Prior to the development of “C”, computer languages were generally designed either as academic exercises by engineers or designed by bureaucratic committees. “C”, however, was developed by programmers, reflecting the way they approached the task of programming. As a result, “C” found wide and rapid acceptance in the programming community, attracting many followers who had near-religious zeal for it.
- Once again, however, the increasing complexity of computer programs exposed an underlying flaw of “C” as well as its predecessors. Each of these programming languages requires that a program be written as a series of linear steps or instructions (with an occasional loop or branch thrown in). In fact, writing such a program is similar to constructing a geometric proof, and like a proof, once a program such as C or FORTRAN exceeds a certain number of steps (somewhere between 25,000 and 100,000 lines of code), the program becomes too complex write effectively.
- Therefore a new approach to computer programming began to find acceptance in the programming community, commonly referred to as object-oriented programming. Object-oriented programming approaches a programming task in roughly the same way that a person's mind might approach that task—by abstracting a solution. Rather than defining a series of steps, or instructions by which a task could be accomplished, an object-oriented program focuses first on a program's data, defining classes of data and objects, where an object is a particular instance of a class. An object-oriented oriented program still contains instructions, referred to as methods, which often are embedded within the classes or objects themselves. An example of a simple object oriented program that displays the volume of two boxes might look like this:
class Box { double width; double height; double depth; // display volume of a box void volume ( ) { System.out.print (“Volume is”); System.out.println (width*height*depth); } } class BoxDemo { public static void main (String args[ ] { Box mybox1 = new Box ( ); Box mybox2 = new Box ( ); // assign values to mybox 1's variables mybox1.width = 3 mybox1.height = 20 mybox1.depth = 15 // assign values to mybox2's variables mybox 2.width = 3 mybox2.height = 6 mybox2.depth = 9 // display volume of mybox1 mybox1.volume ( ); // display volume of mybox2 mybox2.volume ( ) - In this example program, a box class is first defined having the variables of width, height, and depth (the term “double” identifies the type of number that the variable is allowed to be). The box class also defines a method to display the volume of an object box of this class by multiplying width by height by depth. Once this class has been defined, the program defines a second class BoxDemo which includes two objects of the initial box class. The class BoxDemo then twice calls the method of the first box class for displaying the volume of a box, once to display the volume of
mybox 1 and once to display the volume of mybox2. - Object oriented programming has quickly gained widespread popularity. One particularly popular object oriented language is called Java, which is the programming language used in the foregoing example. The reason Java has become so popular is its versatility in defining classes and objects, as well as its ability for one class or object to call functions in other classes and objects as well as to reuse data in other objects simply by referencing the function or the data. In Java, therefore, it is very easy to create multiple variations of a defined class, to create new variations of an old class, and to reuse a method previously defined by one class in a new class. Parenthetically, another object oriented programming language that has become popular is C++, which expands C to include the functionality of both object oriented programming and the instruction oriented programming of C.
- Java, like any other programming language relies upon an interface to convert the program to the required binary instructions. With Java, this interface is called a “Virtual Machine” (VM) because the interface behaves as if it were a computer unto itself. Every time a Java based computer application is initiated, the application initiates a VM to run the application. The Java VM will be described in much greater detail later in this specification, but several important principles will be introduced now. First, while the input to a Java VM is always the Java programming language, the output of a Java VM is customized to the particular platform, or operating system, that hosts the Java VM. In other words, every Java application must be customized to the host operating system so that the VM that it creates is capable of converting the Java programming language to the commands unique to the host operating system, which in turn issues the appropriate binary instructions to the computer.
- Second, Java VMs are designed to be independent of one another. If two Java applications are running on the same computer, each application creates its own VM which is self sufficient, i.e. neither VM needs rely upon the VM of the other application. If one application should close, the other application will not be affected. This often becomes problematical, however. Recall that even with today's processors and storage devices, a computer's resources may still be strained by intensive applications. With multiple Java applications running simultaneously, each creating its own VM, system resources may be strained and slowdowns may result. In other words, there is often a trade off between the desired independence of multiple Java applications and the speed at which the applications may run.
- Third, the creators of the Java VM, Sun Microsystems, emphasized uniformity of the Java VM with respect to all of the host operating systems. Thus, while the “guts” of each VM will of necessity be different across each platform, a user of a Java VM was not intended to be able to recognize any difference, seeing the same functionality regardless of the host platform. This, however, became problematical. Many operating systems offer unique features not available to other operating systems. Thus a business operating on Windows NT might desire to have a Java VM, and hence the Java application running the VM, take advantage of that unique functionality. The same would hold true for a user of a Macintosh or a Linux system, or a Windows 9x system, etc. Therefore, although Sun Microsystems's Java VM is uniform across all platforms, an industry has blossomed by which Java applications may be truly customized to a host operating system whereby the features of the host operating system are more fully exploited, and custom tailored to the particular needs of the business or person running the application.
- This diversity among Java VMs tends to hinder the improvement of the Java VM and the programming language because many such improvements are tied to the particular species of Java VM upon which the improvement was developed. Many businesses may like the particular improvement, but dislike other aspects of the Java VM. In that instance, a business with its own custom or proprietary VM would have the options of buying the new VM with its perceived advantages and faults, or spend the time and resources to engineer its own VM, which it likes, to include the new improvement. Exacerbating this problem is that the new improvement may be proprietary, thus eliminating the second option.
- What is desired then, is an improved system for implementing object-oriented computer applications that both efficiently allocates computer hardware resources among multiple computer applications running simultaneously on the same computer or network of computers, or among multiple threads of a single computer application running on a computer or network of computers, while also preserving the independence of multiple, simultaneous applications. What is further desired is such an improved system that is sufficiently flexible so as to be compatible not only with the diverse range of existing object-oriented computer applications, but also with object-oriented applications that are developed or modified in the future.
-
FIG. 1 is a simplified architectural schematic of an existing VM. -
FIG. 2 is an expanded architectural schematic of the VM ofFIG. 1 showing a memory region interposed between the class loader and the execution engine. -
FIG. 3 is a schematic of the heap shown inFIG. 2 . -
FIG. 4A is a diagram showing a prior art system for operating multiple VM applications on a host computer. -
FIG. 4B is a diagram showing a prior art system for the simultaneous operation of multiple instances of a VM application on several host computers connected through a network or internet server. -
FIG. 5 is a diagram showing a first improved system for operating multiple VM applications on a host computer. -
FIG. 6 is a diagram showing a first manner in which objects may be shared between applications using the system ofFIG. 5 -
FIG. 7 is a diagram showing a second manner in which objects may be shared between applications using the system ofFIG. 5 -
FIG. 8 is a second improved system for operating multiple VM applications on a host computer. -
FIG. 9 is an improved system for the simultaneous operation of multiple instances of a VM application on several host computers connected through a network or internet server. -
FIGS. 10 and 11 show a system for monitoring a shared object space to collect, store, graphically display, and analyze statistical or other data pertaining to the shared object space. -
FIGS. 1-4B show a simplified architectural schematic of an existingJava VM 10, although it should be understood that other types of VMs besides Java may also have the features shown inFIGS. 1-4B . Referring specifically toFIG. 1 , when a Java application is initiated on a host computer with ahost operating system 12, the application loads a Java virtual machine (VM) 10 which may include aclass loader 16 and anexecution engine 18. AlthoughFIG. 1 indicates a single class loader, in actuality, a Java VM may include multiple class loaders. Thus theclass loader 16 may be considered a subsystem that may involve many class loaders. TheJava VM 10 has a flexible class loader architecture that enables a Java application to load classes in custom ways. - Specifically, the
class loader 16 may comprise a system class loader and one or more user-defined class loaders. The system class loader is a part of the Java VM implementation and loads classes, including the Java application programming interface (API) class files 20, in some default way and usually from the local disk of the host computer. As previously stated, the particular default manner in which the system class loader loads classes is specific to the particular VM implementation being used and may be customized. The term “system class loader” is sometimes referred to as a “primordial class loader”, a “bootstrap class loader”, or a “default class loader.” - At run time, a Java application may also load application class files 22 in custom ways through user-defined class loaders, such as by downloading class files across a network. While the system class loader is an intrinsic part of the VM implementation, the user-defined class loaders are not. Instead, user-defined class loaders are written in Java, compiled to class files, loaded into the virtual machine, and instantiated just like any other object, becoming a part of the executable code of a running Java application. User defined class loaders enable a programmer to dynamically extend a Java application at run time. As the application runs, it can determine what extra classes are needed and load them through one or more user-defined class loaders. Because the user defined class loaders are written in Java, classes can be loaded in any manner expressible in the Java programming language.
- For each class loaded by the
virtual machine 10, thevirtual machine 10 records which class loader loaded the class. When a loaded class refers to another class, thevirtual machine 10 requests the referenced class from the same class loader that originally loaded the referencing class. For example, if thevirtual machine 10 loads the class “Volcano” through a particular class loader, it will attempt to load any classes to which Volcano referred with the same class loader. In this way, Java's architecture enables a programmer to create multiple “name spaces” inside a single Java application. Each class loader in the executing Java application has its own name space, which is populated by the names of all the classes it has loaded. - The
execution engine 18 executes instructions contained in the methods of loaded classes in “bytecode”, essentially Java's machine language. The Java specification describes what is to result from a given instruction retrieved from a Java method, but a programmer of a Java application determines the best way of achieving the result using software, hardware, or a combination of both. Theexecution engine 18 is an abstraction; Java is a programming language capable of simultaneously running multiple threads, i.e. distinct paths of execution, hence the execution of each thread can be considered an “instance” of theabstract execution engine 18. Thus at any given time, there may be multiple “instances” of theexecution engine 18. - The
execution engine 18 receives a bytecode stream of instructions in a thread and executes the thread one instruction at a time. Theexecution engine 18 executes the actions requested by each thread, and whenever intended by the Java application, sends instructions to the operating system in the code that the operating system recognizes. From time to time, theexecution engine 18 might encounter an instruction that requests a method written in some other language than Java, referred to as a “native method.” On such occasions, theexecution engine 18 will attempt to invoke that native method by accessingnative method libraries 36 through a native method interface 34 (shown inFIG. 2 ). When the native method returns, theexecution engine 18 will continue executing the next instruction in the bytecode stream. - When the Java
virtual machine 10 runs an application, it needs memory to store many items, including information it extracts from class files, objects that the program instantiates, parameters to methods, return values, local variables, and intermediate results of computations. TheJava VM 10 organizes the memory it needs to execute a program into several runtime data areas, depicted inFIG. 2 . These runtime areas may include amethod area 24, aheap 26, one or more Java stacks 28, one or more program counter (PC) registers 30, and one or more native method stacks 32. Although the same runtime data areas exist in some form in every Java VM implementation, the structural details of these areas are left to the designers of the VM and may therefore vary considerably from one Java application to another. - Each instance of a
Java VM 10 has onemethod area 24 and oneheap 26. These areas are shared by all threads running inside theVM 10. As each thread comes into existence, it receives itsown PC register 30 andJava stack 28. When theVM 10 runs a method contained in a thread, several things happen. First, the value of the PC register is used to tell the next instruction in the method's sequence to execute. Second, the thread'sjava stack 28 stores the state of each executing Java method in a stack frame, which includes the thread's local variables, the parameters with which it was invoked, its return value if any, and intermediate calculations. When theVM 10 has invoked a method in a thread and that method subsequently completes, theVM 10 discards the stack frame for that method from theJava stack 28. The state of native method invocations is stored in thenative method stack 32 in a manner dictated by the designer of theJava VM 10. - Information about loaded data types are parsed from class files as they are loaded and stored in the
method area 24. A data type refers to the format in which the data is expressed, e.g. an integer, a float, etc. A data type could also be an address of an op code within a method or a reference to an object on theheap 26. TheVM 10 uses the type information stored in themethod area 24 as it executes the application it is running. - For each data type the
VM 10 loads, it should store the following kinds of information in the method area: (1) the fully qualified name of the type; (2) the fully qualified name of the type's superclass; (3) whether or not the type is a class or an interface; (4) the type's modifiers; (5) an ordered list of the fully qualified names of any direct superinterfaces; (6) the constant pool for the type; (7) field information; (8) method information; (9) all class variables declared in the type except constants; (10) a reference to class CLASSLOADER; and (11) a reference to class CLASS. Each of these kinds of information is well known to those in the art who design Java virtual machines and program in Java. - Referring to
FIG. 3 , whenever anobject 38 is created by a Java application, memory for thenew object 38 is stored in theheap 26. Because there is only oneheap 26 inside of any instance of aJava VM 10, all threads share theheap 26 and because each Java application runs inside itsown Java VM 10, there is aseparate heap 26 for every Java application running. In this manner, one Java application cannot affect theobjects 38 in theheap 26 of another application. Twodifferent threads objects 38. For this reason, synchronization of the access to objects of multiple threads must be planned. - The existing
Java VM 10, as illustrated inFIGS. 1-3 has several disadvantages. First, it is inherently redundant. Referring toFIGS. 4A and 4B , a single computer when running multiple Java applications (or other applications that run in a VM) must create a separate VM for each application. Each VM, in turn, generates its own method area, heap, PC register, etc., using a good deal of the resources of the underlying computer. This is true even when each VM is running a separate instance of the same application where many of the objects created by the application will be identical. This is illustrated inFIG. 4B where threecomputers same application 54 through aserver 52. In this instance, many of the runtime data areas may be located on theserver 52, creating the same kind of redundancy as seen inFIG. 4A . - The redundancy of existing VM systems translates to a loss in system speed for two reasons. First, each VM must use its own resources, i.e. time, to load objects already loaded in other applications. Second, the combined memory space of all VM applications often bottlenecks system resources. In many cases, the speed at which an application or series of simultaneously running applications may operate defines the upper limit of a system's performance—the number of trades processed, web pages served, or billing records updated per second. In other words, the speed at which individually well-tuned processes can operate determines how much value that system can provide on a second-to second basis, i.e. lost system speed means lost revenue.
- The existing wisdom is that the redundancy and the associated loss of speed that results from designing every VM application to run in its own
isolated VM 10 is a small price in exchange for the assurance that one application cannot change or otherwise corrupt the data being used by another application. In addition, the isolation of applications each within its separate VM ensures that if one application should close, or suddenly crash, the other applications would remain unaffected. The present inventors, though, came to the realization that there are a variety of applications in which the sharing of data across applications might actually be beneficial. In those instances, the redundancy of the existing system for running VM applications and the associated loss of system speed would be needless. - With this in mind,
FIG. 5 shows an improved system for running VM applications, which broadly stated may comprise a sharedobject space 100 and anative access layer 102 operably connectable with a plurality of application programming interfaces (API) 104, 106 of independent VMs or other applications such as the C/C++ application 112. Theaccess layer 102 permits eachapplication API objects 108 into the sharedobject space 100 where theobjects 108 may be read and/or modified by theparticular applications objects 108 stored in the sharedobject space 100 within its own respective heap or other memory area, the sharedobject space 100 permits an application to store anobject 108 in the sharedobject space 100 instead of its own heap or other memory area, thus avoiding the redundancy of existing VM systems. Access to theobjects 108 in the sharedobject space 100 may be synchronized using the methods that presently exist for controlling access to shared objects in a heap by multiple concurrently running threads. Further, the sharedobject space 100 will store anobject 108 so long as a thread of any connected application is using theobject 108. In this manner, even if the application that placed a particular object in the sharedobject space 100 closes or crashes, that object will still be available to other applications as necessary. Thus the sharedobject space 100 permits multiple applications running simultaneously on a system or network to enjoy the stability of existing VM systems, while providing a substantial boost in performance. - The shared
object space 100 is accessible to an application through thenative access layer 102. Thus a Java application or other object oriented application will recognize the sharedobject space 100 as simply another native method accessible through the interface that already exists in Java and other object-oriented applications. Once accessed, all the functionality of the sharedobject space 100 will be instantly accessible to the connected application. Further, the sharedobject space 100 does not need to be tied to a particular VM, but instead is backwards compatible with any individual VM, whether it is a standard Java VM provided by Sun Microsystems or a customized VM of a particular business, and forwards compatible with any VM including improvements that have yet to be developed. Thus the versatility of the sharedobject space 100 can not be overstated. The versatility of the sharedobject space 100 is furthered by its compatibility with a wide variety of application interfaces. As can be seen inFIG. 5 , thenative access layer 102 provides access to the sharedobject space 100 by both Java applications and C or C++ applications. It should be understood that these examples are illustrative only, and that thenative access layer 102 could provide access to the sharedobject space 100 by a number of other application types, whether object-oriented like Java or command oriented like C or C++. - The advantages of the shared
object space 100 are readily apparent, particularly with respect to applications that benefit from the ability of multiple, simultaneously running applications to update a shared object rather than simply read or copy a shared object. One such application might be online trading. As the popularity of online trading increases, trading exchanges are faced with ever-growing volumes of market data and concurrent trader activity. Systems that were built to handle moderate volumes now have to handle thousands of traders and billions of dollars in daily transactions. Such systems have to accommodate huge spikes in demand. For instance, a single trade may require thousands of traders to be notified. Many traders watch for these price changes, then jump in to sell or buy very quickly, causing even more notification demand and more trading volume. The faster a trading system reacts to changes, the more transactions an exchange can execute, increasing its commissions while maximizing trader satisfaction with the service. - Another example of the utility of the shared
object space 100 might be its potential in improving speed of computerized activity in the telecommunications industry. Modem telecommunication networks have to process vast amounts of data very quickly. Every time a call is placed, for example, an application needs to access the customer's subscription information, apply any special discounts that may be applicable, monitor the call duration and establish a rate based on the time and distance to the terminating number. Given that the number of such calls can run into the thousands at any given moment, a memory based data sharing facility is a necessity. In the past, such telecommunications applications have been written from scratch in C at enormous expense. The availability of an off-the-shelf shared memory component that provides a sharedobject space 100 makes it possible to write such systems in Java or another object-oriented program more quickly, cheaply, and with less risk. - Yet another example of the utility of the shared
object space 100 is its potential use in large scale internet applications. Large internet content syndication and portal applications depend on fast caching for scalability. The sharedobject space 100 provides an ideal caching facility for HTML and XML fragments, XML DOMs and streams, HTTP session information, and JDBC query results. It can also hold very fast page request queues and other operational data structures. The sharedobject space 100 may include multi-language support which may be exploited when connected to web servers, servlet engines, content management suites, and XML transcoders to speed up every phase of a sites operation. - In use, the shared
object space 100 may be one element in alarger computing system 101. Specifically, it is anticipated that the sharedobject space 100, along with its associatednative access layer 102 may be used in conjunction with aconsole 118, anadministrative processor 120,disk storage 122 and adisplay 124 suitable for displaying system statistics. Theconsole 118 is used to configure and start thesystem 101 which may comprise asystem manager 126, the sharedobject space 100, and thenative access layer 102. Thesystem manager 126 creates and initializes the sharedobject space 100, collects garbage, gathers statistics, and logs both system and user-defined events. Once thesystem 101 has been started, thesystem manager 126 can also be used to browse the sharedobject space 100, enable statistics collection from individual objects, and display the statistics graphically for analysis. - The
system 101 is preferably stored on adisk 122 in a default directory, e.g. “defaultSystem”, that holds the system's configuration file and log file. Thesystem 101 may be included on an executable storage media such as a compact disk that include an installation tool that may be used to create the requisite directories on thedisk 122. Additional custom system directories may also be installed on thesame disk 122 as desired. Preferably, thesystem 101 includes a number of default tools that operate on the default system; however theconsole 118 and a command line utility may allow the user to specify a different system. - To make use of the
system 101 and its sharedobject space 100, thesystem 101 includes a library file in the default directory. Java applications should include a reference to this library (e.g. productdir/lib/gemfirejar) on its CLASSPATH. On Windows systems, the library may be made available by adding productDir/bin to PATH and on Solaris, the library can be made available by adding productDir/lib to LD_LIBRARY_PATH. An application process connects to thesystem 101 by making a call that contacts thesystem manager 126, such as GemFireConnection.myConn=GemFireConnection.getinstance (“Gemfire”). Thesystem manager 126 then returns information that enables the application process to map the sharedobject space 100 into its address space. - Each
system 101 preferably maintains aglobal name space 116 in the sharedobject space 100. Thename space 116 provides a fast object registry in which applications can register and look up “root” objects by name. Objects that are referenced from this name space are protected from garbage collection. Once connected to thesystem 101, an application can look up shared objects in thename space 116 with a command such asStock myStock = (Stock) myConn.lookup(“GSI”)
A shared object like myStock always represents a current shared value; that is all threads in all VMs always see the same field values, just as all threads in a single VM see the same volatile field values for an object in that VM. The statement -
- myStock.getPrice( )
for example, might return the price most recently set by a local or remote thread, while the statement - myStock.setPrice(34)
immediately updates the shared view of myStock's price. Because these fetches and updates incur no disk or network overhead, they are much faster than the same operations implemented through mechanisms like RMI and they outperform JDBC calls by an even wider margin.
- myStock.getPrice( )
- The
system 101 may include a Class Enhance tool that prepares an application class for sharing by modifying the class's bytecodes to provide transparent instantiation in shared memory and automatic read-through and write-through for field access methods. By default, all fields may be shared, but a user may establish more selective policies by providing an XML description of the fields to be shared in each domain class. Once a class in enhanced, making an object of that class automatically puts the object into shared memory. - Referring to
FIGS. 6 and 7 , thesystem 101 may support two methods of sharing objects, copy sharing and direct sharing. Anobject 128 that is copy shared is allocated twice, once in the local memory of an application and again in sharedmemory 100.FIG. 6 shows an example of a copy sharing method where application A creates anobject 128 in its local address space. Theobject 128 is shared by putting it into the sharedname space 116. At this point, theobject 128 is not immediately written to a field in the sharedobject space 100; instead theobject 128 is written to sharedmemory 100 only after a user “flushes”, i.e. updates the object to a new version, for the first time. Once anobject 128 is written to shared memory, application B is able to copy theobject 128 to its local memory by accessing the sharedobject 128 by name in the sharedname space 116. Application B may modify the copy of theobject 128 obtained from shared memory, but may not update the shared version of theobject 128. If application B wishes to see the most recently updated version of theobject 128, a refresh command may be used. -
FIG. 7 shows an example of a direct sharing method, which is a one-space model where some of all of the non-static fields of the sharedobject 128 reside only in shared memory. Static fields may be kept in the local heap of an application's VM for performance reasons. An assignment to a field of a directly sharedobject 128 is immediately visible to threads of other applications and each application is able to write to the shared object. When the field is read, the current state in sharedmemory 100 is returned; there is no need to refresh the local memory. -
FIG. 8 shows anothersystem 201 that includes a sharedobject space 200 within afirst Java VM 202. Thefirst Java VM 202 may include all the elements of a typical Java VM as previously described, i.e. a method area, a class loader, an execution engine, etc. The heap of the first Java VM, however, acts as the sharedobject space 200 so as to be accessible by the execution engine 204 of a second Java VM. In thesystem 201, the first instance of an application may initiate a VM whose heap performs as a shared object space for subsequent instances of applications operating on the same computer. The sharedobject space 200 may have all the functionality of the sharedobject space 100 previously described. -
FIG. 9 shows anothersystem 301 in which a sharedobject space 300 resides on aserver 302 interconnectingindependent computers computer server 302. For example, theserver 302 may include a dynamic database for stock prices in a trading scenario where theconnected computers - Oftentimes it is desirable to monitor an object space (i.e. monitoring the state of a memory space, objects in that space, or methods that use objects in that space) for statistical and other purposes. Two existing methods of monitoring an object space are typically employed. First, applications are programmed to periodically generate messages concerning the state of the objects they create, and these messages are then logged so that statistical data can be gathered relating to the use of those objects. This particular method adversely impacts performance, however, and takes up a large amount of disk and/or memory space; hence this method is typically used only for monitoring events that do not lend themselves to numeric representation. Alternatively, existing operating systems compile statistics used for monitoring an object space. These statistics, however, are chosen by the vendor of the operating system and cannot be easily customized.
- In contrast to these existing methods of monitoring an object space, the disclosed shared object space may be conveniently monitored using a minimal amount of system resources and may be easily customized to suit the needs of a particular user. Referring to
FIG. 10 , the disclosed system may include aconsole 402 having adisplay 404 and an interface such as thealphanumeric keyboard 406 and optionally amouse 408. Theconsole 402 may be operationally interconnected with anadministrative processor 410 anddisk storage 412. Theconsole 402 in conjunction with theadministrative processor 406 may be defined as anadministrative system 401 and used to monitor a sharedobject space 400 by gathering statistics and providing access to the system and a user-defined event log, as well as monitoring shared object allocation rates, VM connections, lock acquisitions, shared queue sizes, and so on. Theadministrative system 401 may also be used to configure and initialize the sharedobject space 400 and permits an administrative user to dynamically discover which particular applications are utilizing the sharedobject space 400, such as theapplications administrative system 401 also may provide automated alerts for serious problems so that theconsole 402 can be used to take corrective action. - The shared
object space 400 may be associated with a distributed group management system having a distributed cache. In that instance, theadministrative system 401 preferably uses administrative interfaces in the distributed group management system of the sharedobject space 400 to become an adjunct member of the cache. This allows theadministrative system 402 to make requests in cache nodes, such as gathering a snapshot of current contents of a distributed cache region, taking corrective action on a deadlock alert, gathering statistics for graphing, or requesting log file contents for display. - The
administrative system 401 preferably monitors the sharedobject space 400 so that any data or object, such as 420, 422, 424, or 426, in the sharedobject space 400 can be registered with theadministrative system 401 for statistical monitoring and periodic backup to a compressed file on thedisk storage 412. Preferably, theadministrative system 401 takes a “snapshot” of all registered statistical data once every second and transfers that statistical data to thedisk storage 412 where it can be analyzed later, even after the sharedobject space 400 no longer exists. A selected subset of the “snapshot” can also be simultaneously analyzed visually on thedisplay 404. Alternatively, the frequency of the monitoring system may be adjustable so that a user can cause the administrative system to record statistical data more or less frequently than once per second. - The
administrative system 401 preferably provides a framework for gathering application-defined statistics. For example, an application could identify any numeric field in a shared object class as a statistical field. Theadministrative system 401 may then immediately sample the field at designated intervals, log the results, and make the numbers available in a graphical tool on thedisplay 404. For example, ifobject 424 shown inFIG. 10 as “object R” tracks the number of matches performed by a trading system matching engine, that object might be registered with the statistics service with the command -
- GemFireConnectionFactory.getinstance( ).setStatisticsArchived(tradingStats);
after which theadministrative system 401 will thereafter automatically record the state of “trading stats” for statistical review at a later time. The aforementioned registration command is, of course, merely an example of one particular command that could be used, and will vary from system to system depending on many factors including the programming language used, the name of the shared object space system, etc.
- GemFireConnectionFactory.getinstance( ).setStatisticsArchived(tradingStats);
-
FIG. 11 is a simplified schematic of asystem 403 for monitoring objects in a sharedobject space 400 where any application (such asapplications administrative system 401 connected to the sharedobject space 400 may define what in the sharedobject space 400 is to be monitored. Thesystem 403 includes a sharedobject space 400 that is being monitored by anadministrative system 401 using twomonitors object space 400 includes a monitoredobject space 428 that selectively contains any desired number of objects to be monitored, such as theobjects - In operation, the
applications administrative system 401, connected to the sharedobject space 400 may insert references to existing shared objects to be monitored into the monitored object space, such as theobjects objects object space 400, or alternatively may be customized to be data or fields of data that pertains in any way to the state of any shared object in the sharedobject space 400. An application may register an object to be monitored in the monitored object space in any desired manner, such as by making a single call with the object to be monitored as the only argument, inserting the registered monitored object, such as 430 or 432 into the monitoredobject space 428. The size, or capacity, of the monitoredobject space 428 may be any desired portion of the sharedobject space 400, and may be variable so as to expand or contract as necessary. - The
monitors object space 428 at a desired frequency. Preferably, thesystem 403 has a default frequency, such as once per second, which may be adjusted by a user or an application as necessary. Themonitors administrative system 401, may store recorded snapshots of the data to storage local to theadministrative system 401 for graphical display and analysis in the manner previously described. - As can be easily seen in reference to
FIG. 11 , the disclosed system for monitoring objects in a shared object space is highly flexible in that any application using the sharedobject space 400, or an administrative user, has the ability to define data that may be monitored or statistics to be compiled. This represents a tremendous advantage over existing systems, such as existing operating systems whereby the vendor of the operating system defined the set of statistics gathered, which could then either not be modified, or only modified after a great deal of effort. - The terms and expressions that have been employed in the foregoing specification are used therein as terms of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding equivalents of the features shown and described or portions thereof, it being recognized that the scope of the invention is defined and limited only the claims that follow.
Claims (48)
1. A system for the concurrent operation of plural computer applications, each said computer application operating in its own virtual machine, said system comprising;
(a) a shared object space selectively connectable to each said plural computer application, said shared object space capable of storing at least one object accessible to each said plural computer application when connected to said shared object space;
(b) a processing unit operably connected to a display; and
(c) a monitor associated with said shared object space capable of collecting data pertaining to the operation of said shared object space and sending said data to said processing unit, said processing unit capable of processing said data into statistical information pertaining to the operation of said shared object space for graphical representation on said display.
2. The system of claim 1 where each said virtual machine is a Java virtual machine.
3. The system of claim 2 where said shared object space is connected to each said virtual machine through a Java Native Method Interface.
4. The system of claim 3 where said system includes a default directory with a native language library file.
5. The system of claim 1 where said shared object space is operably connectable to a non-object-oriented application.
6. The system of claim 5 where said non-object oriented program is a “C” program.
7. The system of claim 1 where access to said at least one object by said plural computer applications is synchronized.
8. The system of claim 1 where said shared object space is operably connectable to a Sun Microsystems virtual machine.
9. The system of claim 1 where said plural computer applications pertain to at least one of:
(a) stock trading;
(b) communications processing; and
(c) internet services.
10. The system of claim 1 including a global name space in said shared object space.
11. The system of claim 1 where said at least one object is copy shared among said plural applications.
12. The system of claim 1 where said at least one object is direct shared among said plural applications.
13. A system for the concurrent operation of plural computer applications, each said computer application operating in its own virtual machine, said system comprising;
(a) a shared object space selectively connectable to each said plural computer application, said shared object space capable of storing at least one object accessible to each said plural computer application when connected to said shared object space;
(b) a processing unit operably connected to a display;
(c) a monitor associated with said shared object space capable of collecting data pertaining to the operation of said shared object space and sending said data to said processing unit, said processing unit capable of processing said data into statistical information pertaining to the operation of said shared object space for graphical representation on said display; and
(d) said monitor comprising a shared monitor space in said shared object space, said shared monitor space storing references to objects having time varying data pertaining to the operation of said shared object space, where said time varying data referred to in said shared monitor space may be selectively sampled at a desired frequency.
14. The system of claim 13 where each said virtual machine is a Java virtual machine.
15. The system of claim 14 where said shared object space is connected to each said virtual machine through a Java Native Method Interface.
16. The system of claim 15 where said system includes a default directory with a native language library file.
17. The system of claim 13 where said shared object space is operably connectable to a non-object-oriented application.
18. The system of claim 17 where said non-object oriented program is a “C” program.
19. The system of claim 13 where access to said at least one object by said plural computer applications is synchronized.
20. The system of claim 13 where said shared object space is operably connectable to a Sun Microsystems virtual machine.
21. The system of claim 13 where said plural computer applications pertain to at least one of:
(a) stock trading;
(b) communications processing; and
(c) internet services.
22. The system of claim 13 including a global name space in said shared object space.
23. The system of claim 13 where said at least one object is copy shared among said plural applications.
24. The system of claim 13 where said at least one object is direct shared among said plural applications.
25. A system for the concurrent operation of plural computer applications, each said computer application operating in its own virtual machine, said system comprising;
(a) a shared object space selectively connectable to each said plural computer application, said shared object space capable of storing at least one object accessible to each said plural computer application when connected to said shared object space;
(b) a processing unit operably connected to a display;
(c) a monitor associated with said shared object space capable of collecting data pertaining to the operation of said shared object space and sending said data to said processing unit, said processing unit capable of processing said data into statistical information pertaining to the operation of said shared object space for graphical representation on said display; and
(d) said monitor comprising a shared monitor space in said shared object space, said shared monitor space storing references to objects having time varying data pertaining to the operation of said shared object space, where said time varying data referred to in said shared monitor space may be selectively sampled at a desired frequency.
26. The system of claim 25 where each said virtual machine is a Java virtual machine.
27. The system of claim 26 where said shared object space is connected to each said virtual machine through a Java Native Method Interface.
28. The system of claim 27 where said system includes a default directory with a native language library file.
29. The system of claim 25 where said shared object space is operably connectable to a non-object-oriented application.
30. The system of claim 29 where said non-object oriented program is a “C” program.
31. The system of claim 25 where access to said at least one object by said plural computer applications is synchronized.
32. The system of claim 25 where said shared object space is operably connectable to a Sun Microsystems virtual machine.
33. The system of claim 25 where said plural computer applications pertain to at least one of:
(a) stock trading;
(b) communications processing; and
(c) internet services.
34. The system of claim 25 including a global name space in said shared object space.
35. The system of claim 25 where said at least one object is copy shared among said plural applications.
36. The system of claim 25 where said at least one object is direct shared among said plural applications.
37. A system for the concurrent operation of plural computer applications, each said computer application operating in its own virtual machine, said system comprising;
(a) a first virtual machine running a first said application, said first virtual machine having a shared object space for storing at least one object for sharing among said plural applications; and
(b) at least one second virtual machine, each said second virtual machine having a private heap inaccessible to other said plural applications and each said second virtual machine operably connectable to said shared object space of said first virtual machine.
38. The system of claim 37 where each said virtual machine is a Java virtual machine.
39. The system of claim 386 where said shared object space is connected to each said virtual machine through a Java Native Method Interface.
40. The system of claim 39 where said system includes a default directory with a native language library file.
41. The system of claim 37 where said shared object space is operably connectable to a non-object-oriented application.
42. The system of claim 41 where said non-object oriented program is a “C” program.
43. The system of claim 37 where access to said at least one object by said plural computer applications is synchronized.
44. The system of claim 37 where said shared object space is operably connectable to a Sun Microsystems virtual machine.
45. The system of claim 37 where said plural computer applications pertain to at least one of:
(a) stock trading;
(b) communications processing; and
(c) internet services.
46. The system of claim 37 including a global name space in said shared object space.
47. The system of claim 37 where said at least one object is copy shared among said plural applications.
48. The system of claim 37 where said at least one object is direct shared among said plural applications.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/690,783 US20050086662A1 (en) | 2003-10-21 | 2003-10-21 | Object monitoring system in shared object space |
US11/982,541 US8201187B2 (en) | 2003-10-21 | 2007-11-02 | Object monitoring system in shared object space |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/690,783 US20050086662A1 (en) | 2003-10-21 | 2003-10-21 | Object monitoring system in shared object space |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/982,541 Continuation US8201187B2 (en) | 2003-10-21 | 2007-11-02 | Object monitoring system in shared object space |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050086662A1 true US20050086662A1 (en) | 2005-04-21 |
Family
ID=34521721
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/690,783 Abandoned US20050086662A1 (en) | 2003-10-21 | 2003-10-21 | Object monitoring system in shared object space |
US11/982,541 Active 2026-09-16 US8201187B2 (en) | 2003-10-21 | 2007-11-02 | Object monitoring system in shared object space |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/982,541 Active 2026-09-16 US8201187B2 (en) | 2003-10-21 | 2007-11-02 | Object monitoring system in shared object space |
Country Status (1)
Country | Link |
---|---|
US (2) | US20050086662A1 (en) |
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060026200A1 (en) * | 2004-07-27 | 2006-02-02 | Texas Instruments Incorporated | Method and system for shared object data member zones |
US20060064549A1 (en) * | 2004-09-23 | 2006-03-23 | Michael Wintergerst | Cache eviction |
US20060129512A1 (en) * | 2004-12-14 | 2006-06-15 | Bernhard Braun | Socket-like communication API for C |
US20060129981A1 (en) * | 2004-12-14 | 2006-06-15 | Jan Dostert | Socket-like communication API for Java |
US20060143387A1 (en) * | 2004-12-28 | 2006-06-29 | Petev Petio G | Programming models for storage plug-ins |
US20060143392A1 (en) * | 2004-12-28 | 2006-06-29 | Petev Petio G | First in first out eviction implementation |
US20060143393A1 (en) * | 2004-12-28 | 2006-06-29 | Petev Petio G | Least frequently used eviction implementation |
US20060143389A1 (en) * | 2004-12-28 | 2006-06-29 | Frank Kilian | Main concept for common cache management |
US20060143256A1 (en) * | 2004-12-28 | 2006-06-29 | Galin Galchev | Cache region concept |
US20060143595A1 (en) * | 2004-12-28 | 2006-06-29 | Jan Dostert | Virtual machine monitoring using shared memory |
US20060143385A1 (en) * | 2004-12-28 | 2006-06-29 | Michael Wintergerst | Storage plug-in based on shared closures |
US20060143427A1 (en) * | 2004-12-28 | 2006-06-29 | Dirk Marwinski | Storage plug-in based on hashmaps |
US20060143394A1 (en) * | 2004-12-28 | 2006-06-29 | Petev Petio G | Size based eviction implementation |
US20060143398A1 (en) * | 2004-12-23 | 2006-06-29 | Stefan Rau | Method and apparatus for least recently used (LRU) software cache |
US20060143388A1 (en) * | 2004-12-28 | 2006-06-29 | Michael Wintergerst | Programming models for eviction policies |
US20060248276A1 (en) * | 2005-04-28 | 2006-11-02 | Frank Kilian | Cache monitoring using shared memory |
US20060248131A1 (en) * | 2005-04-29 | 2006-11-02 | Dirk Marwinski | Cache isolation model |
US20060282509A1 (en) * | 2005-06-09 | 2006-12-14 | Frank Kilian | Application server architecture |
US20070067469A1 (en) * | 2005-07-19 | 2007-03-22 | Oliver Luik | System and method for a pluggable protocol handler |
US20070156869A1 (en) * | 2005-12-30 | 2007-07-05 | Galin Galchev | Load balancing algorithm for servicing client requests |
US20080163063A1 (en) * | 2006-12-29 | 2008-07-03 | Sap Ag | Graphical user interface system and method for presenting information related to session and cache objects |
US7694065B2 (en) | 2004-12-28 | 2010-04-06 | Sap Ag | Distributed cache architecture |
CN101876906A (en) * | 2010-03-31 | 2010-11-03 | 北京播思软件技术有限公司 | Method and device for running Linux application in Android system |
US7831634B2 (en) | 2005-04-29 | 2010-11-09 | Sap Ag | Initializing a cache region using a generated cache region configuration structure |
US7971001B2 (en) | 2004-12-28 | 2011-06-28 | Sap Ag | Least recently used eviction implementation |
US8799359B2 (en) | 2004-12-28 | 2014-08-05 | Sap Ag | Session management within a multi-tiered enterprise network |
US10248349B2 (en) * | 2016-03-22 | 2019-04-02 | Oracle International Corporation | Efficient and thread-safe objects for dynamically-typed languages |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9665839B2 (en) * | 2001-01-11 | 2017-05-30 | The Marlin Company | Networked electronic media distribution system |
US7665077B2 (en) * | 2004-10-18 | 2010-02-16 | Microsoft Corporation | System and method for sharing objects between applications in a virtual runtime environment |
JP4144885B2 (en) * | 2004-12-28 | 2008-09-03 | インターナショナル・ビジネス・マシーンズ・コーポレーション | How to reuse application objects |
JP4725955B2 (en) * | 2005-06-30 | 2011-07-13 | 株式会社リコー | Information processing apparatus, message management method, program, and storage medium |
US20100057965A1 (en) * | 2008-08-29 | 2010-03-04 | International Business Machines Corporation | Extension of Lock Discipline Violation Detection for Lock Wait Patterns |
US8495630B2 (en) * | 2010-11-03 | 2013-07-23 | International Business Machines Corporation | Transferring objects between virtual machines |
US20120159515A1 (en) * | 2010-12-16 | 2012-06-21 | Microsoft Corporation | Sharing object representations |
US11481240B2 (en) | 2018-11-30 | 2022-10-25 | International Business Machines Corporation | Capturing traces of virtual machine objects combined with correlated system data |
Citations (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6247025B1 (en) * | 1997-07-17 | 2001-06-12 | International Business Machines Corporation | Locking and unlocking mechanism for controlling concurrent access to objects |
US20010014905A1 (en) * | 1999-12-27 | 2001-08-16 | Tamiya Onodera | Method and apparatus for managing a lock for an object |
US20030097360A1 (en) * | 2001-10-19 | 2003-05-22 | International Business Machines Corporation | Object locking in a shared VM environment |
US6681226B2 (en) * | 2001-01-30 | 2004-01-20 | Gemstone Systems, Inc. | Selective pessimistic locking for a concurrently updateable database |
US20040025171A1 (en) * | 2002-07-31 | 2004-02-05 | Barinov Vitaly Y. | Method for improving temporal consistency and snapshot recency in a monitored real-time software-reporting-application architecture |
US6738977B1 (en) * | 2000-05-31 | 2004-05-18 | International Business Machines Corporation | Class sharing between multiple virtual machines |
US20040199828A1 (en) * | 2003-04-01 | 2004-10-07 | International Business Machines Corporation | Method and apparatus for tracing troubleshooting events for aiding technical assistance |
US6829769B2 (en) * | 2000-10-04 | 2004-12-07 | Microsoft Corporation | High performance interprocess communication |
US20050086656A1 (en) * | 2003-10-20 | 2005-04-21 | Gemstone Systems, Inc. | Methods and systems for inter-process copy sharing of data objects |
US7017160B2 (en) * | 2000-04-18 | 2006-03-21 | Sun Microsystems, Inc. | Concurrent shared object implemented using a linked-list with amortized node allocation |
US7131120B2 (en) * | 2002-05-16 | 2006-10-31 | Sun Microsystems, Inc. | Inter Java virtual machine (JVM) resource locking mechanism |
US7143392B2 (en) * | 2001-09-19 | 2006-11-28 | Hewlett-Packard Development Company, L.P. | Hyperbolic tree space display of computer system monitoring and analysis data |
US7152231B1 (en) * | 1999-11-01 | 2006-12-19 | Harris-Exigent, Inc. | High speed interprocess communication |
US7171663B2 (en) * | 2002-12-09 | 2007-01-30 | International Business Machines Corporation | External event interrupt for server-side programs |
US7188145B2 (en) * | 2001-01-12 | 2007-03-06 | Epicrealm Licensing Llc | Method and system for dynamic distributed data caching |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6629153B1 (en) * | 1997-09-17 | 2003-09-30 | Trilogy Development Group, Inc. | Method and apparatus for providing peer ownership of shared objects |
AU5777599A (en) * | 1998-08-21 | 2000-03-14 | Marketxt, Inc. | Anti-manipulation method and system for a real-time computerized stock trading system |
US6789257B1 (en) * | 2000-04-13 | 2004-09-07 | International Business Machines Corporation | System and method for dynamic generation and clean-up of event correlation circuit |
US6567905B2 (en) * | 2001-01-23 | 2003-05-20 | Gemstone Systems, Inc. | Generational garbage collector with persistent object cache |
US7386863B2 (en) * | 2003-06-26 | 2008-06-10 | International Business Machines Corporation | Administering devices in dependence upon user metric vectors with multiple users |
US7774312B2 (en) * | 2003-09-04 | 2010-08-10 | Oracle International Corporation | Self-managing performance statistics repository for databases |
-
2003
- 2003-10-21 US US10/690,783 patent/US20050086662A1/en not_active Abandoned
-
2007
- 2007-11-02 US US11/982,541 patent/US8201187B2/en active Active
Patent Citations (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6247025B1 (en) * | 1997-07-17 | 2001-06-12 | International Business Machines Corporation | Locking and unlocking mechanism for controlling concurrent access to objects |
US7152231B1 (en) * | 1999-11-01 | 2006-12-19 | Harris-Exigent, Inc. | High speed interprocess communication |
US20010014905A1 (en) * | 1999-12-27 | 2001-08-16 | Tamiya Onodera | Method and apparatus for managing a lock for an object |
US7017160B2 (en) * | 2000-04-18 | 2006-03-21 | Sun Microsystems, Inc. | Concurrent shared object implemented using a linked-list with amortized node allocation |
US6738977B1 (en) * | 2000-05-31 | 2004-05-18 | International Business Machines Corporation | Class sharing between multiple virtual machines |
US6829769B2 (en) * | 2000-10-04 | 2004-12-07 | Microsoft Corporation | High performance interprocess communication |
US7188145B2 (en) * | 2001-01-12 | 2007-03-06 | Epicrealm Licensing Llc | Method and system for dynamic distributed data caching |
US6681226B2 (en) * | 2001-01-30 | 2004-01-20 | Gemstone Systems, Inc. | Selective pessimistic locking for a concurrently updateable database |
US7143392B2 (en) * | 2001-09-19 | 2006-11-28 | Hewlett-Packard Development Company, L.P. | Hyperbolic tree space display of computer system monitoring and analysis data |
US20030097360A1 (en) * | 2001-10-19 | 2003-05-22 | International Business Machines Corporation | Object locking in a shared VM environment |
US7131120B2 (en) * | 2002-05-16 | 2006-10-31 | Sun Microsystems, Inc. | Inter Java virtual machine (JVM) resource locking mechanism |
US20040025171A1 (en) * | 2002-07-31 | 2004-02-05 | Barinov Vitaly Y. | Method for improving temporal consistency and snapshot recency in a monitored real-time software-reporting-application architecture |
US7171663B2 (en) * | 2002-12-09 | 2007-01-30 | International Business Machines Corporation | External event interrupt for server-side programs |
US20040199828A1 (en) * | 2003-04-01 | 2004-10-07 | International Business Machines Corporation | Method and apparatus for tracing troubleshooting events for aiding technical assistance |
US20050086656A1 (en) * | 2003-10-20 | 2005-04-21 | Gemstone Systems, Inc. | Methods and systems for inter-process copy sharing of data objects |
Cited By (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060026200A1 (en) * | 2004-07-27 | 2006-02-02 | Texas Instruments Incorporated | Method and system for shared object data member zones |
US20060064549A1 (en) * | 2004-09-23 | 2006-03-23 | Michael Wintergerst | Cache eviction |
US7590803B2 (en) | 2004-09-23 | 2009-09-15 | Sap Ag | Cache eviction |
US20060129512A1 (en) * | 2004-12-14 | 2006-06-15 | Bernhard Braun | Socket-like communication API for C |
US20060129981A1 (en) * | 2004-12-14 | 2006-06-15 | Jan Dostert | Socket-like communication API for Java |
US20060143398A1 (en) * | 2004-12-23 | 2006-06-29 | Stefan Rau | Method and apparatus for least recently used (LRU) software cache |
US7451275B2 (en) | 2004-12-28 | 2008-11-11 | Sap Ag | Programming models for storage plug-ins |
US7840760B2 (en) | 2004-12-28 | 2010-11-23 | Sap Ag | Shared closure eviction implementation |
US20060143256A1 (en) * | 2004-12-28 | 2006-06-29 | Galin Galchev | Cache region concept |
US20060143595A1 (en) * | 2004-12-28 | 2006-06-29 | Jan Dostert | Virtual machine monitoring using shared memory |
US20060143385A1 (en) * | 2004-12-28 | 2006-06-29 | Michael Wintergerst | Storage plug-in based on shared closures |
US20060143427A1 (en) * | 2004-12-28 | 2006-06-29 | Dirk Marwinski | Storage plug-in based on hashmaps |
US20060143394A1 (en) * | 2004-12-28 | 2006-06-29 | Petev Petio G | Size based eviction implementation |
US20060143393A1 (en) * | 2004-12-28 | 2006-06-29 | Petev Petio G | Least frequently used eviction implementation |
US20060143388A1 (en) * | 2004-12-28 | 2006-06-29 | Michael Wintergerst | Programming models for eviction policies |
US10007608B2 (en) | 2004-12-28 | 2018-06-26 | Sap Se | Cache region concept |
US9009409B2 (en) | 2004-12-28 | 2015-04-14 | Sap Se | Cache region concept |
US8799359B2 (en) | 2004-12-28 | 2014-08-05 | Sap Ag | Session management within a multi-tiered enterprise network |
US7996615B2 (en) | 2004-12-28 | 2011-08-09 | Sap Ag | Cache region concept |
US7971001B2 (en) | 2004-12-28 | 2011-06-28 | Sap Ag | Least recently used eviction implementation |
US20060143389A1 (en) * | 2004-12-28 | 2006-06-29 | Frank Kilian | Main concept for common cache management |
US7437516B2 (en) | 2004-12-28 | 2008-10-14 | Sap Ag | Programming models for eviction policies |
US20060143392A1 (en) * | 2004-12-28 | 2006-06-29 | Petev Petio G | First in first out eviction implementation |
US7493449B2 (en) | 2004-12-28 | 2009-02-17 | Sap Ag | Storage plug-in based on hashmaps |
US7512737B2 (en) | 2004-12-28 | 2009-03-31 | Sap Ag | Size based eviction implementation |
US20100268881A1 (en) * | 2004-12-28 | 2010-10-21 | Galin Galchev | Cache region concept |
US7523263B2 (en) | 2004-12-28 | 2009-04-21 | Michael Wintergerst | Storage plug-in based on shared closures |
US7539821B2 (en) | 2004-12-28 | 2009-05-26 | Sap Ag | First in first out eviction implementation |
US7552284B2 (en) | 2004-12-28 | 2009-06-23 | Sap Ag | Least frequently used eviction implementation |
US7694065B2 (en) | 2004-12-28 | 2010-04-06 | Sap Ag | Distributed cache architecture |
US20060143387A1 (en) * | 2004-12-28 | 2006-06-29 | Petev Petio G | Programming models for storage plug-ins |
US20090282196A1 (en) * | 2004-12-28 | 2009-11-12 | Sap Ag. | First in first out eviction implementation |
US7516277B2 (en) | 2005-04-28 | 2009-04-07 | Sap Ag | Cache monitoring using shared memory |
US20060248276A1 (en) * | 2005-04-28 | 2006-11-02 | Frank Kilian | Cache monitoring using shared memory |
US20060248131A1 (en) * | 2005-04-29 | 2006-11-02 | Dirk Marwinski | Cache isolation model |
US7581066B2 (en) | 2005-04-29 | 2009-08-25 | Sap Ag | Cache isolation model |
US7831634B2 (en) | 2005-04-29 | 2010-11-09 | Sap Ag | Initializing a cache region using a generated cache region configuration structure |
US7689660B2 (en) * | 2005-06-09 | 2010-03-30 | Sap Ag | Application server architecture |
US20060282509A1 (en) * | 2005-06-09 | 2006-12-14 | Frank Kilian | Application server architecture |
US7966412B2 (en) | 2005-07-19 | 2011-06-21 | Sap Ag | System and method for a pluggable protocol handler |
US20070067469A1 (en) * | 2005-07-19 | 2007-03-22 | Oliver Luik | System and method for a pluggable protocol handler |
US20070156869A1 (en) * | 2005-12-30 | 2007-07-05 | Galin Galchev | Load balancing algorithm for servicing client requests |
US8707323B2 (en) | 2005-12-30 | 2014-04-22 | Sap Ag | Load balancing algorithm for servicing client requests |
US20080163063A1 (en) * | 2006-12-29 | 2008-07-03 | Sap Ag | Graphical user interface system and method for presenting information related to session and cache objects |
CN101876906A (en) * | 2010-03-31 | 2010-11-03 | 北京播思软件技术有限公司 | Method and device for running Linux application in Android system |
WO2011120288A1 (en) * | 2010-03-31 | 2011-10-06 | 北京播思软件技术有限公司 | Method and device for running linux application in android system |
US10248349B2 (en) * | 2016-03-22 | 2019-04-02 | Oracle International Corporation | Efficient and thread-safe objects for dynamically-typed languages |
Also Published As
Publication number | Publication date |
---|---|
US20080066081A1 (en) | 2008-03-13 |
US8201187B2 (en) | 2012-06-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8201187B2 (en) | Object monitoring system in shared object space | |
US8689232B2 (en) | Object synchronization in shared object space | |
US7543301B2 (en) | Shared queues in shared object space | |
US10181981B2 (en) | Performance and security management of applications deployed in hosted computing environments | |
US5729739A (en) | Persistent object mapping system and method with abstract schema mapper | |
KR100574156B1 (en) | Accessing legacy applications from the internet | |
US6026236A (en) | System and method for enabling software monitoring in a computer system | |
US9411616B2 (en) | Classloader/instrumentation approach for invoking non-bound libraries | |
US5748881A (en) | Method and apparatus for a real-time data collection and display system | |
JP3595340B2 (en) | Recoverable proxy objects in an object-oriented environment | |
US8631401B2 (en) | Capacity planning by transaction type | |
US6263488B1 (en) | System and method for enabling software monitoring in a computer system | |
US6226693B1 (en) | Method and system for logical event management | |
US7689986B2 (en) | Shared listeners in shared object space | |
US7150001B1 (en) | System and method to facilitate design-time component discovery | |
US20030005168A1 (en) | System and method for auditing system call events with system call wrappers | |
KR20010022458A (en) | Computerized system and associated method for optimally controlling storage and transfer of computer programs on a computer network | |
US20070198705A1 (en) | System and method for integrating resources in a network | |
US20040111707A1 (en) | Debugger for multiple processors and multiple debugging types | |
JPH09171473A (en) | Method for management of error and data-processing system | |
Pike | 81⁄ 2, the Plan 9 Window System | |
US5694597A (en) | Method and system for optimizing access to a datastore | |
Orr et al. | Dynamic program monitoring and transformation using the OMOS object server | |
Hunt et al. | Coign: Efficient instrumentation for inter-component communication analysis | |
Ashton et al. | SunOS Minix: a tool for use in Operating System Laboratories |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GEMSTONE SYSTEMS, INC., OHIO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MONNIE, DAVID J.;BRETL, ROBERT;NASTOS, MICHAEL A.;AND OTHERS;REEL/FRAME:014989/0806 Effective date: 20031103 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: VMWARE, INC., CALIFORNIA Free format text: MERGER;ASSIGNOR:GEMSTONE SYSTEMS, INC.;REEL/FRAME:026221/0770 Effective date: 20110502 |