Method, computer program product, and computer processing system for selective injection of GC safepoints for JNI calls

Abstract

A computer-implemented method for managing garbage collection (GC) safepoints is provided. The method includes determining whether a GC safepoint for a target native method can be removed by examining a heap occupancy before execution of the target native method. The method also includes removing the GC safepoint in response to the heap occupancy before execution of the target native method being less than a threshold occupancy percentage. The method also includes determining whether the GC safepoint for the target native method can be removed by examining a most recent GC pause time. Furthermore, the method includes removing the GC safepoint in response to the most recent GC pause time being shorter than an execution time of the target native method by a threshold pause time percentage.

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 Art

[0002] When garbage collection (GC) is required, the mutator thread is suspended at a GC safe point and waits for the GC to end. The Java Virtual Machine (JVM) inserts GC safe points at appropriate locations in the Java code. There are GC safe points before and after calling native methods. In , the state of the mutator thread is changed before and after the GC safepoint. In order to correctly identify the state, a full memory fence is required at the safepoint. In GC, GC can be performed even when native methods are running. At high GC frequency, more GC safepoints are inserted, and the application runs faster.

[0003] However, when native methods are frequently executed, they are degraded by full memory barriers at GC safepoints. As a result, the overall performance of the application is also degraded. Summary of the Invention

[0004] According to aspects of the present invention, a computer-implemented method for managing garbage collection (GC) safepoints is provided. The method includes determining whether a GC safepoint for a target native method can be removed by examining the heap occupancy before executing the target native method. The method also 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 the GC safepoint for the target native method can be removed by examining the most recent GC pause time. Furthermore, the method includes removing the GC safepoint in response to the most recent GC pause time being shorter than the execution time of the target native method by a threshold pause time percentage.

[0005] According to other aspects of the present invention, a computer program product for managing garbage collection (GC) safety points is provided. The computer program product includes a non-transitory computer-readable storage medium having program instructions. The program instructions are executable by a computer to cause the computer to perform a method. The method includes: determining whether the GC safety point for the target native method can be removed by checking the heap occupancy before the execution of the target native method. The method also includes: removing the GC safety point in response to the heap occupancy before the execution of the target native method being less than a threshold occupancy percentage. The method also includes: determining whether the GC safety point for the target native method can be removed by checking the latest GC pause time. In addition, the method includes: removing the GC safety point in response to the latest GC pause time being shorter than the execution time of the target native method by a threshold pause time percentage.

[0006] According to another aspect of the present invention, a computer processing system for managing garbage collection (GC) safepoints is provided. The computer processing system includes a memory device for storing program code. The computer processing system also includes a processor device operably coupled to the memory device for executing the program code to remove a GC safepoint in response to either: (i) a heap occupancy before execution of a target native method is less than a threshold occupancy percentage, and (ii) a most recent GC pause time is shorter than the execution time of the target native method by a threshold pause time percentage.

[0007] These and other features and advantages will become apparent from the following detailed description of illustrative embodiments, which is to be read in connection with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The following description will provide details of the preferred embodiments with reference to the following drawings, in which:

[0009] Figure 1 is a block diagram illustrating an exemplary computing device according to an embodiment of the present invention;

[0010] Figure 2 An exemplary execution flow of a local method according to an embodiment of the present invention is shown;

[0011] Figure 3 is a flowchart illustrating an exemplary method for GC safepoint management according to an embodiment of the present invention;

[0012] Figure 4 is a diagram illustrating an exemplary scenario involving heap occupancy according to an embodiment of the present invention;

[0013] Figure 5 is a further illustration of an embodiment of the present invention Figure 4 Figure 1 shows an exemplary scenario of

[0014] Figure 6 is a block diagram showing an illustrative cloud computing environment having one or more cloud computing nodes with which local computing devices used by cloud consumers communicate, according to an embodiment of the present invention;

[0015] Figure 7 is a block diagram illustrating a set of functional abstraction layers provided by a cloud computing environment according to an embodiment of the present invention. DETAILED DESCRIPTION

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

[0017] In one or more embodiments involving applications that frequently run native methods, acceptable performance of the application is maintained even under high GC frequencies by selectively inserting safepoints for native methods.

[0018] In one or more embodiments, when GC frequency is low, unnecessary GC safepoints for native methods are removed. Fewer GC safepoints avoid full memory barriers that degrade the performance of native methods.

