Computer-implemented method, computer program, and computer processing system for managing garbage collection (GC) safe points (Selective injection of GC safe points for JNI calls)

Abstract

To provide a computer-implemented method in order to manage garbage collection (GC) safepoints.SOLUTION: A method includes a step of determining whether a GC safepoint for a target native method can be removed by checking a heap occupancy ratio prior to executing the target native method. The method further includes a step of removing the GC safepoint responding to the heap occupancy ratio prior to executing the target native method being less than a threshold occupancy amount percentage. The method also includes a step of determining whether the GC safepoint for the target native method can be removed by checking a most recent GC pause time. The method additionally includes a step of removing the GC safepoint responding to the most recent GC pause time being shorter by a threshold pause time amount percentage than an execution time of the target native method.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates generally to computing systems, and more particularly to selective injection of garbage collection (GC) safepoints for Java Native Interface (JNI) calls. [Background technology]

[0002] When garbage collection (GC) is required, mutator threads are suspended at GC safe points and wait for the GC to finish. The Java Virtual Machine (JVM) inserts GC safe points at appropriate locations in Java code. GC safe points are before and after calls to native methods. In OpenJDK, the state of mutator threads changes before and after a GC safe point. To accurately recognize the state, a full memory fence is required at the safe point. In OpenJDK, GC can be performed even when native methods are running. Under high GC frequencies, the more GC safe points are inserted, the faster the application will run.

[0003] However, if native methods are executed frequently, they may suffer due to full memory fences at GC safe points, which can result in a poor overall application performance. Summary of the Invention [Problem to be solved by the invention]

[0004] According to aspects of the present invention, a computer-implemented method is provided for managing garbage collection (GC) safepoints. [Means for solving the problem]

[0005] The method includes determining whether a GC safepoint for the target native method can be removed by checking the heap occupancy before executing the target native method. The method further includes removing the GC safepoint in response to the heap occupancy before executing the target native method being less than a threshold occupancy percentage. The method also includes determining whether a GC safepoint for the target native method can be removed by checking the most recent GC pause time. The method additionally includes removing the GC safepoint in response to the most recent GC pause time being less than the execution time of the target native method by a threshold pause time amount percentage.

[0006] According to another aspect of the present invention, a computer program product is provided for managing garbage collection (GC) safe points. The computer program product comprises a non-transitory computer-readable storage medium having program instructions embodied thereon. The program instructions are executable by a computer to cause the computer to perform a method. The method includes determining whether a GC safe point for a target native method can be removed by checking a heap occupancy before executing the target native method. The method further includes removing the GC safe point in response to the heap occupancy before executing the target native method being less than a threshold occupancy percentage. The method also includes determining whether a GC safe point for the target native method can be removed by checking a most recent GC pause time. The method further includes removing the GC safe point in response to the most recent GC pause time being less than the execution time of the target native method by a threshold pause time amount percentage.

[0007] According to yet another aspect of the present invention, a computer processing system is provided for managing garbage collection (GC) safe points. The computer processing system includes a memory device for storing program code. The computer processor system further includes a processor device operatively coupled to the memory device for executing program code to remove a GC safe point in response to either (i) the heap occupancy before executing a target native method being less than a threshold occupancy percentage, and (ii) the most recent GC pause time being less than the execution time of the target native method by the threshold pause time amount percentage.

[0008] These and other features and advantages will become apparent from the following detailed description of exemplary embodiments, which should be read in connection with the accompanying drawings. [Brief explanation of the drawings]

[0009] The following description provides details of preferred embodiments with reference to the following drawings:

[0010] [Figure 1] FIG. 1 is a block diagram illustrating an exemplary computing device according to one embodiment of the present invention.

[0011] [Figure 2] 1 illustrates an exemplary execution flow of a native method according to one embodiment of the present invention.

[0012] [Figure 3] FIG. 1 is a flow diagram illustrating an exemplary method for GC safepoint management, according to one embodiment of the present invention.

[0013] [Figure 4] FIG. 2 illustrates an exemplary scenario involving heap occupancy, according to one embodiment of the present invention.

[0014] [Figure 5] FIG. 5 further illustrates the example scenario of FIG. 4, according to one embodiment of the present invention.

