May 2020 - hotspot-gc-dev

Work-in-progress: 8236485: Epoch synchronization protocol for G1 concurrent refinement
by Man Cao 19 Apr '21

19 Apr '21

Hi all, I have written up a description and challenges for implementing an epoch synchronization protocol. This protocol is necessary for removing the StoreLoad fence in G1's post-write barrier (JDK-8226731) Description: https://bugs.openjdk.java.net/browse/JDK-8236485 Work-in-progress webrev: https://cr.openjdk.java.net/~manc/8236485/webrev_wip0/ There are two main challenges that I'm not sure how to resolve: - Triggering a thread-local handshake is a blocking operation that can pass a safepoint. - There are native post-write barriers executed by threads in native/VM state. Discussions and suggestions are highly appreciated! -Man

4 7

RFR: 8188055: (ref) Add Reference.refersTo predicate
by Kim Barrett 02 Sep '20

02 Sep '20

[Note review on both core-libs and hotspot-gc-dev lists; try not to lose either when replying.] Please review a new function: java.lang.ref.Reference.refersTo. This function is needed to test the referent of a Reference object without artificially extending the lifetime of the referent object, as may happen when calling Reference.get. Some garbage collectors require extending the lifetime of a weak referent when accessed, in order to maintain collector invariants. Lifetime extension may occur with any collector when the Reference is a SoftReference, as calling get indicates recent access. This new function also allows testing the referent of a PhantomReference, which can't be accessed by calling get. The new function uses a native method whose implementation is in the VM so it can use the Access API. It is the intent that this function will be intrinsified by optimizing compilers like C2 or graal, but that hasn't been implemented yet. Bear that in mind before rushing off to change existing uses of Reference.get. CR: https://bugs.openjdk.java.net/browse/JDK-8188055 https://bugs.openjdk.java.net/browse/JDK-8241029 (CSR) Webrev: https://cr.openjdk.java.net/~kbarrett/8188055/open.04/ Testing: mach5 tier1 Locally (linux-x64) verified the new test passes with various garbage collectors.

8 18

RE: RFR(L): 8215624: add parallel heap inspection support for jmap histo(G1)(Internet mail)
by Hohensee, Paul 30 Jun '20

30 Jun '20