[0019] Figure 1 is a block diagram illustrating an exemplary computing device 100 according to an embodiment of the present invention. The computing device 100 is configured to perform GC safepoint management (eg, selectively injecting GC safepoints for JNI calls).

[0020] The computing device 100 may be embodied as any type of computing 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 device, a web device, a distributed computing system, a processor-based system, and / or a consumer electronic device. Additionally or alternatively, the computing device 100 may be embodied as one or more computing sleds, storage sleds, or other racks, sleds, computer cases, or other components of physically separate computing devices. Figure 1As shown, computing device 100 illustratively includes processor 110, input / output subsystem 120, memory 130, data storage device 140, and communication subsystem 150, and / or other components and devices commonly found in servers or similar computing devices. Of course, in other embodiments, computing device 100 may include other or additional components, such as those commonly found in server computers (e.g., different input / output devices). In addition, in some embodiments, one or more of the illustrated components may be incorporated into another component or otherwise form part of another component. For example, in some embodiments, memory 130 or portions thereof may be incorporated into processor 110.

[0021] The processor 110 may be embodied as any type of processor capable of performing the functions described herein. The processor 110 may be embodied as a single processor, multiple processors, central processing unit(s) (CPUs), graphics processing unit(s) (GPUs), single-core or multi-core processor(s), digital signal processor(s), microcontroller(s), or other processor(s) or processing / control circuit(s).

[0022] Memory 130 may be embodied as any type of volatile or non-volatile memory or data storage device capable of performing the functions described herein. In operation, memory 130 may store various data and software used during 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, which may be embodied as circuits and / or components that facilitate input / output operations with processor 110, memory 130, and other components of computing device 100. For example, I / O subsystem 120 may be embodied as or otherwise include a memory controller hub, an input / output control hub, a platform controller hub, integrated control circuitry, firmware devices, communication links (e.g., point-to-point links, bus links, wires, cables, optical guides, printed circuit board traces, etc.), and / or other components and subsystems that facilitate input / output operations. In some embodiments, I / O subsystem 120 may form part of a system on a chip (SOC) and may be incorporated onto a single integrated circuit chip along with processor 110 , memory 130 , and other components of computing device 100 .

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

[0024] 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, and / or other peripheral devices. For example, in some embodiments, peripheral devices 160 may include a display, a touch screen, 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.