[0015] [Figure 6] 1 is a block diagram illustrating an exemplary cloud computing environment having one or more cloud computing nodes in communication with local computing devices used by cloud consumers, according to one embodiment of the present invention.

[0016] [Figure 7] FIG. 2 is a block diagram illustrating a set of functional abstraction layers provided by a cloud computing environment, according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0017] Embodiments of the present invention relate to selective injection of garbage collection (GC) safepoints for Java Native Interface (JNI) calls.

[0018] In one or more embodiments relating to an application that frequently executes native methods, acceptable performance of the application is maintained even under high CG frequencies by selectively inserting safe points for the native methods.

[0019] In one or more embodiments, unnecessary GC safe points are removed for native methods when the GC frequency is low. Fewer GC safe points avoid full memory fences that can degrade the performance of native methods.

[0020] 1 is a block diagram illustrating an exemplary computing device 100 according to one embodiment of the present invention, configured to perform GC safepoint management (e.g., selective injection of GC safepoints for JNI calls).

[0021] Computing device 100 may be embodied as any type of computing device or computer device capable of performing the functions described herein, including, but not limited to, a computer, a server, a rack-based server, a blade server, a workstation, a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, a wearable computing device, a network appliance, a web appliance, a distributed computing system, a processor-based system, or a consumer electronics device, or any combination thereof. Additionally or alternatively, computing device 100 may be embodied as one or more compute sleds, memory sleds, or other racks, sleds, computing chassis, or other components of a physically separated computing device. As shown in FIG. 1 , computing device 100 illustratively includes a processor 110, an input / output subsystem 120, a memory 130, a data storage device 140, a communications subsystem 150, or other components and devices commonly found in a server or similar computing device, or any combination thereof. Of course, in other embodiments, computing device 100 may include other or additional components, such as components typically found in a server computer (e.g., various input / output devices). Additionally, in some embodiments, one or more of these example components may be incorporated within or form a portion of another component. For example, in some embodiments, memory 130, or portions thereof, may be incorporated within processor 110.

[0022] Processor 110 may be embodied as any type of processor capable of performing the functions described herein, including a single processor, multiple processors, a central processing unit (CPU), a graphics processing unit (GPU), a single or multi-core processor, a digital signal processor, a microcontroller, or other processor or processing / control circuitry.

[0023] Memory 130 may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. During operation, memory 130 may store various data and software used during the operation of computing device 100, such as an operating system, applications, programs, libraries, and drivers. Memory 130 is communicatively coupled to processor 110 via I / O subsystem 120. I / O subsystem 120 may be embodied as circuits and / or components for facilitating input / output operations between processor 110, memory 130, and other components of computing device 100. For example, I / O subsystem 120 may be embodied as or include a memory controller hub, an input / output control hub, a platform controller hub, an integrated control circuit, a firmware device, a communication link (e.g., a point-to-point link, a bus link, a wire, a cable, a light guide, a printed circuit board trace, etc.), or other components and subsystems for facilitating input / output operations, or a combination thereof. In some embodiments, I / O subsystem 120 may form part of a system-on-chip (SOC) and may be integrated with processor 110, memory 130, and other components of computing device 100 on a single integrated circuit chip.

[0024] Data storage device 140 may be embodied as any type of device or devices configured for short-term or long-term storage of data, such as, for example, memory devices and circuitry, memory cards, hard disk drives, solid-state drives, or other data storage devices. Data storage device 140 may store program code for GC safepoint management (e.g., selective GC safepoint insertion for JNI calls). Communications subsystem 150 of computing device 100 may be embodied as any network interface controller or other communications circuitry device or collection thereof capable of enabling communications between computing device 100 and other remote devices over a network. Communications subsystem 150 may be configured to use any one or more communications technologies (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, InfiniBand, Bluetooth, Wi-Fi, WiMAX, etc.) to perform such communications.

[0025] As shown, computing device 100 may also include one or more peripheral devices 160. Peripheral devices 160 may include any number of additional input / output devices, interface devices, or other peripheral devices, or combinations thereof. For example, in some embodiments, peripheral devices 160 may include a display, a touchscreen, graphics circuitry, a keyboard, a mouse, a speaker system, a microphone, a network interface, and / or other input / output devices, interface devices, and / or peripheral devices.

