August 2013 - hotspot-gc-dev

hg: hsx/hotspot-gc/hotspot: 8023227: Enhance layout_helper_log2_element_size assert
by stefan.karlsson＠oracle.com 20 Aug '13

20 Aug '13

Changeset: d0afbee540e0 Author: stefank Date: 2013-08-19 13:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d0afbee540e0 8023227: Enhance layout_helper_log2_element_size assert Reviewed-by: mgerdin, jmasa ! src/share/vm/oops/klass.hpp

1 0

Review request (XS): 8023227: Enhance layout_helper_log2_element_size assert
by Stefan Karlsson 19 Aug '13

19 Aug '13

http://cr.openjdk.java.net/~stefank/8023227/webrev.00 Print the values of l2esz and lh when we hit the assert: assert(l2esz <= LogBitsPerLong, "sanity"); thanks, StefanK

3 2

Visual heap: card table, heap cards, roots, reference chains
by STIRLING, SCOTT 19 Aug '13

19 Aug '13

Hi - this question comes out of personal and professional interest in the JVM's garbage collectors and how they work at the most detailed level possible. I'm wondering if anyone has developed a visualizer or, short of that, even a debug/trace log that could be visualized, which would show a deeper, more granular view of the JVM heap's micro-structures at runtime. It may sound a little nuts to people who are steeped in it, but, for educational and troubleshooting purposes, it would be very interesting to be able to visualize the runtime heap in Java at the macro level (generations) and at the micro-level (heap words, card table, GC roots and chain of references). I'm not expecting something like that would be usable in production or for very large heaps (unless it could be saved off in files and viewed offline). But I can imagine a view in a tool like VisualVM that shows the next level of detail of how the heap is structured at the micro-level and how it changes as programs execute and garbage collection occurs. Watching it in slow motion and replaying captured traces in offline mode would be interesting. I've been lurking on the list for a few. I have the OpenJDK jdk8 project compiling on Windows and a doxygen/GraphViz config for generating documentation and dependency graphs of the C++ code. I've been reading up on CMS, G1 and the GC papers and patents behind them (as well as the Mono/Windows CLR). My interest and experience with testing and tuning JVM heaps and GC for large e-comm sites hosted at AT&T has led to the questions and interest expressed above. Sorry to interject from out of left field. But I highly appreciate any pointers or thoughts on this. And I thank you for making and keeping this project open source. Kind regards, Scott Stirling Principal Technical Architect AT&T, Boston

4 4

Re: RFR: 7164841: Improvements to the GC log file rotation
by Yumin Qi 16 Aug '13

16 Aug '13