[0025] Of course, the computing device 100 may also include other elements (not shown) as will be readily apparent to one skilled in the art, as well as omit certain elements. For example, various other input devices and / or output devices may be included in the computing device 100, depending on the specific implementation of the computing device 100, as will be readily apparent to one skilled in the art. For example, various types of wireless and / or wired input and / or output devices may be used. In addition, additional processors, controllers, memories, etc. in various configurations may also be utilized. Further, in another embodiment, a cloud configuration (e.g., see Figure 6-Figure 7 These and other variations of processing system 100 will be readily apparent to those of ordinary skill in the art given the teachings of the present invention provided herein.

[0026] As used herein, the term "hardware processor subsystem" or "hardware processor" may refer to a processor, memory (including RAM, cache(s), 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, and / or a separate processor- or computing element-based controller (e.g., logic gates, etc.). The hardware processor subsystem may include one or more on-board memories (e.g., caches, dedicated memory arrays, read-only memories, etc.). In some embodiments, the hardware processor subsystem may include one or more memories that may be on-board or off-board or may be dedicated for use by the hardware processor subsystem (e.g., ROM, RAM, basic input / output system (BIOS), etc.).

[0027] In some embodiments, the hardware processor subsystem may include and execute one or more software components. The one or more software components may include an operating system and / or one or more application programs and / or specific code to achieve a specified result.

[0028] 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, and / or PLAs.

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

[0030] Figure 2 An exemplary execution flow 200 of a local method according to an embodiment of the present invention is shown.

[0031] It should be understood that there are two load barrier steps (2 and 7) involving full memory barriers and corresponding GC safepoints (at steps 3 and 8).The present invention can be applied to the execution flow 200 to selectively remove GC safepoints.

[0032] Figure 3 is a flow chart illustrating an exemplary method 300 for GC safepoint management according to one embodiment of the present invention.

[0033] At block 310, upon virtual machine startup, a threshold occupancy percentage and a threshold pause time percentage are set / modified via the first virtual machine parameter and the second virtual machine parameter, respectively. In an 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 will be readily understood by those skilled in the art, given the teachings of the present invention provided herein.

[0034] For both parameters, higher values ​​increase the chances of optimizations (= removing GC safepoints), but the risk of drawbacks from applying the optimizations can become greater. Users should find the optimal balance, depending on their workload, by moving towards higher values. The first parameter relates to heap occupancy, where 70% (or somewhere in the 60-80% range) is considered a good starting point for most workloads in practice, as there's still 30% empty space in the heap. Perhaps 50% isn't that challenging to try to achieve gains using optimizations. In contrast, 90% is too aggressive, and it's highly likely that regressions will be observed by applying optimizations too frequently. Regarding the second parameter, the default value (10%) is set much lower than the first (70%) because the second parameter compares different properties of elapsed time. One is GC pause time, which can typically be time-consuming, such as tens to hundreds of milliseconds. In contrast, the other is the execution time of the target native method, which is typically fast. Therefore, 10% seems to be a good starting point to capture sufficient opportunities. Again, other percentages can be used while maintaining the spirit of the invention.

[0035] At block 320 , the elapsed time of the target native method is recorded by the virtual machine when the target native method is initially called.

[0036] At block 330 , for subsequent calls of the target native method, it is determined whether the GC safepoint for the target native method can be removed by examining the heap occupancy before executing the target native method.

[0037] In response to the heap occupancy before executing the target native method being less than the threshold occupancy percentage, the GC safe point is removed at block 340. The GC safe point is removed in this case because it is estimated that GC will not occur under these conditions.

[0038] At block 350 , when the heap occupancy is equal to or greater than the threshold occupancy percentage, for subsequent calls of the target native method, it is determined whether the GC safepoint for the target native method can be removed by checking the latest GC pause time.

[0039] In response to the most recent GC pause time being shorter than the target native method's execution time by a threshold pause time amount percentage, the GC safe point is removed at block 360. The GC safe point is removed in this case because it is estimated that GC will not occur under these conditions.

[0040] Figure 4 is a diagram illustrating an exemplary scenario 400 involving heap occupancy, according to an embodiment of the present invention.

[0041] Scenario 400 involves four threads th1 to th4, each with a safepoint sp. Enabled safepoints are shown as filled, while disabled safepoints are hollow.

[0042] In scene 400, th4 is executing a native method.

[0043] If the heap occupancy is less than the threshold, th4 disables the 410 safepoint.

[0044] The elapsed time of this native method is less than a threshold determined using GC pause times.

[0045] Figure 5 is a further illustration of an embodiment of the present invention Figure 4 FIG. 4 is a diagram of an exemplary scenario 400 .

[0046] In scenario 400, each thread (th1 to th4) is suspended at each safe point sp due to a request from the GC. Here, the GC requires a stop-the-world.

[0047] In this scenario, as described above, th4 is executing a native method.

[0048] th4 keeps that safepoint available when the heap occupancy reaches a threshold or the elapsed time of a native method is greater than a threshold determined using GC pause times.

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

[0050] 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, VMs, and services) that can be quickly provisioned and released with minimal management cost or interaction with the service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0051] Features are as follows:

[0052] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capacity (such as server time and network storage) on demand without manual interaction with the service provider.

[0053] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0054] Resource pooling: A provider's computing resources are grouped into resource pools to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Generally, consumers do not control or know the exact location of the provided resources, but can specify a location at a higher level of abstraction (e.g., country, state, or data center), thus providing location independence.

[0055] Rapid elasticity: Capacity can be rapidly and elastically (in some cases automatically) provisioned to quickly scale out and quickly released to quickly scale in. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased at any time in any quantity.

[0056] Measurable services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the provider and consumer of the utilized service.

[0057] The service model is as follows:

[0058] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications are accessible from a variety of client devices through a thin client interface such as a web browser (e.g., web-based email). Aside from limited user-specific application configuration settings, consumers neither manage nor control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities.

[0059] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications they create or acquire on cloud infrastructure. These applications are created using programming languages ​​and tools supported by the provider. Consumers neither manage nor control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they do have control over the applications they deploy and may also have control over the configuration of the application hosting environment.