[0026] Of course, computing device 100 may also include other elements (not shown), as would be readily apparent to one skilled in the art, and similarly, certain elements may be omitted. For example, as would be readily apparent to one skilled in the art, various other input and / or output devices may be included in computing device 100, depending on the particular implementation of computing device 100. For example, various types of wireless and / or wired input and / or output devices may be used. Moreover, additional processors, controllers, memory, etc. may also be utilized in various configurations. Furthermore, in other embodiments, cloud configurations may be used (see, e.g., FIGS. 6-7). These and other modifications of processing system 100 will be readily apparent to one skilled in the art given the teachings of the present invention provided herein.

[0027] As used herein, the terms “hardware processor subsystem” or “hardware processor” may refer to a processor, memory (including RAM, cache, etc.), software (including memory management software), or a combination thereof that cooperate to perform one or more specific tasks. In useful embodiments, the hardware processor subsystem may include one or more data processing elements (e.g., logic circuits, processing circuits, instruction execution devices, etc.). The one or more data processing elements may be included in a central processing unit, a graphics processing unit, or a separate processor or computing element-based controller (e.g., logic gates, etc.), or a combination thereof. The hardware processor subsystem may include one or more on-board memories (e.g., cache, dedicated memory array, read-only memory, etc.). In some embodiments, the hardware processor subsystem may include one or more memories that may be on-board, dedicated, or dedicated for use by the hardware processor subsystem (e.g., ROM, RAM, basic input / output system (BIOS), etc.).

[0028] In some embodiments, a hardware processor subsystem may include or execute one or more software elements, which may include an operating system, one or more applications, or both, and / or specific code for achieving a specified result.

[0029] In other embodiments, the hardware processor subsystem may include dedicated, specialized circuitry that performs one or more electronic processing functions to achieve a specified result. Such circuitry may include one or more application specific integrated circuits (ASICs), FPGAs, or PLAs, or a combination thereof.

[0030] These and other variations of the hardware processor subsystem are also contemplated according to embodiments of the present invention.

[0031] FIG. 2 illustrates an exemplary execution flow 200 of a native method according to one embodiment of the present invention.

[0032] It should be appreciated that there are two load barrier steps (2 and 7) with full memory fences (at steps 3 and 8) and corresponding GC safe points. The present invention can be applied to execution flow 200 to selectively remove GC safe points.

[0033] FIG. 3 is a flow diagram illustrating an exemplary method 300 for GC safepoint management, according to one embodiment of the present invention.

[0034] In block 310, a threshold occupancy percentage and a threshold pause time percentage are set / modified via the first and second virtual machine parameters, respectively, at virtual machine startup. In one embodiment, the threshold occupancy percentage may be set to 70 percent, and the threshold pause time percentage may be set to 10 percent. Of course, other percentages may be used, as would be readily understood by one of ordinary skill in the art given the teachings of the present invention provided herein.

[0035] For both parameters, higher values ​​can increase the chances of optimization (i.e., removal of GC safe points), but may come with the risk of incurring a penalty for applying the optimization. Users should find the optimal balanced value for their workload, moving in the higher direction. The first parameter relates to heap occupancy. Here, 70% (or somewhere in the range of 60-80%) is actually considered a good starting point for most workloads, since there is still 30% free space in the heap. 50% is probably not too challenging to try to gain gains with optimizations. In contrast, 90% is too aggressive, and regressions are likely to be observed due to applying optimizations too frequently. Regarding the second parameter, the default value (10%) is set much lower compared to the first parameter (70%) because the second parameter compares elapsed times of different nature. One is the GC pause time, which in many cases can take tens to hundreds of milliseconds. In contrast, the execution time of the target native method is often faster. Therefore, 10% seems to be a good starting point to capture a sufficient number of opportunities. Again, it is emphasized that other percentages can be used while maintaining the spirit of the present invention.

[0036] In block 320, the virtual machine records the elapsed time of the target native method when the target native method is first called.

