October 2014 - hotspot-gc-dev

[JDK 6u21]: does CMS report concurrent mode failure on perm gen expansion ?
by Charlie Hunt 05 Dec '18

05 Dec '18

I'm looking at a GC log and surprised by the "concurrent mode failure" messages. I'm seeing the following GC log entries as the first 8 GCs: 3.398: [Full GC 3.398: [CMS (concurrent mode failure)[YG occupancy: 594957 K (1887488 K)]3.489: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1308660 secs] 594957K->594957K(8178944K), [CMS Perm : 21247K->21247K(21248K)], 0.1310260 secs] [Times: user=0.13 sys=0.03, real=0.14 secs] 3.529: [Full GC 3.529: [CMS (concurrent mode failure)[YG occupancy: 594957 K (1887488 K)]3.617: [weak refs processing, 0.0000110 secs]: 0K->0K(6291456K), 0.1010290 secs] 594957K->594957K(8178944K), [CMS Perm : 21248K->21248K(42496K)], 0.1011530 secs] [Times: user=0.12 sys=0.00, real=0.10 secs] 3.638: [Full GC 3.638: [CMS (concurrent mode failure)[YG occupancy: 662071 K (1887488 K)]3.730: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1068710 secs] 662071K->662071K(8178944K), [CMS Perm : 21319K->21319K(42688K)], 0.1069610 secs] [Times: user=0.15 sys=0.00, real=0.11 secs] 3.772: [Full GC 3.772: [CMS (concurrent mode failure)[YG occupancy: 729184 K (1887488 K)]3.915: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.1582170 secs] 729184K->729184K(8178944K), [CMS Perm : 21499K->21499K(42880K)], 0.1583500 secs] [Times: user=0.20 sys=0.00, real=0.16 secs] 3.962: [Full GC 3.962: [CMS (concurrent mode failure)[YG occupancy: 804686 K (1887488 K)]4.107: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.1598050 secs] 804686K->804686K(8178944K), [CMS Perm : 21702K->21702K(43072K)], 0.1599420 secs] [Times: user=0.21 sys=0.00, real=0.16 secs] 4.497: [Full GC 4.497: [CMS (concurrent mode failure)[YG occupancy: 939150 K (1887488 K)]4.672: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.1895350 secs] 939150K->939150K(8178944K), [CMS Perm : 22202K->22202K(43408K)], 0.1896680 secs] [Times: user=0.23 sys=0.00, real=0.19 secs] 5.054: [Full GC 5.054: [CMS (concurrent mode failure)[YG occupancy: 992483 K (1887488 K)]5.274: [weak refs processing, 0.0000130 secs]: 0K->0K(6291456K), 0.2347170 secs] 992483K->992483K(8178944K), [CMS Perm : 24058K->24058K(44408K)], 0.2348700 secs] [Times: user=0.28 sys=0.00, real=0.23 secs] 6.662: [Full GC 6.662: [CMS (concurrent mode failure)[YG occupancy: 1292895 K (1887488 K)]6.953: [weak refs processing, 0.0000140 secs]: 0K->0K(6291456K), 0.3063690 secs] 1292895K->1292895K(8178944K), [CMS Perm : 30692K->30692K(48120K)], 0.3065860 secs] [Times: user=0.66 sys=0.01, real=0.30 secs] After these 8 GCs, the GC log is much inline with what I'd expect, i.e. ParNew GCs, initial-marks, remarks, etc. In each of the above GCs: - young gen is increasing in occupancy - old gen remains empty - perm gen space size is expanding I can understand the Full GC being reported since perm gen is expanding, but I don't understand the reporting of "concurrent mode failure". Am I missing something? Is it possible HotSpot is reporting concurrent mode failure when perm gen is expanding? Here's the set of command line options in use: -Xmx8G -Xms8G -Xmn1500m -XX:+UseCompressedOops -XX:-UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:MaxDirectMemorySize=5000m thanks, charlie ... PS: I didn't go look at / investigate OpenJDK HotSpot source code since this is JDK 6u21 and thought it might be possible something may have changed between 6u21 and what's in OpenJDK.

4 4

[RFR] 8016752: Test case for 8005857/8016740 (assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose)
by Andrey Zakharov 26 Nov '15

26 Nov '15