[0060] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which they can deploy and run arbitrary software, including operating systems and applications. Consumers neither manage nor control the underlying cloud infrastructure, but do have control over the operating system, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls).

[0061] The deployment model is as follows:

[0062] Private cloud: Cloud infrastructure is run solely for an organization. It can be managed by that organization or a third party and can exist inside or outside the organization.

[0063] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist inside or outside the organization.

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

[0065] Hybrid cloud: A cloud infrastructure consisting of two or more clouds (private, community, or public) that remain distinct entities but are bound together by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0066] Cloud computing environments are service-oriented, with characteristics centered on statelessness, low coupling, modularity, and semantic interoperability. The core of computing is the infrastructure consisting of a network of interconnected nodes.

[0067] Now refer to Figure 6 , depicts an illustrative cloud computing environment 650. As shown, the cloud computing environment 650 includes one or more cloud computing nodes 610 with which a local computing device used by a cloud consumer can communicate, such as a personal digital assistant (PDA) or cellular phone 654A, a desktop computer 654B, a laptop computer 654C, and / or an automobile computer system 654N. The nodes 610 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks (such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above). This allows the cloud computing environment 650 to provide infrastructure as a service, platform as a service, and / or software as a service without the cloud consumer having to maintain resources for them on a local computing device. It should be understood that Figure 6The various types of computing devices 654A-N shown in the figure are merely illustrative, and the computing nodes 610 and cloud computing environment 650 can communicate with any type of computing device over any type of network and / or network addressable connection (e.g., using a web browser).

[0068] Now refer to Figure 7 , showing the cloud computing environment 650 ( Figure 6 ) provides a set of functional abstraction layers. First of all, it should be understood that Figure 7 The components, layers, and functions shown are merely illustrative, and embodiments of the present invention are not limited thereto. As shown in the figure, the following layers and corresponding functions are provided:

[0069] The hardware and software layer 760 includes hardware and software components. Examples of hardware components include: mainframes 761; servers based on RISC (Reduced Instruction Set Computer) architecture 762; servers 763; blade servers 764; storage devices 765; and networks and network components 766. In some embodiments, software components include network application server software 767 and database software 768.

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

[0071] In one example, the management layer 780 may provide the functionality described below. Resource provisioning functionality 781 provides dynamic acquisition of computing resources and other resources for performing tasks in a cloud computing environment. Metering and pricing functionality 782 provides cost tracking of resources used within the cloud computing environment and provides bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security functionality provides identity authentication for cloud consumers and tasks and provides protection for data and other resources. User portal functionality 783 provides access to the cloud computing environment for consumers and system administrators. Service level management functionality 784 provides allocation and management of cloud computing resources to meet required service levels. Service level agreement (SLA) planning and fulfillment functionality 785 provides pre-scheduling and procurement of cloud computing resources based on SLAs for which future demand is forecasted.

[0072] The workload layer 790 provides examples of functionality that can utilize a cloud computing environment. Examples of workloads and functionality that can be provided in this layer include: mapping and navigation 791; software development and lifecycle management 792; virtual classroom instructional delivery 793; data analysis processing 794; transaction processing 795; and GC safepoint management 796.

[0073] The present invention may be a system, method and / or computer program product at any possible level of technical detail integration. The computer program product may include (one or more) computer-readable storage media having computer-readable program instructions thereon, the computer-readable program instructions being used to cause a processor to perform various aspects of the present invention.

[0074] Computer readable storage medium can be a tangible device that can hold and store the instructions used by the instruction execution device.Computer readable storage medium can be, for example, but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the aforementioned storage devices.A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device such as a punch card or a raised structure in a groove having instructions recorded thereon, and any suitable combination of the above-mentioned devices.Computer readable storage medium as used herein should not be interpreted as being a temporary signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (for example, light pulses by optical fiber cables), or electrical signals transmitted by wires.

[0075] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The 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 to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0076] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of integrated circuits, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages, such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as " C " programming language or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or executed completely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (such as, using an internet service provider through the internet). In certain embodiments, the electronic circuit comprising, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can perform the computer-readable program instructions to personalize the electronic circuit by utilizing the state information of the computer-readable program instructions, so as to perform various aspects of the present invention.

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