[0037] In block 330, for a subsequent invocation of the target native method, it is determined whether the GC safepoint for the target native method can be removed by checking the heap occupancy before executing the target native method.

[0038] In block 340, the GC safepoint is removed in response to the heap occupancy being less than a threshold occupancy percentage before executing the target native method, since it is assumed that GC will not occur under these conditions.

[0039] In block 350, for a subsequent invocation of the target native method, if the heap occupancy is equal to or exceeds the threshold occupancy percentage, it is determined whether the GC safepoint for the target native method can be removed by checking the most recent GC pause time.

[0040] In block 360, a GC safepoint is removed in response to the most recent GC pause time being a threshold pause time amount percentage less than the execution time of the target native method. The GC safepoint is removed in this case because it is presumed that a GC will not occur under these conditions.

[0041] FIG. 4 illustrates an exemplary scenario 400 involving heap occupancy, according to one embodiment of the present invention.

[0042] Scenario 400 involves four threads, th1 through th4, each with a safepoint sp. Valid safepoints are shown solid, while invalid safepoints are hollow.

[0043] In scenario 400, th4 is executing a native method.

[0044] If the heap occupancy is below the threshold, th4 disables the safepoint at 410.

[0045] The elapsed time of this native method is below a threshold determined using GC pause times.

[0046] FIG. 5 is a diagram further illustrating the example scenario 400 of FIG. 4, according to one embodiment of the present invention.

[0047] In scenario 400, all threads (th1 to th4) are suspended at their respective safe points sp due to a request from the GC, which now requires a Stop-The-World.

[0048] In this scenario, th4 is executing the native method as described above.

[0049] th4 keeps this safe point available when the heap occupancy reaches a threshold or when the elapsed time of a native method exceeds a threshold determined using GC pause times.

[0050] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0051] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0052] The characteristics are as follows:

[0053] On-demand self-service: Cloud consumers can unilaterally provision computing capabilities such as server time and network storage automatically as needed without requiring human interaction with the service provider.

[0054] Widespread network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous, thin-client or thick-client platforms (eg, cell phones, laptops, and PDAs).

[0055] Resource Pooling: A provider's computing resources are pooled with different physical or virtual resources that are dynamically allocated and reallocated according to demand to serve multiple consumers using a multi-tenant model. Consumers generally have no control or knowledge over the exact location of the resources they are provided with, although there is a notion of location independence in that they may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0056] Rapid Elasticity: Capacity can be rapidly and elastically provisioned, sometimes automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capacity available to provision often appears unlimited and can be purchased at any time in any quantity.

[0057] Measured Service: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services used.

[0058] The service model is as follows:

[0059] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications (e.g., web-based email) are accessible from a variety of client devices through thin-client interfaces such as web browsers. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0060] Platform as a Service (PaaS): The ability provided to a consumer to deploy applications created or acquired by the consumer, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the configuration of the application's hosting environment.

[0061] Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision processing, storage, network, and other basic computing resources that the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does control the operating system, storage, deployed applications, and in some cases has limited control over the selection of network components (e.g., host firewalls).

[0062] The deployment model is as follows:

[0063] Private Cloud: Cloud infrastructure is operated exclusively for an organization. It may be managed by the organization or a third party and may exist on-premise or off-premise.

[0064] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with shared concerns (e.g., mission, security requirements, policy and compliance considerations). It may be managed by the organizations or a third party and may exist on-premises or off-premises.

[0065] Public Cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by an organization that sells cloud services.

[0066] Hybrid Cloud: A cloud infrastructure is a composite of two or more clouds (private, community, or public) that, while still being unique entities, are bound together by standard or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0067] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that comprises a network of interconnected nodes.

[0068] Referring now to FIG. 6 , an exemplary cloud computing environment 650 is illustrated. As shown, the cloud computing environment 650 includes one or more cloud computing nodes 610 that may communicate with local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or cellular phone 654A, a desktop computer 654B, a laptop computer 654C, or an automobile computer system 654N, or combinations thereof. The nodes 610 may communicate with each other. The nodes 610 may be physically or virtually grouped (not shown) into one or more networks, such as private, community, public, or hybrid clouds, or combinations thereof, as described herein above. This enables the cloud computing environment 650 to provide infrastructure, platform, or software as a service, or combinations thereof, without the cloud consumer having to maintain resources on their local computing devices. The types of computing devices 654A-N shown in FIG. 6 are intended to be illustrative only, and it is understood that computing node 610 and cloud computing environment 650 can communicate with any type of computerized device over any type of network or network-addressable connection or both (e.g., using a web browser).

