2

I try to use G1GC with my program. Program is used on various machines with various memory size: VPS with 1Gb memory (minimum), desktop with 8Gb memory, DS with 32Gb memory (maximum). I noticed that G1GC not reserve more memory even if there is a lot of free memory (for example, G1GC not reserve more than 3Gb on my machine with 8Gb total / 4Gb free)

P.S. I want to have universal solution. I cannot create separate version or separate run script for each type of machine.

Xupypr MV
  • 935
  • 10
  • 18
  • What is the reasoning behind wanting to reserve more memory (assuming you want a larger heap)? The reason G1 has smaller heaps is because it typically collects garbage faster (as in, a collection happens quicker and garbage is recognized faster) than the parallel collector. – Jire Mar 06 '16 at 08:33
  • @Jire All reserved memory is already used and cannot be collected by GC. G1GC tries to collect garbage instead of reserve more memory. So, my app do GC instead of real work. – Xupypr MV Mar 06 '16 at 08:38
  • Perhaps G1GC isn't the right choice for your application. Have you considered trying to reduce garbage creation in hotspots of your application, if possible? – Jire Mar 06 '16 at 08:40
  • @Jire Yes looks like G1GC is not good choice for my application (I have better performance with SerialGC and additional in-app memory check). In current case: all reserved memory is used to store permanent objects. And I want to store more permanent objects. – Xupypr MV Mar 06 '16 at 08:47
  • @Xupypr MV : Can you post your G1GC parameters. I got good results with G1GC by fine tuning relevant parameters. Have a look at : http://stackoverflow.com/questions/8111310/java-7-jdk-7-garbage-collection-and-documentation/34254605#34254605 – Ravindra babu Mar 06 '16 at 13:41
  • @Ravindrababu No other keys except -XX:+UseG1GC . As `Stephen C` mentioned in his answer, G1 is not a good GC for my case. I will return back to SerialGC. It has acceptable characteristics for my program. – Xupypr MV Mar 06 '16 at 13:47

1 Answers1

3

I think you have chosen the wrong garbage collection algorithm. The Java 8 documentation offers this guidance:

Selecting a Collector

Unless your application has rather strict pause time requirements, first run your application and allow the VM to select a collector. If necessary, adjust the heap size to improve performance. If the performance still does not meet your goals, then use the following guidelines as a starting point for selecting a collector.

  • If the application has a small data set (up to approximately 100 MB), then select the serial collector with the option -XX:+UseSerialGC.

  • If the application will be run on a single processor and there are no pause time requirements, then let the VM select the collector, or select the serial collector with the option -XX:+UseSerialGC.

  • If (a) peak application performance is the first priority and (b) there are no pause time requirements or pauses of 1 second or longer are acceptable, then let the VM select the collector, or select the parallel collector with -XX:+UseParallelGC.

  • If response time is more important than overall throughput and garbage collection pauses must be kept shorter than approximately 1 second, then select the concurrent collector with -XX:+UseConcMarkSweepGC or -XX:+UseG1GC.

Source: Selecting a Collector

Based on your comments, it seems that your goal is to get peak performance; i.e. minimize the overall time spent on GC and related overheads.

That means that your best options are:

  • Set some performance goals and let the JVM to decide which collector is best. See the Behavior-based Tuning material for details of the performance goals mechanisms.
  • Select the Serial GC if you have only one core.
  • Select the Parallel GC if you have more than one core.

If you want a one-size-fits all script that works irrespective of your hardware, the performance goal approach is best, though that means you won't be able to use platform-specific settings to (potentially) improve on the JVM's decisions.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • So, there is no ability to G1GC to use all available memory without setting `-Xmx` key. Am I right? – Xupypr MV Mar 07 '16 at 08:46
  • If you don't specify a `-Xmx` **option** (it isn't a "key"), then the JVM uses a default heap size that won't be all available memory. Read the Java manual entry for your platform to find out how the default is calculatesg – Stephen C Mar 07 '16 at 12:59