[0078] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct the computer, programmable data processing device, and / or other equipment to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0079] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps will be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0080] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each frame in the flow chart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing the specified logical function. In some alternative embodiments, the function noted in the frame may not occur in the order noted in the figure. For example, the two frames shown in succession can actually be performed substantially simultaneously, or these frames can sometimes be performed in reverse order, depending on the function involved. It will also be noted that the combination of each frame of the block diagram and / or flow chart illustration and the frame in the block diagram and / or flow chart illustration can be realized by a dedicated hardware-based system that performs a specified function or action or performs a combination of special-purpose hardware and computer instructions.

[0081] Reference in the specification to "one embodiment" or "an embodiment" of the present invention and other variations thereof means that a particular feature, 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" and any other variations thereof in various places throughout this specification are not necessarily all referring to the same embodiment.

[0082] It should be understood that the use of any of " / ," "and / or," and "at least one of," for example, in the context of "A / B," "A and / or B," and "at least one of A and B," is intended to encompass selecting only the first listed option (A), or only the second listed option (B), or both options (A and B). As another example, in the context of "A, B, and / or C" and "at least one of A, B, and C," such wording is intended to encompass selecting only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first and second listed options (A and B), or only the first and third listed options (A and C), or only the second and third listed options (B and C), or all three options (A, B, and C). This can be expanded for many of the items listed, as will be readily apparent to one of ordinary skill in this and related arts.

[0083] Having described preferred embodiments of the systems and methods (which are intended to be illustrative and not restrictive), it should be noted that modifications and variations can be made by those skilled in the art in light of the above teachings. Therefore, it should be understood that changes can be made in the specific embodiments disclosed within the scope of the invention as outlined by the appended claims. Having thus described various aspects of the present invention with the details and particularity required by the patent laws, what is claimed and desired protected is set forth in the appended claims.

Claims

1. A computer-implemented method for managing garbage collection (GC) safepoints in a virtual machine, comprising: determining whether GC safepoints for a target native method can be disabled by examining a heap occupancy before executing the target native method; disabling the GC safepoint in response to the heap occupancy before executing the target native method being less than a threshold occupancy percentage; determining whether the GC safepoint for the target native method can be disabled by checking a latest GC pause time; as well as In response to the most recent GC pause time being shorter than the execution time of the target native method by a threshold pause time amount percentage, disabling the GC safepoint.

2. The computer-implemented method of claim 1 , wherein: The threshold occupancy percentage is modifiable via virtual machine parameters when the virtual machine is started.

3. The computer-implemented method of claim 1 , wherein: The threshold pause time percentage is modifiable via a virtual machine parameter when the virtual machine is started.

4. The computer-implemented method of claim 1 , further comprising: When the virtual machine is started, the threshold occupancy amount and the threshold pause time amount are set via corresponding virtual machine parameters.

5. The computer-implemented method of claim 1 , wherein: The threshold occupancy is set to seventy percent.

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

7. The computer-implemented method of claim 1 , further comprising: When the target native method is initially called, the virtual machine records the elapsed time of the target native method, and for subsequent calls to the target native method, the method is repeated.

8. The computer-implemented method of claim 1 , further comprising: Responsive to the heap occupancy prior to execution of the target native method being less than the threshold occupancy percentage, restricted garbage collection is performed.

9. The computer-implemented method of claim 1 , wherein: In response to the heap occupancy before executing the target native method being equal to or greater than a threshold occupancy percentage, determining whether the GC safepoint for the target native method can be disabled by checking the latest GC pause time is performed.

10. A computer program product for managing garbage collection (GC) safe points in a virtual machine, the computer program product comprising program instructions, wherein the program instructions are executable by a computer to enable the computer to perform the method according to any one of claims 1 to 9.

11. A computer processing system for managing garbage collection (GC) safe points in a virtual machine, comprising: a memory device for storing program code; as well as A processor device operatively coupled to the memory device for executing the program code to disable GC safepoints in response to either: (i) a heap occupancy prior to execution of a target native method is less than a threshold occupancy percentage; and (ii) a most recent GC pause time is shorter than an execution time of the target native method by a threshold pause time percentage.

12. The computer processing system of claim 11, wherein: Any one of the threshold occupancy percentage and the threshold pause time percentage is modifiable via corresponding virtual machine parameters when the virtual machine is started.

Images