[0069] Referring now to Figure 7, a set of functional abstraction layers provided by cloud computing environment 650 (Figure 6) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 7 are intended to be illustrative only, and embodiments of the invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0070] Hardware and software layer 760 includes hardware and software components. Examples of hardware components include mainframe 761, reduced instruction set computer (RISC) architecture-based server 762, server 763, blade server 764, storage device 765, and network and network components 766. In some embodiments, software components include network application server software 767 and database software 768.

[0071] The virtualization layer 770 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 771, virtual storage 772, virtual networks including virtual private networks 773, virtual applications and operating systems 774, and virtual clients 775.

[0072] In one example, management layer 780 may provide the following functions: Resource provisioning 781 provides dynamic procurement of computing resources and other resources used to perform tasks in the cloud computing environment. Metering and pricing 782 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 783 provides consumers and system administrators with access to the cloud computing environment. Service level management 784 provides cloud computing resource allocation and management so that required service levels are met. Service level agreement (SLA) planning and fulfillment 785 provides advance provisioning and procurement of cloud computing resources where future requirements are anticipated according to SLAs.

[0073] The workload layer 790 provides examples of functionality for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation 791, software development and lifecycle management 792, virtual classroom delivery 793, data analytics processing 794, transaction processing 795, and GC safepoint management 796.

[0074] The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail of integration. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0075] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves having instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over electrical wires.

[0076] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may comprise copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0077] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as SMALLTALK®, C++, and the like, and traditional procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0078] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0079] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to manufacture the machine. The instructions, when executed by the processor of the computer or other programmable data processing apparatus, thereby form means for implementing the functions / acts specifically specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner. The computer-readable storage medium having instructions stored thereon thereby comprises an article of manufacture containing instructions that implement aspects of the functions / acts specifically specified in one or more blocks of the flowcharts and / or block diagrams.

[0080] The computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other device to cause a sequence of operational steps to be executed on the computer, other programmable data processing apparatus, or other device, resulting in a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts particularly specified in one or more blocks of the flowcharts and / or block diagrams.

[0081] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or implements a combination of dedicated hardware and computer instructions.

[0082] References herein to "one embodiment" or "one embodiment" of the present invention, as well as other variations thereof, mean that the particular aspect, structure, characteristic, etc. described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment," as well as any other variations thereof, in various places throughout this specification do not necessarily all refer to the same embodiment.

[0083] It should be understood that the use of any of " / ", "and / or", "at least one of", for example, "A / B", "A and / or B", "at least one of A and B" is intended to encompass the selection of only the first listed alternative (A), or the selection of only the second listed alternative (B), or the selection of both alternatives (A and B). As a further example, in the cases of "A, B, or C or a combination thereof" and "at least one of A, B, and C", such delimitation is intended to encompass the selection of only the first listed alternative (A), or the selection of only the second listed alternative (B), or the selection of only the third listed alternative (C), or the selection of only the first listed alternative and the second listed alternative (A and B), or the selection of only the first listed alternative and the third listed alternative (A and C), or the selection of only the second listed alternative and the third listed alternative (B and C), or the selection of all three alternatives (A, B, and C). This may be extended for as many items as are listed, as would be readily apparent to one of ordinary skill in the art.