Hi, team. Here is simple test for JVM don't crash when its with PSOldGen, low memory and with -XX:+PrintGCDetails and -XX:+Verbose flags (https://bugs.openjdk.java.net/browse/JDK-8016740) based on Crasher attached to original incident bug webrev: http://cr.openjdk.java.net/~azakharov/8016752/webrev/ test bug: https://bugs.openjdk.java.net/browse/JDK-8016752 bug: https://bugs.openjdk.java.net/browse/JDK-8016740 https://bugs.openjdk.java.net/browse/JDK-8005857 Thanks.

4 14

RFR: 8057037: Verification in ClassLoaderData::is_alive is too slow
by Stefan Karlsson 08 Apr '15

08 Apr '15

Hi all, Please review this patch to remove some verification code that was added during the G1 Class Unloading project. The code was added to make sure we catch any class unloading bugs as early as possible. This verification code is run too often and is causing large GC times in our fastdebug test runs. In one of the tests I investigated, the Full GCs take 8 seconds with this verification and 0.2 seconds without it. Most of the verified pointers are already verified before and after GCs in ClassLoaderDataGraph::verify(). http://cr.openjdk.java.net/~stefank/8057037/webrev.00/ thanks, StefanK

5 6

Request for sponsor - JDK-8031538
by Staffan Friberg 03 Mar '15

03 Mar '15

Hi, I have created the a patch for JDK-8031538 - G1 eden usage is sometimes higher than target eden (printed Eden size) [1]. Since I'm not author I can't upload public WebRevs or request reviews, so I would like to ask if someone could sponsor this change and push it through the process. I have attached the small patch to this email. The patch make sure that the nursery target size calculation takes into account any regions that might currently be used for eden and not only the size of the survivor space. [1] - https://bugs.openjdk.java.net/browse/JDK-8031538 Cheers, Staffan Friberg

2 5

RFR: JDK-8061259: ParNew promotion failed is serialized on a lock
by Jungwoo Ha 16 Jan '15

16 Jan '15

Bug: https://bugs.openjdk.java.net/browse/JDK-8061259 hotspot code: http://cr.openjdk.java.net/~rasbold/8061259/webrev.00/ I created the patch for JDK9, but I can also observe this on JDK7 and 8. We are seeing several cases where GC worker threads are serialized on GCRareEvent_lock causing 2 digit seconds pause on moderate sized heap. I have a test code that can reproduce it and shows it is solved. import java.util.LinkedList; class PromoFail { static class Container { Container p; byte[] a; public Container(int size) { if (size > 0) { p = new Container(size / 2); } else { p = null; } a = new byte[size]; } } public static void main(String args[]) { if (args.length < 1) { System.err.println("@ 1st argument must be size in MB."); System.exit(1); } int size = 0; try { size = Integer.parseInt(args[0]) * 1024 * 1024; } catch (NumberFormatException e) { System.err.println("@ Cannot parse the size(=" + args[0] + ")"); System.exit(1); } // LinkedList will have more unbalanced workload. LinkedList<Container> list = new LinkedList<Container>(); // 1st iteration adds element without removal. // These are all live objects. for (int i = 0; i < size / 4; i++) { list.add(new Container(1)); } // Promote to the old gen. System.gc(); for (int containerSize = 2; container_size < 512; container_size *= 3) { for (int i = 0; i < size / 4; i++) { // Most likely removing an old object due to System.gc() from previous iteration. // This will cause fragmentation. list.remove(); list.add(new Container(containerSize)); } { System.gc(); Runtime runtime = Runtime.getRuntime(); System.out.println("@ Current Used: " + (runtime.totalMemory() - runtime.freeMemory()) / 1024 / 1024); } } } } You can run it with the following parameters. $ java -Xmx2g -Xms2g -Xmn1g -XX:+UseCMSFastPromotionFailure -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=6 PromoFail 4 Without UseCMSFastPromotionFailure #7: [GC (Allocation Failure) #7: [ParNew#6: [CMS-concurrent-abortable-preclean: 0.003/0.203 secs] [Times: user=0.20 sys=0.20 real=0.20 secs] (promotion failed): 838912K->943744K(943744K), 62.0419534 secs]#8: [CMS (concurrent mode failure): 1048441K->1048575K(1048576K), 1.7731336 secs] 1609551K->1170596K(1992320K), [Metaspace: 3547K->3547K(1056768K)], *63.8151607*secs] [Times: user=93.50 sys=22.12 real=63.82 secs] With UseCMSFastPromotionFailure #7: [GC (Allocation Failure) #7: [ParNew#6: [CMS-concurrent-abortable-preclean: 0.004/0.204 secs] [Times: user=0.30 sys=0.02 real=0.20 secs] (promotion failed): 838912K->943744K(943744K), 2.0949545 secs]#8: [CMS (concurrent mode failure): 1048363K->1048575K(1048576K), 1.7517250 secs] 1609551K->1170595K(1992320K), [Metaspace: 3546K->3546K(1056768K)], *3.8467384*secs] [Times: user=10.85 sys=1.04 real=3.85 secs] I also ran it on Dacapo benchmarks. Please see attached results. Those are subset of DaCapo that shows any promotion failed pause. You can see that some speed ups and no performance regressions.