For the interface, I'd use "parallel" instead of "parallelThreadNum". All the other options are lower case, and it's a lot easier to type "parallel". I took the liberty of updating the CSR. If you're ok with it, you might want to change variable names and such, plus of course JMap.usage. Thanks, Paul On 4/22/20, 2:29 AM, "serviceability-dev on behalf of linzang(臧琳)" <serviceability-dev-bounces(a)openjdk.java.net on behalf of linzang(a)tencent.com> wrote: Dear Stefan, Thanks a lot! I agree with you to decouple the heap inspection code with GC's. I will start from your POC code, may discuss with you later. BRs, Lin On 2020/4/22, 5:14 PM, "Stefan Karlsson" <stefan.karlsson(a)oracle.com> wrote: Hi Lin, I took a look at this earlier and saw that the heap inspection code is strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer if we'd abstract this away, so that the GCs only provide a "parallel object iteration" interface, and the heap inspection code is kept elsewhere. I started experimenting with doing that, but other higher-priority (to me) tasks have had to take precedence. I've uploaded my work-in-progress / proof-of-concept: https://cr.openjdk.java.net/~stefank/8215624/webrev.01.delta/ https://cr.openjdk.java.net/~stefank/8215624/webrev.01/ The current code doesn't handle the lifecycle (deletion) of the ParallelObjectIterators. There's also code left unimplemented in around CollectedHeap::run_task. However, I think this could work as a basis to pull out the heap inspection code out of the GCs. Thanks, StefanK On 2020-04-22 02:21, linzang(臧琳) wrote: > Dear all, > May I ask you help to review? This RFR has been there for quite a while. > Thanks! > > BRs, > Lin > > > On 2020/3/16, 5:18 PM, "linzang(臧琳)" <linzang(a)tencent.com> wrote:> > >> Just update a new path, my preliminary measure show about 3.5x speedup of jmap histo on a nearly full 4GB G1 heap (8-core platform with parallel thread number set to 4). >> webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> BRs, >> Lin >> > On 2020/3/2, 9:56 PM, "linzang(臧琳)" <linzang(a)tencent.com> wrote: >> > >> > Dear all, >> > Let me try to ease the reviewing work by some explanation :P >> > The patch's target is to speed up jmap -histo for heap iteration, from my experience it is necessary for large heap investigation. E.g in bigData scenario I have tried to conduct jmap -histo against 180GB heap, it does take quite a while. >> > And if my understanding is corrent, even the jmap -histo without "live" option does heap inspection with heap lock acquired. so it is very likely to block mutator thread in allocation-sensitive scenario. I would say the faster the heap inspection does, the shorter the mutator be blocked. This is parallel iteration for jmap is necessary. >> > I think the parallel heap inspection should be applied to all kind of heap. However, consider the heap layout are different for GCs, much time is required to understand all kinds of the heap layout to make the whole change. IMO, It is not wise to have a huge patch for the whole solution at once, and it is even harder to review it. So I plan to implement it incrementally, the first patch (this one) is going to confirm the implemention detail of how jmap accept the new option, passes it to attachListener of the jvm process and then how to make the parallel inspection closure be generic enough to make it easy to extend to different heap layout. And also how to implement the heap inspection in specific gc's heap. This patch use G1's heap as the begining. >> > This patch actually do several things: >> > 1. Add an option "parallelThreadNum=<N>" to jmap -histo, the default behavior is to set N to 0, means let's JVM decide how many threads to use for heap inspection. Set this option to 1 will disable parallel heap inspection. (more details in CSR: https://bugs.openjdk.java.net/browse/JDK-8239290) >> > 2. Make a change in how Jmap passing arguments, changes in http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/src/jdk.jc…, originally it pass options as separate arguments to attachListener, this patch change to that all options be compose to a single string. So the arg_count_max in attachListener.hpp do not need to be changed, and hence avoid the compatibility issue, as disscussed at https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/02733… >> > 3. Add an abstract class ParHeapInspectTask in heapInspection.hpp / heapInspection.cpp, It's work(uint worker_id) method prepares the data structure (KlassInfoTable) need for every parallel worker thread, and then call do_object_iterate_parallel() which is heap specific implementation. I also added some machenism in KlassInfoTable to support parallel iteration, such as merge(). >> > 4. In specific heap (G1 in this patch), create a subclass of ParHeapInspectTask, implement the do_object_iterate_parallel() for parallel heap inspection. For G1, it simply invoke g1CollectedHeap's object_iterate_parallel(). >> > 5. Add related test. >> > 6. it may be easy to extend this patch for other kinds of heap by creating subclass of ParHeapInspectTask and implement the do_object_iterate_parallel(). >> > >> > Hope these info could help on code review and initate the discussion :-) >> > Thanks! >> > >> > BRs, >> > Lin >> > >On 2020/2/19, 9:40 AM, "linzang(臧琳)" <linzang(a)tencent.com> wrote:. >> > > >> > > Re-post this RFR with correct enhancement number to make it trackable. >> > > please ignore the previous wrong post. sorry for troubles. >> > > >> > > webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_01/ >> > > Hi bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > -------------- >> > > Lin >> > > >Hi Lin, > > > > > >> > > >Could you, please, re-post your RFR with the right enhancement number in >> > > >the message subject? >> > > >It will be more trackable this way. >> > > > >> > > >Thanks, >> > > >Serguei >> > > > >> > > > >> > > >On 2/17/20 10:29 PM, linzang(臧琳) wrote: >> > > >> Dear David, >> > > >> Thanks a lot! >> > > >> I have updated the refined code to http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_01/. >> > > >> IMHO the parallel heap inspection can be extended to all kinds of heap as long as the heap layout can support parallel iteration. >> > > >> Maybe we can firstly use this webrev to discuss how to implement it, because I am not sure my current implementation is an appropriate way to communicate with collectedHeap, then we can extend the solution to other kinds of heap. >> > > >> >> > > >> Thanks, >> > > >> -------------- >> > > >> Lin >> > > >>> Hi Lin, >> > > >>> >> > > >>> Adding in hotspot-gc-dev as they need to see how this interacts with GC >> > > >>> worker threads, and whether it needs to be extended beyond G1. >> > > >>> >> > > >>> I happened to spot one nit when browsing: >> > > >>> >> > > >>> src/hotspot/share/gc/shared/collectedHeap.hpp >> > > >>> >> > > >>> + virtual bool run_par_heap_inspect_task(KlassInfoTable* cit, >> > > >>> + BoolObjectClosure* filter, >> > > >>> + size_t* missed_count, >> > > >>> + size_t thread_num) { >> > > >>> + return NULL; >> > > >>> >> > > >>> s/NULL/false/ >> > > >>> >> > > >>> Cheers, >> > > >>> David > > > > >>> >> > > >>> On 18/02/2020 2:15 pm, linzang(臧琳) wrote: >> > > >>>> Dear All, >> > > >>>> May I ask your help to review the follow changes: >> > > >>>> webrev: >> > > >>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215264/webrev_00/ >> > > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8215624 >> > > >>>> related CSR: https://bugs.openjdk.java.net/browse/JDK-8239290 >> > > >>>> This patch enable parallel heap inspection of G1 for jmap histo. >> > > >>>> my simple test shown it can speed up 2x of jmap -histo with >> > > >>>> parallelThreadNum set to 2 for heap at ~500M on 4-core platform. >> > > >>>> >> > > >>>> ------------------------------------------------------------------------ >> > > >>>> BRs, >> > > >>>> Lin >> > > >> > >> > > > > > >

