Techniques for selectively promoting objects in a generational garbage collector are provided. Rather than using a single promotion policy, information about objects are used to determine and effectively enforce a suitable promotion policy for them. This information, for example, may be information about the general context under which the object is allocated or executed, or it may pertain to a particular operation, thread, function (or method) where garbage is likely to be generated and/or mostly garbage is generated. When it is determined that garbage is likely to be generated or mostly garbage is to be generated, a more suitable promotion policy can be enforced rather than a general (or normal). objects are allocated using two or more memory allocators. Typically, objects that are likely to be garbage are allocated in a manner that effectively delays or bars their promotion to the next generation.
|
27. A computer readable storage medium including computer program code for allocating objects in a memory portion that includes a young generation and at least one older generation, said computer readable medium including comprising:
computer program code for allocating one or more objects in said young generation in accordance with a first promotion policy exercised for promoting objects from said young generation to an older generation of said memory portion; and
computer program code for allocating one or more other objects in said young generation in accordance with a second promotion policy exercised for postponing or cancelling promoting objects form said young generation to an older generation of said memory portion wherein the determination to allocate the objects in accordance with the second promotion policy includes at least evaluating the characteristics of each of the objects of the set of objects to determine a likelihood that each object will become garbage within a predetermined number of garbage collection cycles, and wherein the objects to which the second promotion policy is applied are not evaluated in accordance with the first promotion policy, and,
wherein,
each of said one or more objects includes a header that indicates said second promotion policy.
14. A computer system, comprising:
at least one processing unit;
a memory portion that is partitioned into a young generation and at least one older generation;
a first memory allocator that operates to allocate one or more objects in said young generation in accordance with a first promotion policy for promoting said one or more objects from said young generation to an older generation in said memory; and
a second memory allocator that operates to allocate one or more'other objects in said young generation in accordance with a second promotion policy for at least postponing promoting said one or more other objects from said young generation to an older generation in said memory relative to the promoting performed in accordance with the first promotion policy wherein the determination to allocate the objects in accordance with the second promotion policy includes at least evaluating the characteristics of each of the objects of the set of objects to determine a likelihood that each object will become garbage within a predetermined number of garbage collection cycles, and wherein the objects to which the second promotion policy is applied are not evaluated in accordance with the first promotion policy, and, wherein the one or more other objects are being allocated by system code or are associated with an operation predefined as likely to generate garbage.
1. A method in a data processing system having a program for allocating objects in a memory portion that includes a young generation and at least one older generation, said method comprising:
(a) for each of the objects, determining whether at least one object should be allocated in said young generation in accordance with a first promotion policy exercised for promoting objects from said young generation to an older generation of said memory portion;
(b) based on the determining whether each of the objects should be allocated using the first promotion policy, determining whether said at least one object should be allocated in said young generation in accordance with a second promotion policy exercised for at least postponing promoting objects from said young generation to said older generation relative to the first promotion policy, wherein the determination includes at least evaluating the characteristics of each of the objects of the set of objects to determine a likelihood that each object will become garbage within a predetermined number of garbage collection cycles, and wherein the objects to which the second promotion policy is applied are not evaluated in accordance with the first promotion policy; and
(c) storing each of the objects in said young generation in accordance with said first or second promotion policy and providing an indication of said second promotion policy in a header for a subset of the objects, the indication used during a promoting step to preempt use of the first promotion policy.
30. A computer readable storage medium including computer program code for allocating objects in a memory portion that includes a young generation and at least one older generation, said computer readable medium including comprising:
computer program code for allocating all of the objects into said young generation in accordance with either a first promotion policy exercised for promoting objects from said young generation to an older generation of said memory portion or a second promotion policy exercised for promoting objects from said young generation to an older generation of said memory portion, wherein the second promotion policy defines a longer tenure for the objects in the young generation than the first promotion policy, wherein the determination to allocate the objects in accordance with the second promotion policy includes at least evaluating the characteristics of each of the objects of the set of objects to determine a likelihood that each object will become garbage within a predetermined number of garbage collection cycles, and wherein the objects to which the second promotion policy is applied are not evaluated in accordance with the first promotion policy; and
computer program code for promoting live ones of the objects allocated in the young generation to the older generation, the promoting being performed for each object involving first determining whether the object was allocated using the first or the second promotion policy and second applying the determined one of the first and second promotion policies.
2. The method as recited in
determining whether said at least one object is used as temporary data.
3. The method as recited in
determining whether said at least one object is garbage.
4. The method as recited in
5. The method as recited in
determining whether said at least one object is garbage.
6. The method as recited in
7. The method as recited in
determining whether system code is allocating said object; and
wherein said method further comprises:
selecting a second promotion policy that postpones the promotion of said at least one object with respect to other objects allocated in accordance with said first promotion policy.
8. The method as recited in
determining whether one or more of the following operations are being performed: loading a class, parsing a file that represents a class, dynamic compilation, and a call to a library function that generates temporary data.
9. The method as recited in
10. The method as recited in
11. The method as recited in
12. The method as recited in
wherein said preemption indicator indicates that a garbage collection count should be preempted;
wherein said preemption value provides a preemptive garbage collection count that is used instead of a garbage collection count.
13. The method as recited in
15. The computer system as recited in
an allocation interface that can be used to access both said first and second memory allocators,
wherein,
said allocation interface operates to use said first or second memory allocators in accordance with an allocation selection, and
an allocation switching function that can be used to switch said allocation selection from said first memory allocator to said second memory allocator.
16. The computer system as recited in
17. The computer system as recited in
determines whether at least one object should not be allocated using said first memory allocator in said young generation in accordance with said first promotion; and
determines said second promotion policy used by said second allocator when it is determined that at least one object should not be allocated in said young generation in accordance with said first promotion.
18. The computer system as recited in
19. The computer system as recited in
a garbage collector that reads said header and promotes said at least one object in accordance with said header.
20. The computer system as recited in
21. The computer system as recited in
22. The computer system as recited in
said preemption indicator indicates that a garbage collection count should be preempted; and
said preemption value provides a preemptive garbage collection count that is used instead of said garbage collection count.
23. The computer system as recited in
25. The computer system as recited in
26. The computer system as recited in
28. The computer readable medium as recited in
29. The computer readable medium as recited in
31. The computer readable medium as recited in
|
This invention is related to U.S. Provisional Patent Application No. 60/532,460, filed on Dec. 24, 2003, and entitled: “SMART GARBAGE COLLECTION FOR COMPUTING ENVIRONMENTS”. That application is incorporated herein by reference in its entirety and for all purposes.
This invention is related to U.S. Provisional Patent Application No. 60/532,541, filed on Dec. 24, 2003, and entitled: “SMART GARBAGE COLLECTION FOR COMPUTING ENVIRONMENTS”. That application is incorporated herein by reference in its entirety and for all purposes.
The present invention relates generally to computing systems, and more particularly, to techniques for allocation and garbage collection of objects of an object-oriented programming language.
From a computer programming perspective, data which is no longer needed by a computer program can be referred to as “garbage.” In the past, programmers had to write programs that explicitly requested allocation of data and then returned it to the system (e.g., operating system) when it was no longer needed. As such, programs that neglected to return unused storage could have been shut down by the operating system.
Today, some programming languages, such as LISP, and Java™ programming languages, provide a “garbage collector” that frees programmers from concerns about explicitly freeing memory. A garbage collector is useful because it cleans up the memory space by identifying objects that are no longer needed. The memory space can be reclaimed for a more meaningful use. In programming languages such as Java™, a portion of memory is provided as a “heap” for allocation and storage of objects. In a heap, some objects become garbage shortly after their creation, some survive for a long time and then become garbage, and others can remain alive for the entire duration of the program.
A variety of garbage collection schemes can be used to free the memory (e.g., heap) from objects that are no longer used (i.e., have become garbage). Some garbage collection schemes use a “generational” garbage collector. A generational garbage collector divides memory (e.g., a heap) into multiple generations. Typically, the heap is divided into a Young Generation and one or more Older Generations. Objects are initially allocated in the Young Generation. If an object in the Young Generation meets some “promotion” criteria, such as having survived a certain number of collections, then the object is “promoted” to the next generation, namely, an Older Generation, and possibly promoted to the next Older Generation, and so on.
Generally, a generational collector is free to use a different collection strategy for different generations and perform garbage collection on each of the generations separately. Typically, most garbage is collected from the Young Generation. Hence, the garbage collection strategy used in the Young Generation can have a significant amount of influence on overall system performance.
A generational garbage collection scheme is an effective strategy, especially for computing environments that operate with a relatively limited processing power and/or memory (e.g., embedded, handheld, or mobile devices, virtual machine used for smaller devices, etc.). Conventional generational garbage collectors promote all objects in the Young Generation in accordance with a single promotion policy. A single promotion policy, however, typically results in prematurely promoting some objects to the next generation. In other words, some objects are promoted to the next generation even though they become garbage after they have been moved to the next generation.
Accordingly, improved garbage collection strategies are needed.
As noted in the background section, conventional generational garbage collectors promote all objects in the Young Generation in accordance with a single policy. This results in premature promotion of some objects that become garbage after they have been moved to the next generation.
Prematurely promoting an object has many drawbacks. One drawback is that it is typically more expensive to garbage collect an Older Generation rather than the Young Generation. As a general rule, garbage collection of an Older Generation should be minimized to achieve better system performance. Another drawback of prematurely promoting an object is the unnecessary use of the space reserved for the Older Generations, which in turn, adversely affects performance by increasing the frequency of garbage collection cycles for the Older Generations. In some computing environments (e.g., virtual machines) yet additional resources are needlessly used to promote objects when objects are prematurely promoted. By way of example, more invocations of garbage collection write barriers are needed to track the inter-generational references (or pointers) and/or more scans of the recorded write barrier entries are needed. Accordingly, improved garbage collection strategies are needed.
Broadly speaking, the invention relates to techniques for selectively promoting objects in a generational garbage collector. As will be appreciated, these techniques can improve the performance of computing systems, especially those that operate with a relatively small amount of memory and/or processing power (e.g., embedded or handheld devices, virtual machine used for smaller devices, etc.)
The invention utilizes information about objects to determine and effectively enforce a suitable promotion policy for them. This information, for example, may be information about the general context under which the object is allocated or executed. As another example, the information may be concerning a particular operation, thread, function (or method) where garbage is likely to be generated and/or mostly garbage is likely to be generated. By way of example, operations such as class loading, parsing of classfiles, and dynamic compilation which are performed by system code are likely to generate temporary data or mostly temporary data that is likely to become garbage before the user program terminates. As such, memory allocated by system code can be considered to be likely garbage, or mostly garbage. In addition, some particular functions (or methods) are also likely to generate temporary data or mostly temporary data that is likely to become garbage or be mostly garbage. By way of example, concatenation of strings in the Java™ programming language is an operation that is commonly used and generates temporary data or mostly temporary data that is likely to become garbage, or become mostly garbage.
In accordance with one aspect of the invention, a plurality of promotion policies are determined and effectively enforced to promote objects from the Young Generation to an Older Generation. As a result, each object can be promoted in accordance with a promotion policy that is more suitable for that particular object. In one embodiment, when it is determined that garbage is likely to be generated or mostly garbage is to be generated, a more suitable promotion policy can be enforced rather than a general (or normal) promotion policy for all objects. In other words, the general (or normal) promotion policy can be preempted by a more suitable promotion policy when it is deemed appropriate.
Objects are allocated using two or more memory allocators in accordance with another aspect of the invention. Typically, objects that are likely to be garbage are allocated in a manner that effectively delays or bars their promotion to the next generation. In one embodiment, a preemptive memory allocator is provided. Rather than using a general memory allocator, the preemptive memory allocator can be used to allocate objects that are likely to be garbage. An object can, for example, be allocated with a header that indicates to a generational garbage collector that the promotion of an object to the next generation should be postponed or altogether avoided. Hence, the number of objects that are prematurely promoted is reduced. As a result, system performance is improved, especially when a relatively small amount of memory and/or processing power is used (e.g., embedded or handheld devices, virtual machine used for smaller devices, etc.)
The invention can be implemented in numerous ways, including as a method, a computer system and a computer readable storage medium. Although aspects of methods, systems, and articles of manufacture consistent with the present invention are depicted as being stored in memory, one having skill in the art will appreciate that these aspects may be stored on or read from other computer-readable media, such as computer-readable storage media like secondary storage devices, such as hard disks, floppy disks, CD-ROM, or other forms of ROM, RAM, or NVRAM, either currently known or developed in the future. Several embodiments of the invention are discussed below.
These and other aspects and advantages of the present invention will become more apparent when the detailed description below is read in conjunction with the accompanying drawings.
The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:
As noted in the background section, conventional generational garbage collectors promote all objects in accordance with a single promotion policy. This results in prematurely promoting some objects that are likely to become garbage after they have been moved to the next generation. Prematurely promoting an object has many drawbacks. One drawback is that it is typically more expensive to garbage collect an Older Generation rather than the Young Generation. As a general rule, garbage collection of an Older Generation should be minimized to achieve better system performance. Another drawback of prematurely promoting an object is the unnecessary use of the space reserved for the Older Generations, which in turn, adversely affects performance by increasing the frequency of garbage collection cycles for the Older Generations. In some computing environments (e.g., virtual machines) yet additional resources are needlessly used to promote objects when objects are prematurely promoted. By way of example, more invocations of garbage collection write barriers are needed to track the inter-generational references (or pointers) and/or more scans of the recorded write barrier entries are needed. Accordingly, improved garbage collection strategies are needed.
Broadly speaking, the invention relates to techniques for selectively promoting objects in a generational garbage collector. As will be appreciated, these techniques can improve the performance of computing systems, especially those that operate with a relatively small amount of memory and/or processing power (e.g., embedded or handheld devices, virtual machine used for smaller devices, etc.)
The invention utilizes information about objects to determine and effectively enforce a suitable promotion policy for them. This information, for example, may be information about the general context under which the object is allocated or executed. As another example, the information may be concerning a particular operation, thread, function (or method) where garbage is likely to be generated and/or mostly garbage is likely to be generated. By way of example, operations such as class loading, parsing of classfiles, and dynamic compilation which are performed by system code are likely to generate temporary data or mostly temporary data that is likely to become garbage before the user program terminates. As such, memory allocated by system code can be considered to be likely garbage, or mostly garbage. In addition, some particular functions (or methods) are also likely to generate temporary data or mostly temporary data that is likely to become garbage or be mostly garbage. By way of example, concatenation of strings in the Java™ programming language is an operation that is commonly used and generates temporary data or mostly temporary data that is likely to become garbage, or become mostly garbage.
In accordance with one aspect of the invention, a plurality of promotion policies are determined and effectively enforced to promote objects from the Young Generation to an Older Generation. As a result, each object can be promoted in accordance with a promotion policy that is more suitable for that particular object. In one embodiment, when it is determined that garbage is likely to be generated or mostly garbage is to be generated, a more suitable promotion policy can be enforced rather than a general (or normal) promotion policy for all objects. In other words, the general (or normal) promotion policy can be preempted by a more suitable promotion policy when it is deemed appropriate.
Objects are allocated using two or more memory allocators in accordance with another aspect of the invention. Typically, objects that are likely to be garbage are allocated in a manner that effectively delays or bars their promotion to the next generation. In one embodiment, a preemptive memory allocator is provided. Rather than using a general memory allocator, the preemptive memory allocator can be used to allocate objects that are likely to be garbage. An object can, for example, be allocated with a header that indicates to a generational garbage collector that the promotion of an object to the next generation should be postponed or altogether avoided. Hence, the number of objects that are prematurely promoted is reduced. As a result, system performance is improved, especially when a relatively small amount of memory and/or processing power is used (e.g., embedded or handheld devices, virtual machine used for smaller devices, etc.)
Embodiments of the invention are discussed below with reference to
The memory 106 can, for example, represent heap memory used for allocation of objects of an object-oriented programming language (e.g., Java™ programming language. It should be noted that the garbage collector 104 is a generational garbage collector. As such, memory 106 is partitioned into a Young Generation portion 108 and one or more Older Generations OG1, . . . , OGn. New objects are initially allocated by the smart memory allocation system 102 in the Young Generation 108 of the memory 106. Some of the new objects allocated by the smart memory allocation system 102 in the Young Generation 108 may eventually be “promoted” to an Older Generation if they still remain in use (“alive”) when a garbage collection threshold (or promotion threshold) is reached. This garbage collection threshold (or promotion threshold) can, for example, be based on the number of garbage collection cycles that an object has survived. As will be appreciated, unlike conventional garbage collection schemes, promotion of objects from the Young Generation 108 to an Older Generation (e.g., OG1) may be selectively controlled. In other words, promotion may be delayed, avoided, or even expedited relative to a general threshold (“normal threshold”) used to generally promote objects. By way of example, promotion of an object may be delayed beyond a normal promotion threshold, delayed relative to another object, effectively delayed indefinitely, or accelerated.
As will be appreciated, the smart memory allocation system 102 can selectively delay or expedite promotion of an object to the next generation. Referring to
As illustrated in
In any case, the smart allocation system 102 can allocate objects using a general (normal) mode M1 or a preemption mode M2. By way of example, an object 120 is allocated by the smart allocation system 102 in the Young Generation 108 using the normal mode M1. Object 120 may be promoted to an Older Generation OG1 in accordance with a general (or normal) promotion policy that indicates that any object in the Young Generation 108 that may still be used (alive) after N (e.g., four (4)) garbage collection cycles will be promoted to the next generation. As such, object 120 will be promoted to the next generation, namely, Older Generation 1 (OG1) if it is still alive after N (e.g., four (4)) garbage collection cycles. Object 122, however, is allocated by the smart allocation system 102 in the Young Generation 108 using the preemption mode M2. As such, object 122 may not be promoted to the next generation even if it is still alive after N (e.g., four (4)) garbage collection cycles. In other words, object 122 is promoted in accordance with another policy that preempts the general promotion policy enforced for object 120. In one embodiment, object 122 is marked with a preemption policy indicator (or marking) which indicates that a general promotion policy should not be enforced for the object and/or indicates a particular promotion policy that should be enforced for this object.
Referring now to
Other embodiments of the invention can be used to promote objects in accordance with a particular policy rather than preventing promotion per se.
By way of example, while a code portion 308 is being executed, the allocation interface 302 may be in position S1 and switched to the general memory allocation 304. This means that a general allocation policy can be enforced. As a result, objects allocated with the general allocator 304 will be promoted in accordance with a general policy. However, before the code portion 310 is executed, a switch function can be called to change the allocation policy. In effect, when the code portion 310 is executed, the allocation switch is moved from the S1 to S2 position to inactivate the general memory allocator 304 and activate the preemptive memory allocator 306. As a result, all functions in the code portion 310 will use the preemptive memory allocator 306 even though the same allocation interface 302 is used. Hence, a function that may be nested or called by another function in the code portion 310 will allocate memory using the preemptive memory allocator 306.
The switch in allocation policy may, for example, be made based on some external input or insight that indicates that it is likely that the object(s) being allocated will be garbage that can be collected and/or it is likely that a significant amount of objects that are garbage will be generated. One such example is system code that is run as part of the runtime environment. Unlike the application program code, system code is typically performed to provide a runtime environment that, among other things, supports execution of an application program rather than executing the application code itself. As such, system code typically generates temporary objects that will eventually be garbage. By way of example, class loading, parsing, and dynamic compilation that are performed in platform independent programming environments (e.g., Java™ programming environment) are operations that typically generate temporary objects that will eventually be garbage. Typically, all these operations are performed by system code. Therefore, during execution of system code, the allocation policy may be switched to the preemptive memory allocator 306 in accordance with one aspect of the invention. The allocation policy may be switched for different threads or based on different contexts of the same code. In general, the switch to the preemptive memory allocator 306 may be made for any context-specific code that allocates objects that are likely to become garbage or are likely to be mostly garbage.
In other cases, however, it may be desirable to have a particular function directly use the preemptive memory allocator 306.
Direct access to the preemptive memory allocator 350 can be used, among other things, by library methods (or functions) used in a high-level programming language. By way of example, a library method can use the preemptive memory allocator 350 for concatenation of strings in Java™ programming language. This means that the “+” operator for string objects (used to indicate a concatenation operation) may be implemented to call, for example, a “StringBuffer.appendwithLikelyGarbageAllocation,” rather than the conventional “StringBuffer.append.” As will be appreciated, operations like concatenations of strings in Java™ which are often used and are often likely to generate temporary data can directly access (e.g., call) the preemptive memory allocator 350.
Typically, the preemption policy is determined 406 so that promotion of the one or more objects to the next generation of the memory is delayed. It should be noted that the one or more objects were determined 404 to be likely garbage or likely to be mostly garbage. As such, a reasonable promotion policy would be one that delays promotion beyond the general (normal) promotion time. By way of example, the general (normal) promotion policy may be to promote an object if it has survived four (4) garbage collection cycles. In this case, a reasonable preemption policy that is determined 406 above, may be to promote the one or more objects after five (5) or more garbage collection cycles (e.g., 6, 7, 8, 9, 10, 12, 20, 40, 50, 100, 1000, etc.). As will be appreciated, the preemption policy can be determined 406 based on system and/or application program requirements (e.g., memory space, speed, type of application).
Accordingly, one or more preemption values and/or indictors are generated 410 based on the promotion policy determined 406 for the one or more objects. The one or more preemption values and/or indictors are generated based on the preemption policy so that the general promotion policy can effectively be preempted for these objects. For example, a header can be generated in accordance with embodiments shown in
Initially, a Garbage Collection Count (GCC) is read 502 for the object. The Garbage Collection Count is a positive integer which has been initialized for the object when the object was allocated. The Garbage Collection Count (GCC) reflects the promotion policy that has been selected for the object. In this example, larger integer values, correspond to longer waiting periods.
After the Garbage Collection Count (GCC) is read 502, it is determined 504 whether a Garbage Collection Count (GCC), is equal to zero (0). If it is determined 504 that the Garbage Collection Count (GCC) is greater than zero, the value of the Garbage Collection Count (GCC) is decreased 506, by one and the object promotion method 500 ends. It should be noted that for the embodiment shown in
However, if it is determined 504 that the Garbage Collection Count (GCC) is equal to zero (0), it is determined 508 whether a preemption indicator (e.g., preemption indicator 222 of
On the other hand, if it is determined 508 that a preemption indicator is set, it is determined 512 whether a preemption value (e.g., 220 of
The many features and advantages of the present invention are apparent from the written description, and thus, it is intended by the appended claims to cover all such features and advantages of the invention. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation as illustrated and described. Hence, all suitable modifications and equivalents may be resorted to as falling within the scope of the invention.
Fresko, Nedim, Mathiske, Bernd J., Pliss, Oleg
Patent | Priority | Assignee | Title |
10002074, | Sep 04 2013 | Red Hat, Inc. | Non-intrusive storage of garbage collector-specific management data |
10120796, | Sep 14 2012 | SAP SE | Memory allocation for long-lived objects |
9361224, | Sep 04 2013 | Red Hat, Inc | Non-intrusive storage of garbage collector-specific management data |
9921958, | Dec 08 2015 | International Business Machines Corporation | Efficiently using memory for java collection objects |
Patent | Priority | Assignee | Title |
5857210, | Jun 26 1997 | Oracle America, Inc | Bounded-pause time garbage collection system and method including read and write barriers associated with an instance of a partially relocated object |
6490599, | Oct 07 1998 | International Business Machines Corporation | On-the-fly garbage collector |
6493730, | Oct 10 2000 | Oracle America, Inc | Efficient object faulting with generational garbage collection |
6839725, | May 16 2000 | Oracle America, Inc | Dynamic adaptive tenuring of objects |
7024437, | Dec 06 2002 | Oracle America, Inc | Better placement of objects reachable from special objects during collection based on the train algorithm |
20030187888, | |||
20030212719, | |||
20040167945, | |||
20050138623, | |||
20050149585, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Apr 07 2004 | FRESKO, NEDIM | Sun Microsystems, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 015206 | /0529 | |
Apr 07 2004 | PLISS, OLEG | Sun Microsystems, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 015206 | /0529 | |
Apr 09 2004 | Oracle America, Inc. | (assignment on the face of the patent) | / | |||
Apr 09 2004 | MATHISKE, BERND J | Sun Microsystems, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 015206 | /0529 | |
Feb 12 2010 | ORACLE USA, INC | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037306 | /0556 | |
Feb 12 2010 | Sun Microsystems, Inc | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037306 | /0556 | |
Feb 12 2010 | Oracle America, Inc | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037306 | /0556 |
Date | Maintenance Fee Events |
Jan 25 2011 | ASPN: Payor Number Assigned. |
Jan 25 2011 | RMPN: Payer Number De-assigned. |
May 14 2014 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
May 31 2018 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jun 01 2022 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Dec 14 2013 | 4 years fee payment window open |
Jun 14 2014 | 6 months grace period start (w surcharge) |
Dec 14 2014 | patent expiry (for year 4) |
Dec 14 2016 | 2 years to revive unintentionally abandoned end. (for year 4) |
Dec 14 2017 | 8 years fee payment window open |
Jun 14 2018 | 6 months grace period start (w surcharge) |
Dec 14 2018 | patent expiry (for year 8) |
Dec 14 2020 | 2 years to revive unintentionally abandoned end. (for year 8) |
Dec 14 2021 | 12 years fee payment window open |
Jun 14 2022 | 6 months grace period start (w surcharge) |
Dec 14 2022 | patent expiry (for year 12) |
Dec 14 2024 | 2 years to revive unintentionally abandoned end. (for year 12) |