4 38

Re: RFR: JDK-8055845 - Add trace event for promoted objects
by Erik Helin 02 Dec '14

02 Dec '14

(it seems like we lost hotspot-gc-dev(a)openjdk.java.net somewhere in this thread, I'm adding it back) On 2014-08-28 23:15, Staffan Friberg wrote: > Hi Erik, > > Thanks for the comments. >> - Aren't the events for promotion to the tenured generation (SerialOld) >> and the CMS generation missing? > The reason for leaving out these two, Serial completely and CMS > promotion, was due to that neither as far as I understand make use of > PLABs. I might be wrong here, but looking at the function TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks to me like SerialOld is using PLABs when ParNew is promoting objects from young to old. As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote (in concurrentMarkSweepGeneration.cpp) it seems like each CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local Allocation Buffer) that is a thread-local allocation buffer. See compactibleFreeListSpace.{hpp,cpp} for more details. Given this, I think we should add events for Serial and CMS as well. On 2014-08-28 23:15, Staffan Friberg wrote: > So without a good sampling type of event it would end up being an > event for each aging and/or promotion that happened in the GC. As this > would be a very large number of events so I decided not to support those > cases due to performance concerns. If you have a good idea on how to > support it please let me know. I would see CMS as the priority of the > two, client workloads can usually be analyzed with a different collector > which might not be the case for a latency sensitive application. > >> - We try to keep the trace dependency (the header file) in >> gcTraceSend.cpp, see the pattern for all the other events in >> gcTrace.cpp (they all have a "report" and a "send" function). > Will update it to follow that pattern. Thanks! On 2014-08-28 23:15, Staffan Friberg wrote: >> - Would it make sense to differentiate, either by separate events or by >> a field in a event, between promotions to to-space and to the old >> generation? >> - The are two events for TLAB allocations, >> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >> What do you think about using two events for PLAB allocations as well: >> - java/object_alloc_in_new_PLAB >> - java/object_alloc_outside_PLAB > I think this is a matter of taste and probably how similar we want the > event to be to the existing allocation event. I personally prefer a > single event but if the GC team and serviceability team feel it would be > better to have two I can certainly rewrite. The reason for me preferring > a single event is just ease of analysis, you can easily filter a list of > events on a field, it is harder to merge two different events with > different fields and work with them in an straight forward fashion. > > Any general preference for having a single or multiple events? I would prefer to have two events in this case and try to follow the existing allocation events as much as possible (both in naming and in style). Keeping the tenured field (I missed it the first time I read the patch) is good. On 2014-08-28 23:15, Staffan Friberg wrote: >> - In PSPromotionManager, instead of utilizing the C++ friendship with >> PSScavenge, should we add a getter function for the gc_tracer? > Created a getter function. Thanks! If you make report_promotion_sample const, then the getter can return a const ParallelScavengeTracer*, right? Thanks, Erik > Will upload a new webrev shortly. > > //Staffan > > On 08/28/2014 02:27 AM, Erik Helin wrote: >> Hi Staffan, >> >> thanks for the patch, looks like a useful event! >> >> A few initial comments: >> - Aren't the events for promotion to the tenured generation (SerialOld) >> and the CMS generation missing? >> - We try to keep the trace dependency (the header file) in >> gcTraceSend.cpp, see the pattern for all the other events in >> gcTrace.cpp (they all have a "report" and a "send" function). >> - Would it make sense to differentiate, either by separate events or by >> a field in a event, between promotions to to-space and to the old >> generation? >> - The are two events for TLAB allocations, >> java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB. >> What do you think about using two events for PLAB allocations as well: >> - java/object_alloc_in_new_PLAB >> - java/object_alloc_outside_PLAB >> - In PSPromotionManager, instead of utilizing the C++ friendship with >> PSScavenge, should we add a getter function for the gc_tracer? >> >> Thanks, >> Erik >> >> On 2014-08-27 16:28, Bengt Rutisson wrote: >>> >>> >>> Hi Staffan, >>> >>> Overall I think this change looks fine. I know that Erik Helin has some >>> thoughts on the naming of the events. I'll let him communicate those >>> thoughts. >>> >>> Apart from Erik's comments and the missing test case (that I know you >>> are working on) I think the change looks good. >>> >>> Thanks, >>> Bengt >>> >>> On 8/26/14 10:50 AM, Bengt Rutisson wrote: >>>> >>>> Hi all, >>>> >>>> Staffan sent me an updated webrev based on Erik's comments. I uploaded >>>> it here: >>>> http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/ >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> On 2014-08-25 19:32, Staffan Friberg wrote: >>>>> Hi Erik, >>>>> >>>>> No issue with naming the field class, since the event is similar to >>>>> the Allocation event I used that as a starting point and it also uses >>>>> class as name together with a couple of other events. >>>>> >>>>> Will go through the descriptions and remove periods. >>>>> >>>>> Object age is basically the how many times an object has been kept in >>>>> survivor region, it is incremented each time a YC happens and the >>>>> object is aged. >>>>> Will see how I can update the description to make it clearer. Calling >>>>> the field tenuringAge might help? >>>>> >>>>>> From the documentation, >>>>>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html >>>>>> >>>>>> -XX:MaxTenuringThreshold=/threshold/ >>>>>> >>>>>> Sets the maximum tenuring threshold for use in adaptive GC >>>>>> sizing. The largest value is 15. The default value is 15 for the >>>>>> parallel (throughput) collector, and 6 for the CMS collector. >>>>>> >>>>>> The following example shows how to set the maximum tenuring >>>>>> threshold to 10: >>>>>> >>>>>> -XX:MaxTenuringThreshold=10 >>>>>> >>>>>> >>>>>> -XX:+PrintTenuringDistribution >>>>>> >>>>>> Enables printing of tenuring age information. The following is >>>>>> an example of the output: >>>>>> >>>>>> Desired survivor size 48286924 bytes, new threshold 10 (max 10) >>>>>> - age 1: 28992024 bytes, 28992024 total >>>>>> - age 2: 1366864 bytes, 30358888 total >>>>>> - age 3: 1425912 bytes, 31784800 total >>>>>> ... >>>>>> >>>>>> Age 1 objects are the youngest survivors (they were created >>>>>> after the previous scavenge, survived the latest scavenge, and >>>>>> moved from eden to survivor space). Age 2 objects have survived >>>>>> two scavenges (during the second scavenge they were copied from >>>>>> one survivor space to the next). And so on. >>>>>> >>>>>> In the preceding example, 28 992 024 bytes survived one scavenge >>>>>> and were copied from eden to survivor space, 1 366 864 bytes are >>>>>> occupied by age 2 objects, etc. The third value in each row is >>>>>> the cumulative size of objects of age n or less. >>>>>> >>>>>> By default, this option is disabled. >>>>>> >>>>> >>>>> Thanks for the comments, >>>>> Staffan >>>>> >>>>> On 08/25/2014 09:55 AM, Erik Gahlin wrote: >>>>>> Did you manage to call the field "class"? It's a reserved word in >>>>>> C++, so we had to use "klass" in the past >>>>>> >>>>>> Descriptions with only one sentence shouldn't end with "." >>>>>> >>>>>> How is "Object Age" measured? >>>>>> >>>>>> As a user, I would expect the number to be in seconds/minutes/hours, >>>>>> but that is not the case. Perhaps an explanation in the description >>>>>> and/or a field name that better reflects what we really mean with >>>>>> age. >>>>>> >>>>>> Otherwise trace.xml looks good! >>>>>> >>>>>> Erik >>>>>> >>>>>> Staffan Friberg skrev 25/08/14 18:28: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please get reviews for this RFE that adds a trace event for >>>>>>> aging and promotion for young collections in G1, CMS and Parallel >>>>>>> GC. >>>>>>> It works similarly to allocation events, and generates the event on >>>>>>> the slow path when either a direct copy occurs or a new PLAB is >>>>>>> request. >>>>>>> >>>>>>> Since I'm adding an event I cc:ed the serviceability list in case >>>>>>> anyone has any comments on the event and changes to trace.xml. >>>>>>> >>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845 >>>>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00 >>>>>>> >>>>>>> Bengt has been kind and agreed to both sponsor and host the the >>>>>>> webrev. >>>>>>> >>>>>>> Thanks, >>>>>>> Staffan >>>>>>> >>>>>> >>>>> >>>> >>> >