Calvin, Thanks for the review, See embedded. On 8/16/2013 6:26 PM, Calvin Cheung wrote: > Couple of minor comments in ostream.cpp: > > 1) > 479 char time_msg[256]; > 480 char time_str[64]; > 481 char renamed_file_name[256]; > > I think you can replace 256 with MAX_PATH. However, we define MAX_PATH > as (2 * K) in unix platforms. So it maybe too large of a buffer for > this purpose. On windows, I think it is defined as 256. > > In the same file, there's > static const int buffer_length = 32; > in outputStream::date_stamp(). > > I'm thinking you can have a #define for the size for time_str and use > the same #define in > outputStream::date_stamp(). > I considered using MAX_PATH but it is too big for this purpose so take current solution. For time string we may use buffer_length, I will change that. > 2) > int jio_snprintf(char *str, size_t count, const char *fmt, ...) > > The return value of jio_snprintf() isn't checked. > It could return -1 from calling _vsnprintf(). However, I don't see the > return status being check in the existing code. So I'm not sure if it > is a must check. > This return value only indicates the writing of chars finished and number of chars is less or equals to count (buffer not over flowed). If copy up to count and string truncated it is still OK, the buffer will contain partial strings but not all. So usually we don't check its return value. > 3) > > 516 if (access(renamed_file_name, NOT_WINDOWS(F_OK) WINDOWS_ONLY(0)) > == 0) { > > 543 if (access(renamed_file_name, NOT_WINDOWS(F_OK) WINDOWS_ONLY(0)) > == 0) { > > You can use ERROR_SUCCESS instead of 0 for the WINDOWS_ONLY part. > Using ERROR_SUCCESS will mislead reading code since it is usually used for a return value from Windows API call. In fact there is definitions in io.h of Visual C++: /* File attribute constants for _findfirst() */ #define _A_NORMAL 0x00 /* Normal file - No read/write restrictions */ #define _A_RDONLY 0x01 /* Read only file */ #define _A_HIDDEN 0x02 /* Hidden file */ #define _A_SYSTEM 0x04 /* System file */ #define _A_SUBDIR 0x10 /* Subdirectory */ #define _A_ARCH 0x20 /* Archive file */ But I would like to use '0' here to not make the symbol complicate for reading. Thanks Yumin > Calvin > > On 8/15/2013 8:35 AM, Yumin Qi wrote: >> Hi, >> >> Can I have your review for this small changes? >> http://cr.openjdk.java.net/~minqi/7164841/webrev00/ >> <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev00/> >> >> This is for a enhancement to add head/tail message to the logging >> files to assist reading GC output. >> 1. modified prompt message if invalid arguments used for log rotating; >> 2. add time and file name message to log file head/tail. >> 3. for easily identify which log file is current, use file name >> like <filename>.n.current, after it reaches maximum size, rename it >> to <filename>.n >> On Windows, there is no F_OK (existing test) definition, F_OK >> is defined as "0" and for _access of VC++, it just describes: >> >> modevalue >> >> >> >> Checks file for >> >> 00 >> >> >> >> Existence only >> >> 02 >> >> >> >> Write-only >> >> 04 >> >> >> >> Read-only >> >> 06 >> >> >> >> Read and write >> >> >> http://msdn.microsoft.com/en-us/library/1w06ktdy.aspx >> The definition are consistent with unistd.h. >> >> Test: JPRT and jtreg. >> >> Thanks >> Yumin >

1 0

hg: hsx/hotspot-gc/hotspot: 8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0
by bengt.rutisson＠oracle.com 16 Aug '13

16 Aug '13

Changeset: 9720d338b1d5 Author: brutisso Date: 2013-08-16 11:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9720d338b1d5 8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0 Reviewed-by: stefank, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

1 0

Request for review - 8022817: CMS should not shrink if compaction was not done
by Jon Masamitsu 16 Aug '13

16 Aug '13

8022817: CMS should not shrink if compaction was not done If UseCMSCompactAtFullCollection is turned off, a full GC that is done in the foreground but does not compact should not shrink the generation. In that case a mark-sweep was done so the free space is maintained in freelists (not as a contiguous area at the end of the generation) and shrinking for freelists is not implemented. http://cr.openjdk.java.net/~jmasa/8022817/webrev.00/ Thanks. Jon

3 6

RFR (XS): JDK-8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0
by Bengt Rutisson 16 Aug '13

16 Aug '13