3 6

RFR (L): 8244603 and 8238858: Improve young gen sizing
by Thomas Schatzl 24 Jun '20

24 Jun '20

Hi all, can I have reviews for this change that improves young gen sizing a lot to prepare for heap shrinking during young gc (JDK-8238687) ;) In particular, with this change the following issues two related issues are fixed: * 8238858: G1 Mixed gc young gen sizing might cause the first mixed gc to immediately follow the prepare mixed gc * 8244603: G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs These have been grouped together because it is too hard to separate them out as the bugs required significant rewrite in the young gen sizing. This results in G1 following GCTimeRatio much better than before, leading to less erratic heap expansion. That is, constant loads do not result in that much overcommit any more. Some background: At end of gc and when the remembered set sampling thread (re-)evaluates the young gen G1 calculates two values: - the *desired* (unconstrained) size of the young gen; desired/unconstrained meaning that these values are not limited by actually existing free regions. This value is interesting for adaptive IHOP so that it (better) converges to a fixed value. (There is some bugfix, JDK-8238163, coming for this to fix a few issues with that) - the actual *target* size for the young gen, i.e. after taking constraints in available free regions into account, and whether we are currently already needing to use parts of the reserve or not. Some problems that were fixed with the current code: - during calculation of the *desired* young gen length G1 basically sizes the young gen during mixed gc to the minimum allowed size always. This causes unnecessary spikes in short/long term ratios, causing lots of heap increases even with a constant load. Since we do not shrink the heap yet during regular gcs, this typically ended up in fully expanding the heap (unless the reclamations during Remark actually reclaimed something, but the equilibrium of committed heap between these two mechanisms is much higher). E.g. on specjbb2015 fixed IR (constant load) with "small" and "medium" load G1 will use half the heap now while staying < GCTimeRatio. - at end of gc g1 calculates the young gen for the *next* gc, i.e. during the prepare mixed gc g1 should already use the "reduced" amount of regions (that's JDK-8238858); similarly the *last* mixed gc in the mixed gc phase should already use the calculation for the young phase. The current code does not. This partially fixes some "at end of mixed gc it takes a while for g1 to achieve previous young gen size again" issues. (There is a CR for that, but as mentioned, this change does not completely solve it). - there were some calculations to ensure that "at least one region will be allocated" every time g1 recalculates young gen but that really resulted in g1 increasing the young gen by at least one. You do not always want that, particularly since we regularly revise the young gen. What you want is a minimum desired *eden* size. - the desired and target young gen size calculation was done in a single huge method. This change splits up the code a bit. - the code that calculated the actual *target* young length has been very inconsistent in handling the reserve. I.e. the limit to the actually available free regions only applied in some cases, and notably not if you were already using the reserve, causing strange behavior where at least the calculated young gen target length was higher than available free regions. This could cause full gcs. - I added some detailed trace-level logging for the ergonomic decisions which really helps when debugging issues, but might be too large/intrusive for the code - I am not sure whether to leave it in. Reviewing: I think the best entry point for this change is G1Policy::update_young_list_target_length(size_t) where the new code first calculates a desired young gen length and then target young length. Some additional notes: - eden before a mixed gc is calculated by predicting the time for the minimum amount of old gen regions we will definitely take (min_old_cset_length) and then letting eden fill up the remainder. Often this results in significantly larger young gens than before this change, at worst young gen will be limited to minimum young gen size (as before). Overall it works fairly well, i.e. gives much smoother cpu usage. There is a caveat to that in that it depends on accuracy of predictions. Since G1 predictions are often too high, we might want to take more a lot more optional regions in the future to not be required to early terminate the mixed gc I.e. I have often seen that we do not use up the 200ms pause time goal. - currently, and like before, MMU desired length overrides the pause time desired length. I.e. *if* a GCPauseTimeIntervalMillis is set, the spacing between gcs is more important than actual pause times. The difference is that now that there is an explicit comment about this behavior there :) - when eating into the reserve (last 10% of heap), we at most allow use of the sizer's min young length or half of the reserve regions (rounded up!), whichever is higher. This is an arbitrary decision, but since supposedly at that time we are already close to the next mixed gc due to adaptive ihop, so we can take more. - note that all this is about calculating a *target* length, not the actual length. Actual length may be higher e.g. due to gclocker. - there may be some out-of-box performance regressions since G1 does not expand the heap that much more. Performance can be restored by either decreasing GCTimeRatio, or better setting minimum heap sizes. Actually, in the future, when shrinking is implemented (JDK-8238687), these may be more severe (in some benchmarks, actual gc usage is still <2%). I will likely try to balance that with decreasing default GCTimeRatio value in the future. CR: https://bugs.openjdk.java.net/browse/JDK-8244603 https://bugs.openjdk.java.net/browse/JDK-8238858 Webrev: http://cr.openjdk.java.net/~tschatzl/8244603/webrev/ Testing: mach5 tier1-5, perf testing Thanks, Thomas

3 6

RFR: 8245203/8245204/8245208: ZGC: Don't hold the ZPageAllocator lock while committing/uncommitting memory
by Per Liden 09 Jun '20

09 Jun '20

Please review this series of three patches to rework the page allocation path so that we don't hold the ZPageAllocator lock while committing/uncommitting memory. Patch 1 & 2 are small and preparatory. Patch 3 is the main patch and it's unfortunately fairly large as it was hard to break up in a sensible way. --------------------- 1) 8245203: ZGC: Don't track size in ZPhysicalMemoryBacking To make it easier to allow for more concurrent commit/uncommit we should not track the backing "size" in ZPhysicalMemoryBacking. Instead we can add the full physical memory range (from 0 to max_capacity) to the list of uncommitted memory at startup. This removes the need to track and update the backing size (which otherwise needs to be properly synchronized). Bug: https://bugs.openjdk.java.net/browse/JDK-8245203 Webrev: http://cr.openjdk.java.net/~pliden/8245203/webrev.0 --------------------- 2) 8245204: ZGC: Introduce ZListRemoveIterator Add ZListRemoveIterator, which unlike ZListIterator, iterates over a non-const "ZList<T>" and each call to "next()" also removes the returned element from the list. Bug: https://bugs.openjdk.java.net/browse/JDK-8245204 Webrev: http://cr.openjdk.java.net/~pliden/8245204/webrev.0 --------------------- 3) 8245208: ZGC: Don't hold the ZPageAllocator lock while committing/uncommitting memory We're currently holding the ZPageAllocator lock while performing a number of expensive operations, such as committing and uncommitting memory. This can have a very negative impact on latency, for example, when a Java thread is trying to allocate a page from the page cache while the ZUncommitter thread is uncommitting a portion of the heap. Bug: https://bugs.openjdk.java.net/browse/JDK-8245208 Webrev: http://cr.openjdk.java.net/~pliden/8245208/webrev.0 --------------------- Testing: More than 10 runs of Tier1-7 on all ZGC supported platforms. Manual testing to provoke various error conditions on Linux. This patchset also solves https://bugs.openjdk.java.net/browse/JDK-8242527 as a side-effect. /Per