5 17

RFR: 8059066: CardTableModRefBS might commit the same page twice
by Erik Helin 26 Nov '14

26 Nov '14

Hi all, this patch fixes an issue with overlapping commits in cardTableModRefBS. If the JVM is started with the options -Xmx8m -XX:-UseLargePages -version on a system with a smallest page size of 8kB, then cardTableModRefBS will commit the same page twice. Given how os::commit_memory works, the issue is benign: mmap will simply overwrite the page with zeroes again, and since this is during initialization, the card table is only filled with zeroes. However, the issue becomes annoying when running with -XX:NativeMemoryTracking=detail, since NMT will report the overlapping commit. The patch is a little tricky, since the surrounding code is a bit intertwined. I will try to explain the patch step-by-step, it is composed of two parts: 1. Update which committed regions we check when determining if `new_end_aligned` interferes with another region. 2. Update the criteria for checking if `new_end_aligned` interferes with another region. The patch for the first part is: --- a/src/share/vm/memory/cardTableModRefBS.cpp +++ b/src/share/vm/memory/cardTableModRefBS.cpp @@ -277,5 +277,5 @@ void CardTableModRefBS::resize_covered_r // space of another region. int ri = 0; - for (ri = 0; ri < _cur_covered_regions; ri++) { + for (ri = ind + 1; ri < _cur_covered_regions; ri++) { if (ri != ind) { if (_committed[ri].contains(new_end_aligned)) { We only need to check if `new_end_aligned` clashes with regions following `ind`, since the code a few lines above handles regions before `ind`: 265 HeapWord* const max_prev_end = largest_prev_committed_end(ind); 266 if (max_prev_end > cur_committed.end()) { 267 cur_committed.set_end(max_prev_end); 268 } We only commit more memory if `new_end_for_commit > cur_committed.end()` where `new_end_for_commit` is equal to new_end_for_aligned`. Hence, the case where a region before `ind` already have committed memory up to (or beyond) `new_end_aligned` is taken care of. Therefore, we only need to check regions after `ind`, which is the patch above. This is also confirmed by an existing comment and assert in the loop body: 285 // Any region containing the new end 286 // should start at or beyond the region found (ind) 287 // for the new end (committed regions are not expected to 288 // be proper subsets of other committed regions). 289 assert(_committed[ri].start() >= _committed[ind].start(), 290 "New end of committed region is inconsistent"); Since the committed regions should be sorted according their start address (see CardTableModRefBS::find_covering_region_by_base), the assert can only fail for regions where `ri < ind`. The second part of the patch then updates the criteria for determining if `new_end_aligned` interferes with a region after `ind`: --- a/src/share/vm/memory/cardTableModRefBS.cpp +++ b/src/share/vm/memory/cardTableModRefBS.cpp @@ -279,5 +279,6 @@ void CardTableModRefBS::resize_covered_r for (ri = ind + 1; ri < _cur_covered_regions; ri++) { if (ri != ind) { - if (_committed[ri].contains(new_end_aligned)) { + if (new_end_aligned > _committed[ri].start() && + new_end_aligned <= _committed[ri].end()) { // The prior check included in the assert // (new_end_aligned >= _committed[ri].start()) `_committed[ri].contains(new_end_aligned)` only checks: bool contains(const void* addr) const { return addr >= (void*)_start && addr < (void*)end(); } and therefore misses the case when `new_end_aligned` completely covers the region _committed[ri], that is, `new_end_aligned == _committed[ri].end()`. This is fixed by the above patch. Given the above two patches, the `if (ri != ind`)` check can be removed from the loop body and the loop body can therefore remove two spaces of indentation. I also removed an outdated comment. Webrev: http://cr.openjdk.java.net/~ehelin/8059066/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8059066 Testing: - JPRT - Ad-hoc (Window 32/64, Linux 32/64, OS X 64, Solaris x86-64/SPARC): - Dacapo, Kitchensink, Weblogic+medrec, runThese - nsk.regression, vm.gc, vm.oom, vm.parallel_class_loading, vm.regression, vm.runtime - nashorn regression tests - JTReg: - HotSpot - jdk_core, jdk_svc - Running -Xmx8m -XX:-UseLargePages -version on a machine with 8kB pages Thanks, Erik