Hi everyone, Could I have a couple of reviews for this small change? http://cr.openjdk.java.net/~brutisso/8023145/webrev.00/ From the bug report: With the fix for JDK-7145569 the method G1CollectedHeap::mark_strong_code_roots() was introduced. However, this method assumes that the work gang has been set up. If we are running with ParallelGCThreads=0 we don't set up the work gang and thus get a null pointer: This simple JTreg test illustrates the issue: /** * @test Test8000311 * @key gc * @bug 8000311 * @summary G1: ParallelGCThreads==0 broken * @run main/othervm -XX:+UseG1GC -XX:ParallelGCThreads=0 -XX:+ResizePLAB -XX:+ExplicitGCInvokesConcurrent Test8000311 * @author filipp.zhinkin(a)oracle.com */ import java.util.*; public class Test8000311 { public static void main(String args[]) { for(int i = 0; i<100; i++) { byte[] garbage = new byte[1000]; System.gc(); } } } It crashes with a null pointer: # SIGSEGV (0xb) at pc=0xffffffff7d3fadf4, pid=22622, tid=6 si_addr=0x0000000000000000 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7fadf4] void G1CollectedHeap::mark_strong_code_roots(unsigned)+0x44;; __1cPG1CollectedHeapWmark_strong_code_roots6MI_v_+0x44 V [libjvm.so+0x7f5f80] void G1CollectedHeap::g1_process_strong_roots(bool,SharedHeap::ScanningOption,OopClosure*,OopsInHeapRegionClosure*,G1KlassScanClosure*,int)+0x5e0;; __1cPG1CollectedHeapXg1_process_strong_roots6MbnKSharedHeapOScanningOption_pnKOopClosure_pnXOopsInHeapRegionClosure_pnSG1KlassScanClosure_i_v_+0x5e0 V [libjvm.so+0x7fccdc] void G1ParTask::work(unsigned)+0x67c;; __1cJG1ParTaskEwork6MI_v_+0x67c V [libjvm.so+0x7f7500] void G1CollectedHeap::evacuate_collection_set(EvacuationInfo&)+0x418;; __1cPG1CollectedHeapXevacuate_collection_set6MrnOEvacuationInfo__v_+0x418 V [libjvm.so+0x7f1a84] bool G1CollectedHeap::do_collection_pause_at_safepoint(double)+0x824;; __1cPG1CollectedHeapbGdo_collection_pause_at_safepoint6Md_b_+0x824 V [libjvm.so+0x1241a7c] void VM_G1IncCollectionPause::doit()+0x2e4;; __1cXVM_G1IncCollectionPauseEdoit6M_v_+0x2e4 V [libjvm.so+0x123de38] void VM_Operation::evaluate()+0xf8;; __1cMVM_OperationIevaluate6M_v_+0xf8 V [libjvm.so+0x1239dcc] void VMThread::evaluate_operation(VM_Operation*)+0x254;; __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_+0x254 V [libjvm.so+0x123a83c] void VMThread::loop()+0x654;; __1cIVMThreadEloop6M_v_+0x654 V [libjvm.so+0x1239834] void VMThread::run()+0xe4;; __1cIVMThreadDrun6M_v_+0xe4 V [libjvm.so+0xef8af0] java_start+0x258;; java_start+0x258 With the proposed fix the test passes. Thanks, Bengt

3 3

hg: hsx/hotspot-gc/hotspot: 2 new changesets
by bengt.rutisson＠oracle.com 15 Aug '13

15 Aug '13

Changeset: 5888334c9c24 Author: johnc Date: 2013-08-15 10:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/5888334c9c24 7145569: G1: optimize nmethods scanning Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead. Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: 8088d93a63e6 Author: brutisso Date: 2013-08-15 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8088d93a63e6 Merge

1 0

hg: hsx/hotspot-gc/hotspot: 2 new changesets
by erik.helin＠oracle.com 15 Aug '13

15 Aug '13

Changeset: 274ce305e5b9 Author: ehelin Date: 2013-08-13 18:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/274ce305e5b9 8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0 Reviewed-by: stefank, brutisso, sjohanss ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp Changeset: 33d39b75663f Author: ehelin Date: 2013-08-15 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/33d39b75663f Merge

1 0

hg: hsx/hotspot-gc/nashorn: 5 new changesets
by john.coomes＠oracle.com 15 Aug '13

15 Aug '13

Changeset: 0ad00ae4fec6 Author: hannesw Date: 2013-08-01 12:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/0ad00ae4fec6 8020132: Big object literal with numerical keys exceeds method size Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + test/script/basic/JDK-8020132.js + test/script/basic/JDK-8020132.js.EXPECTED Changeset: bb0f3c896cb7 Author: sundar Date: 2013-08-06 13:10 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/bb0f3c896cb7 Merge Changeset: ab90c566272d Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/ab90c566272d Merge Changeset: 414203de4374 Author: lana Date: 2013-08-13 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/414203de4374 Merge Changeset: afc100513451 Author: cl Date: 2013-08-15 09:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/nashorn/rev/afc100513451 Added tag jdk8-b103 for changeset 414203de4374 ! .hgtags

1 0