3 17

RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
by Reingruber, Richard 05 Jun '20

05 Jun '20

Hi Vladimir, > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ > Not an expert in JVMTI code base, so can't comment on the actual changes. > From JIT-compilers perspective it looks good. I put out webrev.1 a while ago [1]: Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ You originally suggested to use a handshake to switch a thread into interpreter mode [2]. I'm using a direct handshake now, because I think it is the best fit. May I ask if webrev.1 still looks good to you from JIT-compilers perspective? Can I list you as (partial) Reviewer? Thanks, Richard. [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245… [2] http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/0303… -----Original Message----- From: Vladimir Ivanov <vladimir.x.ivanov(a)oracle.com> Sent: Freitag, 7. Februar 2020 09:19 To: Reingruber, Richard <richard.reingruber(a)sap.com>; serviceability-dev(a)openjdk.java.net; hotspot-compiler-dev(a)openjdk.java.net Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ Not an expert in JVMTI code base, so can't comment on the actual changes. From JIT-compilers perspective it looks good. Best regards, Vladimir Ivanov > Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 > > The change avoids making all compiled methods on stack not_entrant when switching a java thread to > interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack. > > Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations. > > Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms. > > Thanks, Richard. > > See also my question if anyone knows a reason for making the compiled methods not_entrant: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/0303… >

3 10

RFR: 8246135: ZGC: Save important log lines and print them when dumping hs_err files
by Stefan Karlsson 03 Jun '20

03 Jun '20

Hi all, Please review this patch to save some of the important ZGC log lines and print them when dumping hs_err files. https://cr.openjdk.java.net/~stefank/8246135/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8246135 The patch adds a concept of "precious" log lines. What's typically logged are GC initialization lines, but also error messages are saved. These lines are then dumped in the hs_err file if the JVM crashes or hits an assert. The lines can also be printed in a debugger to get a quick overview when debugging. The precious lines are always saved, but just like any other Unified Logging calls, only logged if the tags are enabled. The patch builds on the JDK-8246134 patch. The hs_err output looks like this: ZGC Precious Log: NUMA Support: Disabled CPUs: 8 total, 8 available Memory: 16384M Large Page Support: Disabled Medium Page Size: 32M Workers: 5 parallel, 1 concurrent Address Space Type: Contiguous/Unrestricted/Complete Address Space Size: 65536M x 3 = 196608M Min Capacity: 42M Initial Capacity: 256M Max Capacity: 4096M Max Reserve: 42M Pre-touch: Disabled Uncommit: Enabled Uncommit Delay: 300s Runtime Workers: 5 parallel ZGC Globals: GlobalPhase: 2 (Relocate) GlobalSeqNum: 1 Offset Max: 4096G (0x0000040000000000) Page Size Small: 2M Page Size Medium: 32M ZGC Metadata Bits: Good: 0x0000100000000000 Bad: 0x00002c0000000000 WeakBad: 0x00000c0000000000 Marked: 0x0000040000000000 Remapped: 0x0000100000000000 Heap: ZHeap used 12M, capacity 256M, max capacity 4096M Metaspace used 6501K, capacity 6615K, committed 6784K, reserved 1056768K class space used 559K, capacity 588K, committed 640K, reserved 1048576K ZGC Page Table: Small 0x0000000000000000 0x0000000000200000 0x0000000000200000 Allocating Small 0x0000000000200000 0x0000000000240000 0x0000000000400000 Allocating Small 0x0000000000400000 0x0000000000600000 0x0000000000600000 Allocating Small 0x0000000000600000 0x0000000000800000 0x0000000000800000 Allocating Small 0x0000000000800000 0x00000000009c0000 0x0000000000a00000 Allocating Small 0x0000000000a00000 0x0000000000a40000 0x0000000000c00000 Allocating Thanks, StefanK

4 20

RFR(S) 8245925 G1 allocates EDEN region after CDS has executed GC
by Ioi Lam 02 Jun '20

02 Jun '20

https://bugs.openjdk.java.net/browse/JDK-8245925 http://cr.openjdk.java.net/~iklam/jdk15/8245925-g1-eden-after-cds-gc.v01/ Summary: CDS supports archived heap objects only for G1. During -Xshare:dump, CDS executes a full GC so that G1 will compact the heap regions, leaving maximum contiguous free space at the top of the heap. Then, the archived heap regions are allocated from the top of the heap. Under some circumstances, java.lang.ref.Cleaners will execute after the GC has completed. The cleaners may allocate or synchronized, which will cause G1 to allocate an EDEN region at the top of the heap. The fix is simple -- after CDS has entered a safepoint, if EDEN regions exist, exit the safepoint, run GC, and try again. Eventually all the cleaners will be executed and no more allocation can happen. For safety, I limit the retry count to 30 (or about total 9 seconds). Thanks - Ioi <https://bugs.openjdk.java.net/browse/JDK-8245925>

3 8

RFR(S/M) : 8243434 : use reproducible random in :vmTestbase_vm_g1classunloading
by Igor Ignatyev 02 Jun '20

02 Jun '20

http://cr.openjdk.java.net/~iignatyev/8243434/webrev.00 > 132 lines changed: 8 ins; 0 del; 124 mod Hi all, could you please review this patch? from JBS: > this subtask is to use j.t.l.Utils.getRandomInstance() as a random number generator, where applicable, in : vmTestbase_vm_g1classunloading test group and marking the tests which make use of "randomness" with a proper k/w. testing: : vmTestbase_vm_g1classunloading test group JBS: https://bugs.openjdk.java.net/browse/JDK-8243434 webrevs: - code changes: http://cr.openjdk.java.net/~iignatyev//8243434/webrev.00.code > 15 lines changed: 8 ins; 0 del; 7 mod; - adding k/w: http://cr.openjdk.java.net/~iignatyev//8243434/webrev.00.kw > 112 lines changed: 0 ins; 0 del; 112 mod; - full: http://cr.openjdk.java.net/~iignatyev//8243434/webrev.00 > 132 lines changed: 8 ins; 0 del; 124 mod Thanks, -- Igor

3 6

RFR(S/M) : 8243430 : use reproducible random in :vmTestbase_vm_gc
by Igor Ignatyev 02 Jun '20

02 Jun '20

http://cr.openjdk.java.net/~iignatyev/8243430/webrev.00 > 555 lines changed: 11 ins; 65 del; 479 mod; Hi all, could you please review this small patch? from JBS: > this subtask is to use j.t.l.Utils.getRandomInstance() as a random number generator, where applicable, in : vmTestbase_vm_gc test group and marking the tests which make use of "randomness" with a proper k/w. testing: : vmTestbase_vm_gc test group JBS: https://bugs.openjdk.java.net/browse/JDK-8243430 webrevs: - code changes: http://cr.openjdk.java.net/~iignatyev//8243430/webrev.00.code > 94 lines changed: 11 ins; 65 del; 18 mod; - adding k/w: http://cr.openjdk.java.net/~iignatyev//8243430/webrev.00.kw > 229 lines changed: 0 ins; 0 del; 229 mod; - full: http://cr.openjdk.java.net/~iignatyev//8243430/webrev.00 > 555 lines changed: 11 ins; 65 del; 479 mod; Thanks, -- Igor

4 9