[0084] While preferred embodiments of the system and method have been described (intended to be illustrative only and not limiting), it should be noted that modifications and variations can be made by those skilled in the art given the above teachings. It is therefore to be understood that changes may be made within the specific embodiments disclosed which are within the scope of the invention and outlined by the appended claims. Having thus described aspects of the invention with particularity, and as particularly required by the patent laws, what is claimed and desired to be protected by Letters Patent is set forth in the appended claims. According to the present disclosure, the following items are also disclosed: (Item 1) 1. A computer-implemented method for managing garbage collection (GC) safe points, comprising: determining whether a GC safepoint for the target native method can be removed by checking the heap occupancy before executing the target native method; removing the GC safepoint in response to the heap occupancy being less than a threshold occupancy percentage before executing the target native method; determining whether the GC safepoint for the target native method can be removed by checking the most recent GC pause time; removing the GC safepoint in response to the most recent GC pause time being less than the execution time of the target native method by a threshold pause time amount percentage; 1. A computer-implemented method comprising: (Item 2) Item 10. The computer-implemented method of item 1, wherein the threshold occupancy percentage is modifiable via a virtual machine parameter at virtual machine startup. (Item 3) 3. The computer-implemented method of claim 1, wherein the threshold pause time amount percentage is modifiable via a virtual machine parameter at virtual machine startup. (Item 4) 4. The computer-implemented method of any one of items 1 to 3, further comprising setting the threshold occupancy percentage and the threshold pause time percentage via respective virtual machine parameters at virtual machine startup. (Item 5) 5. The computer-implemented method of any one of items 1 to 4, wherein the threshold occupancy percentage is set to 70 percent. (Item 6) 6. The computer-implemented method of any one of items 1 to 5, wherein the threshold pause time amount percentage is set to 10 percent. (Item 7) 7. The computer-implemented method of any one of claims 1 to 6, further comprising: recording, by a virtual machine, the elapsed time of the target native method when the target native method is first invoked; and repeating the computer-implemented method for subsequent invocations of the target native method. (Item 8) 8. The computer-implemented method of claim 1, further comprising restricting garbage collection from being performed in response to the heap occupancy being less than the threshold occupancy percentage before executing the target native method. (Item 9) 9. The computer-implemented method of any one of items 1 to 8, wherein determining whether the GC safepoint for the target native method can be removed by checking the most recent GC pause time is performed in response to the heap occupancy before executing the target native method either equaling or exceeding a threshold occupancy percentage. (Item 10) 1. A computer program for managing garbage collection (GC) safe points, the computer program comprising: determining whether a GC safepoint for the target native method can be removed by checking the heap occupancy before executing the target native method; removing the GC safepoint in response to the heap occupancy being less than a threshold occupancy percentage before executing the target native method; determining whether the GC safepoint for the target native method can be removed by checking the most recent GC pause time; removing the GC safepoint in response to the most recent GC pause time being less than the execution time of the target native method by a threshold pause time amount percentage; A computer program for causing a computer to carry out a method comprising: (Item 11) Item 11. The computer program of item 10, wherein the threshold occupancy percentage is modifiable via a virtual machine parameter at virtual machine startup. (Item 12) Item 12. The computer program of item 10 or 11, wherein the threshold pause time amount percentage is modifiable via a virtual machine parameter at virtual machine startup. (Item 13) 13. The computer program product of claim 10, wherein the method comprises setting the threshold occupancy percentage and the threshold pause time percentage via respective virtual machine parameters at virtual machine startup. (Item 14) 14. The computer program of any one of items 10 to 13, wherein the threshold occupancy percentage is set to 70 percent. (Item 15) 15. The computer program of any one of claims 10 to 14, wherein the threshold pause time amount percentage is set to 10 percent. (Item 16) 16. The computer program product of claim 10, wherein the method comprises recording, by a virtual machine, the elapsed time of the target native method the first time the target native method is called, and repeating the method for subsequent calls of the target native method. (Item 17) 17. The computer program product of claim 10, further comprising: limiting garbage collection to be performed in response to the heap occupancy being less than the threshold occupancy percentage before executing the target native method. (Item 18) 18. The computer program of claim 10, wherein determining whether the GC safepoint for the target native method can be removed by checking the most recent GC pause time is performed in response to the heap occupancy before executing the target native method being either equal to or exceeding a threshold occupancy percentage. (Item 19) 1. A computer processing system for managing garbage collection (GC) safe points, comprising: a memory device for storing program code; a processor device operatively coupled to the memory device for executing the program code to remove a GC safepoint in response to either (i) a heap occupancy percentage before executing a target native method being less than a threshold occupancy percentage, and (ii) a recent GC pause time being less than the execution time of the target native method by a threshold pause time amount percentage; and A computer processing system comprising: (Item 20) 20. The computer processing system of claim 19, wherein both the threshold occupancy percentage and the threshold pause time percentage are modifiable via respective virtual machine parameters at virtual machine startup.