4 12

[9] RFR (L): 8037968: Add tests on alignment of objects copied to survivor space
by Filipp Zhinkin 25 Nov '14

25 Nov '14

Hi all, please review tests on survivor alignment feature (JDK-8031323 [1]). Webrev: http://cr.openjdk.java.net/~fzhinkin/8037968/webrev.00/ Bug id: https://bugs.openjdk.java.net/browse/JDK-8037968 Testing: manual, automated Description: There are 6 new tests: one verifies SurvivorAlignmentInBytes option processing and other 5 tests verify that that option only affect alignment of objects copied to survivor space and that their alignment is equal to SurvivorAlignmentInBytes value. Since there are no guarantee that _all_ objects copied to survivor space will be alignedthese tests are verifying that objects occupy some expected amount of memory depending on alignment. All tests use following algorithm: - decide how many objects should be allocated - allocate objects - force minor or full GCs if needed - verify usage of particular heap space (eden, survivor or tenured). There are several differences between Hotspot garbage collectors that affect memory usage measurements: 1) precision of such measurements; 2) min amount of heap space that will be occupied by a single object. The first one is about the G1 GC, where usage of eden and survivor regions is reported as (number_of_used_regions * G1HeapRegionSize) [2]. Tests verify that actual memory usage is close to expected usage, i.e. difference between actual and expected usage hasto be lower or equal to 5% of expected usage. However, for G1 GC max allowed difference has to be aligned up to G1HeapRegionSize. The second one is about the CMS GC, where an objecthas to occupy at least MinChunkSize bytes [3][4]. And, of course, amount of memory occupied by an object depends on the alignment used in particular heap space: SurvivorAlignmentInBytes for survivor space and ObjectsAlignmentInBytes for other spaces. To take all such aspects into account tests use AlignmentHelper class, whose instances are created for each heap space. That class is aimed to answer following questions: - how much space will be occupied by an object whose size is M; - how many objects of size M should be allocated to occupy N bytes of memory in particular heap space; - how much space will be occupied by K objects whose size is M; - how close the actual memory usage has to be to the expected memory usage given the precision with which we can measure the memory usage. In order to avoid false failures caused by memory allocated by different threads (for example, some agent was attached to tested JVM and allocated objects during the test run) tests check that only the main test thread was allocating objects. Thanks, Filipp. [1] https://bugs.openjdk.java.net/browse/JDK-8031323 [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/5c722dffbc0f/src/share/vm… [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/5c722dffbc0f/src/share/vm… [4] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/5c722dffbc0f/src/share/vm…