Claims

1. 1. A computer-implemented method for managing garbage collection (GC) safe points, comprising: removing a GC safepoint in response to either (i) the heap occupancy before executing the target native method being less than a threshold occupancy percentage, and (ii) the most recent GC pause time being less than the execution time of the target native method by a threshold pause time amount percentage.

1. A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the threshold occupancy percentage is modifiable via a virtual machine parameter at virtual machine startup.

3. The computer-implemented method of claim 1 or 2, wherein the threshold pause time amount percentage is modifiable via a virtual machine parameter at virtual machine startup time.

4. The computer-implemented method of claim 1 , further comprising setting the threshold occupancy percentage and the threshold pause time percentage via respective virtual machine parameters at virtual machine startup.

5. The computer-implemented method of claim 1 , wherein the threshold occupancy percentage is set to 70 percent.

6. The computer-implemented method of claim 1 , wherein the threshold pause time amount percentage is set to 10 percent.

7. 7. The computer-implemented method of claim 1, further comprising: recording, by a virtual machine, the elapsed time of the target native method when the target native method is first invoked; and performing the step of removing the GC safepoint for subsequent invocations of the target native method.

8. 8. The computer-implemented method of claim 1, further comprising restricting garbage collection from being performed in response to the heap occupancy being less than the threshold occupancy percentage before executing the target native method.

9. A computer-implemented method as described in any one of claims 1 to 8, comprising a step of determining whether the GC safepoint for the target native method can be removed by checking the most recent GC pause time depending on whether the heap occupancy before executing the target native method is either equal to or exceeds a threshold occupancy percentage.

10. 1. A computer program for managing garbage collection (GC) safe points, the computer program comprising: removing a GC safepoint in response to either (i) the heap occupancy before executing the target native method being less than a threshold occupancy percentage, and (ii) the most recent GC pause time being less than the execution time of the target native method by a threshold pause time amount percentage. A computer program for causing a computer to carry out a method comprising:

11. The computer program product of claim 10 , wherein the threshold occupancy percentage is modifiable via a virtual machine parameter at virtual machine startup.

12. 12. The computer program product of claim 10 or 11, wherein the threshold pause time amount percentage is modifiable via a virtual machine parameter at virtual machine startup time.

13. 13. The computer program product of claim 10, wherein the method comprises setting the threshold occupancy percentage and the threshold pause time percentage via respective virtual machine parameters at virtual machine startup.

14. 14. The computer program of claim 10, wherein the threshold occupancy percentage is set to 70 percent.

15. 15. The computer program of claim 10, wherein the threshold pause time amount percentage is set to 10 percent.

16. 16. The computer program product of claim 10, wherein the method comprises recording, by a virtual machine, the elapsed time of the target native method when the target native method is first called, and removing the GC safepoint for subsequent calls of the target native method.

17. 17. The computer program product of claim 10, wherein the method comprises limiting garbage collection from being performed in response to the heap occupancy being less than the threshold occupancy percentage before execution of the target native method.

18. A computer program as described in any one of claims 10 to 17, wherein the method includes a step of determining whether the GC safepoint for the target native method can be removed by checking the most recent GC pause time depending on whether the heap occupancy before executing the target native method is either equal to or exceeds a threshold occupancy percentage.

19. 1. A computer processing system for managing garbage collection (GC) safe points, comprising: a memory device for storing program code; a processor device operatively coupled to the memory device for executing the program code to remove a GC safepoint in response to either (i) a heap occupancy percentage before executing a target native method being less than a threshold occupancy percentage, and (ii) a recent GC pause time being less than the execution time of the target native method by a threshold pause time amount percentage; and A computer processing system comprising:

20. 20. The computer processing system of claim 19, wherein both the threshold occupancy percentage and the threshold pause time percentage are modifiable via respective virtual machine parameters at virtual machine startup time.

Images