3 6

RFR: 8059475: Test echeneis/vm/mm/gc/allgc_withfull/SoftReferenceTest#testSoftReference512To2kEvery4th fails
by Andrey Zakharov 19 Nov '14

19 Nov '14

Hello, team As part of subj. bug I've ported this test to jtreg. As this test is new for jtreg - copyrights sets to 2014. Test is pretty simple and old - it tests that when we OOM all soft references has been cleared Source remains almost same. Fixed final list iteration and invocation for jtreg. webrev: http://cr.openjdk.java.net/~fzhinkin/azakharov/8059661/webrev.00 bug: https://bugs.openjdk.java.net/browse/JDK-8059661

2 8

RFR: 8062537: [TESTBUG] Conflicting GC combinations in hotspot tests
by Evgeniya Stepanova 14 Nov '14

14 Nov '14

Hi, Please review changes for 8062537, the OpenJDK/hotspot part of the JDK-8019361 <https://bugs.openjdk.java.net/browse/JDK-8019361> bug: https://bugs.openjdk.java.net/browse/JDK-8062537 fix: http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/ Problem: Some tests explicitly set GC and fail when jtreg set another GC. Solution: Such tests marked with the jtreg tag "requires" to skip test if there is a conflict Tested locally with different GC flags (-XX:+UseG1GC, -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and without any GC flag). Tests are being excluded as expected. No tests failed because of the conflict. Thanks, Evgeniya Stepanova //

5 25