Search Results

Search found 672 results on 27 pages for 'gc'.

Page 1/27 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Understanding G1 GC Logs

    - by poonam
    The purpose of this post is to explain the meaning of GC logs generated with some tracing and diagnostic options for G1 GC. We will take a look at the output generated with PrintGCDetails which is a product flag and provides the most detailed level of information. Along with that, we will also look at the output of two diagnostic flags that get enabled with -XX:+UnlockDiagnosticVMOptions option - G1PrintRegionLivenessInfo that prints the occupancy and the amount of space used by live objects in each region at the end of the marking cycle and G1PrintHeapRegions that provides detailed information on the heap regions being allocated and reclaimed. We will be looking at the logs generated with JDK 1.7.0_04 using these options. Option -XX:+PrintGCDetails Here's a sample log of G1 collection generated with PrintGCDetails. 0.522: [GC pause (young), 0.15877971 secs] [Parallel Time: 157.1 ms] [GC Worker Start (ms): 522.1 522.2 522.2 522.2 Avg: 522.2, Min: 522.1, Max: 522.2, Diff: 0.1] [Ext Root Scanning (ms): 1.6 1.5 1.6 1.9 Avg: 1.7, Min: 1.5, Max: 1.9, Diff: 0.4] [Update RS (ms): 38.7 38.8 50.6 37.3 Avg: 41.3, Min: 37.3, Max: 50.6, Diff: 13.3] [Processed Buffers : 2 2 3 2 Sum: 9, Avg: 2, Min: 2, Max: 3, Diff: 1] [Scan RS (ms): 9.9 9.7 0.0 9.7 Avg: 7.3, Min: 0.0, Max: 9.9, Diff: 9.9] [Object Copy (ms): 106.7 106.8 104.6 107.9 Avg: 106.5, Min: 104.6, Max: 107.9, Diff: 3.3] [Termination (ms): 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] [Termination Attempts : 1 4 4 6 Sum: 15, Avg: 3, Min: 1, Max: 6, Diff: 5] [GC Worker End (ms): 679.1 679.1 679.1 679.1 Avg: 679.1, Min: 679.1, Max: 679.1, Diff: 0.1] [GC Worker (ms): 156.9 157.0 156.9 156.9 Avg: 156.9, Min: 156.9, Max: 157.0, Diff: 0.1] [GC Worker Other (ms): 0.3 0.3 0.3 0.3 Avg: 0.3, Min: 0.3, Max: 0.3, Diff: 0.0] [Clear CT: 0.1 ms] [Other: 1.5 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.3 ms] [Ref Enq: 0.0 ms] [Free CSet: 0.3 ms] [Eden: 12M(12M)->0B(10M) Survivors: 0B->2048K Heap: 13M(64M)->9739K(64M)] [Times: user=0.59 sys=0.02, real=0.16 secs] This is the typical log of an Evacuation Pause (G1 collection) in which live objects are copied from one set of regions (young OR young+old) to another set. It is a stop-the-world activity and all the application threads are stopped at a safepoint during this time. This pause is made up of several sub-tasks indicated by the indentation in the log entries. Here's is the top most line that gets printed for the Evacuation Pause. 0.522: [GC pause (young), 0.15877971 secs] This is the highest level information telling us that it is an Evacuation Pause that started at 0.522 secs from the start of the process, in which all the regions being evacuated are Young i.e. Eden and Survivor regions. This collection took 0.15877971 secs to finish. Evacuation Pauses can be mixed as well. In which case the set of regions selected include all of the young regions as well as some old regions. 1.730: [GC pause (mixed), 0.32714353 secs] Let's take a look at all the sub-tasks performed in this Evacuation Pause. [Parallel Time: 157.1 ms] Parallel Time is the total elapsed time spent by all the parallel GC worker threads. The following lines correspond to the parallel tasks performed by these worker threads in this total parallel time, which in this case is 157.1 ms. [GC Worker Start (ms): 522.1 522.2 522.2 522.2Avg: 522.2, Min: 522.1, Max: 522.2, Diff: 0.1] The first line tells us the start time of each of the worker thread in milliseconds. The start times are ordered with respect to the worker thread ids – thread 0 started at 522.1ms and thread 1 started at 522.2ms from the start of the process. The second line tells the Avg, Min, Max and Diff of the start times of all of the worker threads. [Ext Root Scanning (ms): 1.6 1.5 1.6 1.9 Avg: 1.7, Min: 1.5, Max: 1.9, Diff: 0.4] This gives us the time spent by each worker thread scanning the roots (globals, registers, thread stacks and VM data structures). Here, thread 0 took 1.6ms to perform the root scanning task and thread 1 took 1.5 ms. The second line clearly shows the Avg, Min, Max and Diff of the times spent by all the worker threads. [Update RS (ms): 38.7 38.8 50.6 37.3 Avg: 41.3, Min: 37.3, Max: 50.6, Diff: 13.3] Update RS gives us the time each thread spent in updating the Remembered Sets. Remembered Sets are the data structures that keep track of the references that point into a heap region. Mutator threads keep changing the object graph and thus the references that point into a particular region. We keep track of these changes in buffers called Update Buffers. The Update RS sub-task processes the update buffers that were not able to be processed concurrently, and updates the corresponding remembered sets of all regions. [Processed Buffers : 2 2 3 2Sum: 9, Avg: 2, Min: 2, Max: 3, Diff: 1] This tells us the number of Update Buffers (mentioned above) processed by each worker thread. [Scan RS (ms): 9.9 9.7 0.0 9.7 Avg: 7.3, Min: 0.0, Max: 9.9, Diff: 9.9] These are the times each worker thread had spent in scanning the Remembered Sets. Remembered Set of a region contains cards that correspond to the references pointing into that region. This phase scans those cards looking for the references pointing into all the regions of the collection set. [Object Copy (ms): 106.7 106.8 104.6 107.9 Avg: 106.5, Min: 104.6, Max: 107.9, Diff: 3.3] These are the times spent by each worker thread copying live objects from the regions in the Collection Set to the other regions. [Termination (ms): 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] Termination time is the time spent by the worker thread offering to terminate. But before terminating, it checks the work queues of other threads and if there are still object references in other work queues, it tries to steal object references, and if it succeeds in stealing a reference, it processes that and offers to terminate again. [Termination Attempts : 1 4 4 6 Sum: 15, Avg: 3, Min: 1, Max: 6, Diff: 5] This gives the number of times each thread has offered to terminate. [GC Worker End (ms): 679.1 679.1 679.1 679.1 Avg: 679.1, Min: 679.1, Max: 679.1, Diff: 0.1] These are the times in milliseconds at which each worker thread stopped. [GC Worker (ms): 156.9 157.0 156.9 156.9 Avg: 156.9, Min: 156.9, Max: 157.0, Diff: 0.1] These are the total lifetimes of each worker thread. [GC Worker Other (ms): 0.3 0.3 0.3 0.3Avg: 0.3, Min: 0.3, Max: 0.3, Diff: 0.0] These are the times that each worker thread spent in performing some other tasks that we have not accounted above for the total Parallel Time. [Clear CT: 0.1 ms] This is the time spent in clearing the Card Table. This task is performed in serial mode. [Other: 1.5 ms] Time spent in the some other tasks listed below. The following sub-tasks (which individually may be parallelized) are performed serially. [Choose CSet: 0.0 ms] Time spent in selecting the regions for the Collection Set. [Ref Proc: 0.3 ms] Total time spent in processing Reference objects. [Ref Enq: 0.0 ms] Time spent in enqueuing references to the ReferenceQueues. [Free CSet: 0.3 ms] Time spent in freeing the collection set data structure. [Eden: 12M(12M)->0B(13M) Survivors: 0B->2048K Heap: 14M(64M)->9739K(64M)] This line gives the details on the heap size changes with the Evacuation Pause. This shows that Eden had the occupancy of 12M and its capacity was also 12M before the collection. After the collection, its occupancy got reduced to 0 since everything is evacuated/promoted from Eden during a collection, and its target size grew to 13M. The new Eden capacity of 13M is not reserved at this point. This value is the target size of the Eden. Regions are added to Eden as the demand is made and when the added regions reach to the target size, we start the next collection. Similarly, Survivors had the occupancy of 0 bytes and it grew to 2048K after the collection. The total heap occupancy and capacity was 14M and 64M receptively before the collection and it became 9739K and 64M after the collection. Apart from the evacuation pauses, G1 also performs concurrent-marking to build the live data information of regions. 1.416: [GC pause (young) (initial-mark), 0.62417980 secs] ….... 2.042: [GC concurrent-root-region-scan-start] 2.067: [GC concurrent-root-region-scan-end, 0.0251507] 2.068: [GC concurrent-mark-start] 3.198: [GC concurrent-mark-reset-for-overflow] 4.053: [GC concurrent-mark-end, 1.9849672 sec] 4.055: [GC remark 4.055: [GC ref-proc, 0.0000254 secs], 0.0030184 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 4.088: [GC cleanup 117M->106M(138M), 0.0015198 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 4.090: [GC concurrent-cleanup-start] 4.091: [GC concurrent-cleanup-end, 0.0002721] The first phase of a marking cycle is Initial Marking where all the objects directly reachable from the roots are marked and this phase is piggy-backed on a fully young Evacuation Pause. 2.042: [GC concurrent-root-region-scan-start] This marks the start of a concurrent phase that scans the set of root-regions which are directly reachable from the survivors of the initial marking phase. 2.067: [GC concurrent-root-region-scan-end, 0.0251507] End of the concurrent root region scan phase and it lasted for 0.0251507 seconds. 2.068: [GC concurrent-mark-start] Start of the concurrent marking at 2.068 secs from the start of the process. 3.198: [GC concurrent-mark-reset-for-overflow] This indicates that the global marking stack had became full and there was an overflow of the stack. Concurrent marking detected this overflow and had to reset the data structures to start the marking again. 4.053: [GC concurrent-mark-end, 1.9849672 sec] End of the concurrent marking phase and it lasted for 1.9849672 seconds. 4.055: [GC remark 4.055: [GC ref-proc, 0.0000254 secs], 0.0030184 secs] This corresponds to the remark phase which is a stop-the-world phase. It completes the left over marking work (SATB buffers processing) from the previous phase. In this case, this phase took 0.0030184 secs and out of which 0.0000254 secs were spent on Reference processing. 4.088: [GC cleanup 117M->106M(138M), 0.0015198 secs] Cleanup phase which is again a stop-the-world phase. It goes through the marking information of all the regions, computes the live data information of each region, resets the marking data structures and sorts the regions according to their gc-efficiency. In this example, the total heap size is 138M and after the live data counting it was found that the total live data size dropped down from 117M to 106M. 4.090: [GC concurrent-cleanup-start] This concurrent cleanup phase frees up the regions that were found to be empty (didn't contain any live data) during the previous stop-the-world phase. 4.091: [GC concurrent-cleanup-end, 0.0002721] Concurrent cleanup phase took 0.0002721 secs to free up the empty regions. Option -XX:G1PrintRegionLivenessInfo Now, let's look at the output generated with the flag G1PrintRegionLivenessInfo. This is a diagnostic option and gets enabled with -XX:+UnlockDiagnosticVMOptions. G1PrintRegionLivenessInfo prints the live data information of each region during the Cleanup phase of the concurrent-marking cycle. 26.896: [GC cleanup ### PHASE Post-Marking @ 26.896### HEAP committed: 0x02e00000-0x0fe00000 reserved: 0x02e00000-0x12e00000 region-size: 1048576 Cleanup phase of the concurrent-marking cycle started at 26.896 secs from the start of the process and this live data information is being printed after the marking phase. Committed G1 heap ranges from 0x02e00000 to 0x0fe00000 and the total G1 heap reserved by JVM is from 0x02e00000 to 0x12e00000. Each region in the G1 heap is of size 1048576 bytes. ### type address-range used prev-live next-live gc-eff### (bytes) (bytes) (bytes) (bytes/ms) This is the header of the output that tells us about the type of the region, address-range of the region, used space in the region, live bytes in the region with respect to the previous marking cycle, live bytes in the region with respect to the current marking cycle and the GC efficiency of that region. ### FREE 0x02e00000-0x02f00000 0 0 0 0.0 This is a Free region. ### OLD 0x02f00000-0x03000000 1048576 1038592 1038592 0.0 Old region with address-range from 0x02f00000 to 0x03000000. Total used space in the region is 1048576 bytes, live bytes as per the previous marking cycle are 1038592 and live bytes with respect to the current marking cycle are also 1038592. The GC efficiency has been computed as 0. ### EDEN 0x03400000-0x03500000 20992 20992 20992 0.0 This is an Eden region. ### HUMS 0x0ae00000-0x0af00000 1048576 1048576 1048576 0.0### HUMC 0x0af00000-0x0b000000 1048576 1048576 1048576 0.0### HUMC 0x0b000000-0x0b100000 1048576 1048576 1048576 0.0### HUMC 0x0b100000-0x0b200000 1048576 1048576 1048576 0.0### HUMC 0x0b200000-0x0b300000 1048576 1048576 1048576 0.0### HUMC 0x0b300000-0x0b400000 1048576 1048576 1048576 0.0### HUMC 0x0b400000-0x0b500000 1001480 1001480 1001480 0.0 These are the continuous set of regions called Humongous regions for storing a large object. HUMS (Humongous starts) marks the start of the set of humongous regions and HUMC (Humongous continues) tags the subsequent regions of the humongous regions set. ### SURV 0x09300000-0x09400000 16384 16384 16384 0.0 This is a Survivor region. ### SUMMARY capacity: 208.00 MB used: 150.16 MB / 72.19 % prev-live: 149.78 MB / 72.01 % next-live: 142.82 MB / 68.66 % At the end, a summary is printed listing the capacity, the used space and the change in the liveness after the completion of concurrent marking. In this case, G1 heap capacity is 208MB, total used space is 150.16MB which is 72.19% of the total heap size, live data in the previous marking was 149.78MB which was 72.01% of the total heap size and the live data as per the current marking is 142.82MB which is 68.66% of the total heap size. Option -XX:+G1PrintHeapRegions G1PrintHeapRegions option logs the regions related events when regions are committed, allocated into or are reclaimed. COMMIT/UNCOMMIT events G1HR COMMIT [0x6e900000,0x6ea00000]G1HR COMMIT [0x6ea00000,0x6eb00000] Here, the heap is being initialized or expanded and the region (with bottom: 0x6eb00000 and end: 0x6ec00000) is being freshly committed. COMMIT events are always generated in order i.e. the next COMMIT event will always be for the uncommitted region with the lowest address. G1HR UNCOMMIT [0x72700000,0x72800000]G1HR UNCOMMIT [0x72600000,0x72700000] Opposite to COMMIT. The heap got shrunk at the end of a Full GC and the regions are being uncommitted. Like COMMIT, UNCOMMIT events are also generated in order i.e. the next UNCOMMIT event will always be for the committed region with the highest address. GC Cycle events G1HR #StartGC 7G1HR CSET 0x6e900000G1HR REUSE 0x70500000G1HR ALLOC(Old) 0x6f800000G1HR RETIRE 0x6f800000 0x6f821b20G1HR #EndGC 7 This shows start and end of an Evacuation pause. This event is followed by a GC counter tracking both evacuation pauses and Full GCs. Here, this is the 7th GC since the start of the process. G1HR #StartFullGC 17G1HR UNCOMMIT [0x6ed00000,0x6ee00000]G1HR POST-COMPACTION(Old) 0x6e800000 0x6e854f58G1HR #EndFullGC 17 Shows start and end of a Full GC. This event is also followed by the same GC counter as above. This is the 17th GC since the start of the process. ALLOC events G1HR ALLOC(Eden) 0x6e800000 The region with bottom 0x6e800000 just started being used for allocation. In this case it is an Eden region and allocated into by a mutator thread. G1HR ALLOC(StartsH) 0x6ec00000 0x6ed00000G1HR ALLOC(ContinuesH) 0x6ed00000 0x6e000000 Regions being used for the allocation of Humongous object. The object spans over two regions. G1HR ALLOC(SingleH) 0x6f900000 0x6f9eb010 Single region being used for the allocation of Humongous object. G1HR COMMIT [0x6ee00000,0x6ef00000]G1HR COMMIT [0x6ef00000,0x6f000000]G1HR COMMIT [0x6f000000,0x6f100000]G1HR COMMIT [0x6f100000,0x6f200000]G1HR ALLOC(StartsH) 0x6ee00000 0x6ef00000G1HR ALLOC(ContinuesH) 0x6ef00000 0x6f000000G1HR ALLOC(ContinuesH) 0x6f000000 0x6f100000G1HR ALLOC(ContinuesH) 0x6f100000 0x6f102010 Here, Humongous object allocation request could not be satisfied by the free committed regions that existed in the heap, so the heap needed to be expanded. Thus new regions are committed and then allocated into for the Humongous object. G1HR ALLOC(Old) 0x6f800000 Old region started being used for allocation during GC. G1HR ALLOC(Survivor) 0x6fa00000 Region being used for copying old objects into during a GC. Note that Eden and Humongous ALLOC events are generated outside the GC boundaries and Old and Survivor ALLOC events are generated inside the GC boundaries. Other Events G1HR RETIRE 0x6e800000 0x6e87bd98 Retire and stop using the region having bottom 0x6e800000 and top 0x6e87bd98 for allocation. Note that most regions are full when they are retired and we omit those events to reduce the output volume. A region is retired when another region of the same type is allocated or we reach the start or end of a GC(depending on the region). So for Eden regions: For example: 1. ALLOC(Eden) Foo2. ALLOC(Eden) Bar3. StartGC At point 2, Foo has just been retired and it was full. At point 3, Bar was retired and it was full. If they were not full when they were retired, we will have a RETIRE event: 1. ALLOC(Eden) Foo2. RETIRE Foo top3. ALLOC(Eden) Bar4. StartGC G1HR CSET 0x6e900000 Region (bottom: 0x6e900000) is selected for the Collection Set. The region might have been selected for the collection set earlier (i.e. when it was allocated). However, we generate the CSET events for all regions in the CSet at the start of a GC to make sure there's no confusion about which regions are part of the CSet. G1HR POST-COMPACTION(Old) 0x6e800000 0x6e839858 POST-COMPACTION event is generated for each non-empty region in the heap after a full compaction. A full compaction moves objects around, so we don't know what the resulting shape of the heap is (which regions were written to, which were emptied, etc.). To deal with this, we generate a POST-COMPACTION event for each non-empty region with its type (old/humongous) and the heap boundaries. At this point we should only have Old and Humongous regions, as we have collapsed the young generation, so we should not have eden and survivors. POST-COMPACTION events are generated within the Full GC boundary. G1HR CLEANUP 0x6f400000G1HR CLEANUP 0x6f300000G1HR CLEANUP 0x6f200000 These regions were found empty after remark phase of Concurrent Marking and are reclaimed shortly afterwards. G1HR #StartGC 5G1HR CSET 0x6f400000G1HR CSET 0x6e900000G1HR REUSE 0x6f800000 At the end of a GC we retire the old region we are allocating into. Given that its not full, we will carry on allocating into it during the next GC. This is what REUSE means. In the above case 0x6f800000 should have been the last region with an ALLOC(Old) event during the previous GC and should have been retired before the end of the previous GC. G1HR ALLOC-FORCE(Eden) 0x6f800000 A specialization of ALLOC which indicates that we have reached the max desired number of the particular region type (in this case: Eden), but we decided to allocate one more. Currently it's only used for Eden regions when we extend the young generation because we cannot do a GC as the GC-Locker is active. G1HR EVAC-FAILURE 0x6f800000 During a GC, we have failed to evacuate an object from the given region as the heap is full and there is no space left to copy the object. This event is generated within GC boundaries and exactly once for each region from which we failed to evacuate objects. When Heap Regions are reclaimed ? It is also worth mentioning when the heap regions in the G1 heap are reclaimed. All regions that are in the CSet (the ones that appear in CSET events) are reclaimed at the end of a GC. The exception to that are regions with EVAC-FAILURE events. All regions with CLEANUP events are reclaimed. After a Full GC some regions get reclaimed (the ones from which we moved the objects out). But that is not shown explicitly, instead the non-empty regions that are left in the heap are printed out with the POST-COMPACTION events.

    Read the article

  • java GC periodically enters into several full GC cycles

    - by Peter
    Environment: sun JDK 1.6.0_16 vm settings: -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -Xms1024 -Xmx1024M -XX:MaxNewSize=448m -XX:NewSize=448m -XX:SurvivorRatio=4(6 also checked) -XX:MaxPermSize=128M OS: windows server 2003 processor: 4 cores of INTEL XEON 5130, 2000 Hz my application description: high intensity of concurrent(java 5 concurrency used) operations completed each time by commit to oracle. it's about 20-30 threads run non stop, doing tasks. application runs in JBOSS web container. My GC starts work normally, I see a lot of small GCs and all that time CPU shows good load, like all 4 cores loaded to 40-50%, CPU graph is stable. Then , after 1 min of good work, CPU starts drop to 0% on 2 cores from 4, it's graph becomes unstable, goes up and down("teeth"). I see, that my threads work slower(I have monitoring), I see that GC starts produce a lot of FULL GC during that time and next 4-5 minutes this situation remains as is, then for short period of time, like 1 minute, it gets back to normal situation, but shortly after that all bad thing repeats. Question: Why I have so frequent full GC??? How to prevent that? I played with SurvivorRatio - does not help. I noticed, that application behaves normally until first FULL GC occurs, while I have enough memory. Then it runs badly. my GC LOG: starts good then long period of FULL GCs(many of them) 1027.861: [GC 942200K-623526K(991232K), 0.0887588 secs] 1029.333: [GC 803279K(991232K), 0.0927470 secs] 1030.551: [GC 967485K-625549K(991232K), 0.0823024 secs] 1030.634: [GC 625957K(991232K), 0.0763656 secs] 1033.126: [GC 969613K-632963K(991232K), 0.0850611 secs] 1033.281: [GC 649899K(991232K), 0.0378358 secs] 1035.910: [GC 813948K(991232K), 0.3540375 secs] 1037.994: [GC 967729K-637198K(991232K), 0.0826042 secs] 1038.435: [GC 710309K(991232K), 0.1370703 secs] 1039.665: [GC 980494K-972462K(991232K), 0.6398589 secs] 1040.306: [Full GC 972462K-619643K(991232K), 3.7780597 secs] 1044.093: [GC 620103K(991232K), 0.0695221 secs] 1047.870: [Full GC 991231K-626514K(991232K), 3.8732457 secs] 1053.739: [GC 942140K(991232K), 0.5410483 secs] 1056.343: [Full GC 991232K-634157K(991232K), 3.9071443 secs] 1061.257: [GC 786274K(991232K), 0.3106603 secs] 1065.229: [Full GC 991232K-641617K(991232K), 3.9565638 secs] 1071.192: [GC 945999K(991232K), 0.5401515 secs] 1073.793: [Full GC 991231K-648045K(991232K), 3.9627814 secs] 1079.754: [GC 936641K(991232K), 0.5321197 secs]

    Read the article

  • The Unspoken - The Why of GC Ergonomics

    - by jonthecollector
    Do you use GC ergonomics, -XX:+UseAdaptiveSizePolicy, with the UseParallelGC collector? The jist of GC ergonomics for that collector is that it tries to grow or shrink the heap to meet a specified goal. The goals that you can choose are maximum pause time and/or throughput. Don't get too excited there. I'm speaking about UseParallelGC (the throughput collector) so there are definite limits to what pause goals can be achieved. When you say out loud "I don't care about pause times, give me the best throughput I can get" and then say to yourself "Well, maybe 10 seconds really is too long", then think about a pause time goal. By default there is no pause time goal and the throughput goal is high (98% of the time doing application work and 2% of the time doing GC work). You can get more details on this in my very first blog. GC ergonomics The UseG1GC has its own version of GC ergonomics, but I'll be talking only about the UseParallelGC version. If you use this option and wanted to know what it (GC ergonomics) was thinking, try -XX:AdaptiveSizePolicyOutputInterval=1 This will print out information every i-th GC (above i is 1) about what the GC ergonomics to trying to do. For example, UseAdaptiveSizePolicy actions to meet *** throughput goal *** GC overhead (%) Young generation: 16.10 (attempted to grow) Tenured generation: 4.67 (attempted to grow) Tenuring threshold: (attempted to decrease to balance GC costs) = 1 GC ergonomics tries to meet (in order) Pause time goal Throughput goal Minimum footprint The first line says that it's trying to meet the throughput goal. UseAdaptiveSizePolicy actions to meet *** throughput goal *** This run has the default pause time goal (i.e., no pause time goal) so it is trying to reach a 98% throughput. The lines Young generation: 16.10 (attempted to grow) Tenured generation: 4.67 (attempted to grow) say that we're currently spending about 16% of the time doing young GC's and about 5% of the time doing full GC's. These percentages are a decaying, weighted average (earlier contributions to the average are given less weight). The source code is available as part of the OpenJDK so you can take a look at it if you want the exact definition. GC ergonomics is trying to increase the throughput by growing the heap (so says the "attempted to grow"). The last line Tenuring threshold: (attempted to decrease to balance GC costs) = 1 says that the ergonomics is trying to balance the GC times between young GC's and full GC's by decreasing the tenuring threshold. During a young collection the younger objects are copied to the survivor spaces while the older objects are copied to the tenured generation. Younger and older are defined by the tenuring threshold. If the tenuring threshold hold is 4, an object that has survived fewer than 4 young collections (and has remained in the young generation by being copied to the part of the young generation called a survivor space) it is younger and copied again to a survivor space. If it has survived 4 or more young collections, it is older and gets copied to the tenured generation. A lower tenuring threshold moves objects more eagerly to the tenured generation and, conversely a higher tenuring threshold keeps copying objects between survivor spaces longer. The tenuring threshold varies dynamically with the UseParallelGC collector. That is different than our other collectors which have a static tenuring threshold. GC ergonomics tries to balance the amount of work done by the young GC's and the full GC's by varying the tenuring threshold. Want more work done in the young GC's? Keep objects longer in the survivor spaces by increasing the tenuring threshold. This is an example of the output when GC ergonomics is trying to achieve a pause time goal UseAdaptiveSizePolicy actions to meet *** pause time goal *** GC overhead (%) Young generation: 20.74 (no change) Tenured generation: 31.70 (attempted to shrink) The pause goal was set at 50 millisecs and the last GC was 0.415: [Full GC (Ergonomics) [PSYoungGen: 2048K-0K(26624K)] [ParOldGen: 26095K-9711K(28992K)] 28143K-9711K(55616K), [Metaspace: 1719K-1719K(2473K/6528K)], 0.0758940 secs] [Times: user=0.28 sys=0.00, real=0.08 secs] The full collection took about 76 millisecs so GC ergonomics wants to shrink the tenured generation to reduce that pause time. The previous young GC was 0.346: [GC (Allocation Failure) [PSYoungGen: 26624K-2048K(26624K)] 40547K-22223K(56768K), 0.0136501 secs] [Times: user=0.06 sys=0.00, real=0.02 secs] so the pause time there was about 14 millisecs so no changes are needed. If trying to meet a pause time goal, the generations are typically shrunk. With a pause time goal in play, watch the GC overhead numbers and you will usually see the cost of setting a pause time goal (i.e., throughput goes down). If the pause goal is too low, you won't achieve your pause time goal and you will spend all your time doing GC. GC ergonomics is meant to be simple because it is meant to be used by anyone. It was not meant to be mysterious and so this output was added. If you don't like what GC ergonomics is doing, you can turn it off with -XX:-UseAdaptiveSizePolicy, but be pre-warned that you have to manage the size of the generations explicitly. If UseAdaptiveSizePolicy is turned off, the heap does not grow. The size of the heap (and the generations) at the start of execution is always the size of the heap. I don't like that and tried to fix it once (with some help from an OpenJDK contributor) but it unfortunately never made it out the door. I still have hope though. Just a side note. With the default throughput goal of 98% the heap often grows to it's maximum value and stays there. Definitely reduce the throughput goal if footprint is important. Start with -XX:GCTimeRatio=4 for a more modest throughput goal (%20 of the time spent in GC). A higher value means a smaller amount of time in GC (as the throughput goal).

    Read the article

  • Java SE 7 Update 4??????·???????G1 GC??????“WebLogic+WebSocket”??????????????????????WebLogic Server 12c Forum 2012?????

    - by ???02
    2012?4?????????Java SE 7 Update 4????????·??????(GC)????G1 GC??????????GC???????????? ???????Web??????????????????HTML5??????/???????????????????WebSocket??????????????????WebLogic Server?????????????????????????????? 2012?8????????WebLogic Server 12c Forum 2012???????????·?????????????????????????(???) Java SE 7 Update 4??????G1 GC???????? 2012?8????????WebLogic Server 12c Forum 2012??????????????????·???????????????????????Java EE 6??????????????????????????????????????WebLogic Server????????????????????·???????????????????Java SE 7 Update 4???????GC??HTML5??????1????WebSocket??????????·????????????????????? ?????? Fusion Middleware?????? ?????????????? ???? 2012?4???????Java SE 7 Update 4?????Mac OS X????????????????????????G1 GC?????????? Fusion Middleware?????? ???????????????????????G1 GC???????????????? ????????GC???????????????????????????????????????????????????????????????????????????????????????????·??????????????????????????·??????????GC????????????????1??GC???????????????????????????????? GC????????????????????????????GC??????????????????????GC????GC???????????????????????????????GC??????????????????????????????????????????????????????????????? ???64????????????????????JVM?????64????????????64????JVM????GB???????·????????????????????????GC????????????????GC????????????????????????????·????????????????GC?????????????????????????????????????????????????????????????????SLA????????????????????·?????????????? ????????????????????????Java SE 7 Update 4????????GC?G1 GC?? G1 GC????????????????????????????????????????????????????????????GC???????????????????????????(????????)??????????????????????????????????????????????????????????????????????????????????????????? ??????G1 GC??????????????????????????????????????????? ??G1 GC?????????????????????????????????????????????????????????????????????????????????????????GC?????????????????????64????JVM????????·???????????????????????????????????????GC??????? ???????????????????????? ????????????????????????????????????????????OutOfMemory???????????????????????????????? WebLogic Server 12c?Java SE 7??????????????G1 GC???????????WebLogic Server 11g(10.3.6)??????????????????????GC????????JVM??????????-XX:+UseG1 GC????????????????? HTML5?Web????/?????????WebSocket?????????????????? ?????? Fusion Middleware?????? ?????????? ?????? ?????? Fusion Middleware???????WebLogic Server??????·???????????????????????·?????????Near future of WebLogic / ????WebLogic???????????????Web??????????HTML5???? ????????IT????????????????????1???????·?????????????????????????????????????????????????????????????HTML5?? HTML5???????HTML????????????HTML???Web????????????????????????HTML5???????????????????????????????????????????????HTML5????????/???????????????????????????????????WebWorker?????????????????????????????Web Storage???????API??????HTML5??????????????HTML??????????? ???HTML5??????????????????????WebSocket????????Web????/?????????????????????????? WebSocket????????????????????????(???????)?HTTP????????????????WebSocket????????WebSocket????????????????????????HTTP????????????????????????Web????/??????????????????? WebSocket??????????“??????Web”???????????????????????????????????????????????????????????????1???????????????????????HTTP???????????????????????????????????Comet????HTTP???????????????????????????????WebSocket???????????????????????????????????????????????????????????????? ?????????WebSocket????????????????????????????????????????????????????? WebSocket???????????????????????????? ?????? WebSocket???????(RFC 6455) ?????(Proposed Standard)??? WebSocket API(JavaScript)??(W3C) ????(Last Call Working Draft)??????2012?6?14???? WebSocket API Java EE??(JSR-356) Review Ballot??? ???? Web???? Google Chrome 16?Mozilla Firefox 11?Internet Explorer 10(PP5)?Safari 6??? ???·????? Jetty?jWebSocket?node.js?GlassFish 3.x????? ????????????????(RFC 6455)?????????JavaScript??????????????????????Java EE????????JSR-356?????????????????????????·????????????????????????????·??????????????? ??????????Java???????????????GlassFish????????????????????(JSR-356)??????????????·???·???????????????? ?WebSocket?WebLogic Server ??????????????WebSocket??WebLogic Server???????????????????? WebSocket????HTML5?????????????????????????????????HTML5?????????????????????Java EE?????????HTML5????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? ???????HTML5?????????????????????????????????? ????????????? ?????????????????????????????????????????????????????????????????????????????????????????????????????HTML5???????????Java EE??????????????????????????(???) ???????????????????????????????????????????????????????????????????????????????????Java EE?WebLogic?????????????????????????????????????????????????????

    Read the article

  • What is the Difference between GC.GetTotalMemory(false) and GC.GetTotalMemory(true)

    - by somaraj
    Hi, Could some one tell me the difference between GC.GetTotalMemory(false) and GC.GetTotalMemory(true); I have a small program and when i compared the results the first loop gives an put put < loop count 0 Diff = 32 for GC.GetTotalMemory(true); and < loop count 0 Diff = 0 for GC.GetTotalMemory(false); but shouldnt it be the otherway ? Smilarly rest of the loops prints some numbers ,which are different for both case. what does this number indicate .why is it changing as the loop increase. struct Address { public string Streat; } class Details { public string Name ; public Address address = new Address(); } class emp :IDisposable { public Details objb = new Details(); bool disposed = false; #region IDisposable Members public void Dispose() { Disposing(true); } void Disposing(bool disposing) { if (!disposed) disposed = disposing; objb = null; GC.SuppressFinalize(this); } #endregion } class Program { static void Main(string[] args) { long size1 = GC.GetTotalMemory(false); emp empobj = null; for (int i = 0; i < 200;i++ ) { // using (empobj = new emp()) //------- (1) { empobj = new emp(); //------- (2) empobj.objb.Name = "ssssssssssssssssss"; empobj.objb.address.Streat = "asdfasdfasdfasdf"; } long size2 = GC.GetTotalMemory(false); Console.WriteLine( "loop count " +i + " Diff = " +(size2-size1)); } } } }

    Read the article

  • Tuning JVM (GC) for high responsive server application

    - by elgcom
    I am running an application server on Linux 64bit with 8 core CPUs and 6 GB memory. The server must be highly responsive. After some inspection I found that the application running on the server creates rather a huge amount of short-lived objects, and has only about 200~400 MB long-lived objects(as long as there is no memory leak) After reading http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html I use these JVM options -Xms2g -Xmx2g -XX:MaxPermSize=256m -XX:NewRatio=1 -XX:+UseConcMarkSweepGC Result: the minor GC takes 0.01 ~ 0.02 sec, the major GC takes 1 ~ 3 sec the minor GC happens constantly. How can I further improve or tune the JVM? larger heap size? but will it take more time for GC? larger NewSize and MaxNewSize (for young generation)? other collector? parallel GC? is it a good idea to let major GC take place more often? and how?

    Read the article

  • android app does not show up on my device or the emulator in eclipse

    - by Sam
    hey everyone, I have no errors in my app-code what so ever, but when i try to run in on either my cell or my emulator/the avd in eclipse i can't run it because it doesn't show up on either one. this is my console output: [2011-02-04 08:14:58 - Versuch] Uploading Versuch.apk onto device 'CB511L2WTB' [2011-02-04 08:14:58 - Versuch] Installing Versuch.apk... [2011-02-04 08:15:01 - Versuch] Success! [2011-02-04 08:15:01 - Versuch] \Versuch\bin\Versuch.apk installed on device [2011-02-04 08:15:01 - Versuch] Done! and this is my LogCat output, which tells me nothing, but you are the experts ;) 02-04 08:18:10.020: DEBUG/dalvikvm(22167): GC freed 2576 objects / 559120 bytes in 37ms 02-04 08:18:10.700: DEBUG/dalvikvm(6709): GC freed 7692 objects / 478912 bytes in 41ms 02-04 08:18:11.170: DEBUG/dalvikvm(31774): GC freed 3367 objects / 163464 bytes in 122ms 02-04 08:18:13.230: DEBUG/dalvikvm(22167): GC freed 2790 objects / 552328 bytes in 38ms 02-04 08:18:14.650: DEBUG/dalvikvm(6709): GC freed 8443 objects / 540440 bytes in 39ms 02-04 08:18:16.260: DEBUG/dalvikvm(31921): GC freed 214 objects / 9824 bytes in 216ms 02-04 08:18:16.670: DEBUG/dalvikvm(22167): GC freed 3232 objects / 561256 bytes in 40ms 02-04 08:18:18.600: DEBUG/dalvikvm(6709): GC freed 7718 objects / 481952 bytes in 39ms 02-04 08:18:19.210: DEBUG/dalvikvm(1129): GC freed 6898 objects / 275328 bytes in 109ms 02-04 08:18:19.690: DEBUG/dalvikvm(22167): GC freed 2968 objects / 571232 bytes in 39ms 02-04 08:18:21.440: DEBUG/dalvikvm(1212): GC freed 1020 objects / 49328 bytes in 395ms 02-04 08:18:22.570: DEBUG/dalvikvm(6709): GC freed 7893 objects / 495616 bytes in 40ms 02-04 08:18:23.060: DEBUG/dalvikvm(22167): GC freed 3117 objects / 561912 bytes in 41ms 02-04 08:18:25.860: DEBUG/dalvikvm(22167): GC freed 2924 objects / 558448 bytes in 36ms 02-04 08:18:26.350: DEBUG/dalvikvm(32098): GC freed 4662 objects / 495496 bytes in 290ms 02-04 08:18:26.410: DEBUG/dalvikvm(22167): GC freed 1077 objects / 130680 bytes in 33ms 02-04 08:18:27.080: DEBUG/dalvikvm(6709): GC freed 7912 objects / 485368 bytes in 40ms 02-04 08:18:28.190: DEBUG/dalvikvm(22167): GC freed 953 objects / 767272 bytes in 33ms 02-04 08:18:29.500: DEBUG/dalvikvm(1129): GC freed 6756 objects / 270480 bytes in 105ms 02-04 08:18:30.500: WARN/System.err(22536): java.lang.Exception: You must call com.mercuryintermedia.productconfiguration.initialize() first 02-04 08:18:30.670: WARN/System.err(22536): at com.mercuryintermedia.ProductConfiguration.getProductName(ProductConfiguration.java:136) 02-04 08:18:30.670: WARN/System.err(22536): at com.mercuryintermedia.api.rest.Item.getPublishingContainersItems(Item.java:15) 02-04 08:18:30.670: WARN/System.err(22536): at com.mercuryintermedia.mflow.ContainerHelper.getContainerFromServer(ContainerHelper.java:68) 02-04 08:18:30.670: WARN/System.err(22536): at com.mercuryintermedia.mflow.ContainerHelper.run(ContainerHelper.java:46) 02-04 08:18:31.090: DEBUG/dalvikvm(6709): GC freed 10545 objects / 682480 bytes in 49ms 02-04 08:18:31.120: DEBUG/dalvikvm(1813): GC freed 5970 objects / 310912 bytes in 60ms 02-04 08:18:31.320: DEBUG/dalvikvm(22167): GC freed 2468 objects / 539520 bytes in 39ms 02-04 08:18:34.110: DEBUG/dalvikvm(22167): GC freed 2879 objects / 569008 bytes in 35ms 02-04 08:18:34.920: DEBUG/dalvikvm(6709): GC freed 7029 objects / 424632 bytes in 35ms 02-04 08:18:36.150: DEBUG/dalvikvm(9060): GC freed 564 objects / 27840 bytes in 89ms 02-04 08:18:36.630: DEBUG/dalvikvm(22167): GC freed 2437 objects / 554000 bytes in 35ms 02-04 08:18:38.760: DEBUG/dalvikvm(6709): GC freed 8309 objects / 545032 bytes in 36ms 02-04 08:18:39.270: DEBUG/dalvikvm(1129): GC freed 6958 objects / 278352 bytes in 107ms 02-04 08:18:39.970: DEBUG/dalvikvm(22167): GC freed 2915 objects / 560312 bytes in 38ms 02-04 08:18:41.260: DEBUG/dalvikvm(6184): GC freed 373 objects / 26152 bytes in 205ms 02-04 08:18:42.780: DEBUG/dalvikvm(6709): GC freed 7212 objects / 447696 bytes in 36ms 02-04 08:18:43.160: DEBUG/dalvikvm(22167): GC freed 3106 objects / 561824 bytes in 39ms 02-04 08:18:46.310: DEBUG/dalvikvm(22167): GC freed 3110 objects / 564080 bytes in 45ms 02-04 08:18:46.650: DEBUG/dalvikvm(6709): GC freed 7508 objects / 468832 bytes in 36ms 02-04 08:18:48.820: DEBUG/dalvikvm(31712): GC freed 13795 objects / 828232 bytes in 203ms 02-04 08:18:49.040: DEBUG/dalvikvm(1129): GC freed 6918 objects / 276224 bytes in 109ms 02-04 08:18:49.640: DEBUG/dalvikvm(22167): GC freed 2952 objects / 562168 bytes in 37ms 02-04 08:18:50.630: DEBUG/dalvikvm(6709): GC freed 8332 objects / 549680 bytes in 35ms 02-04 08:18:52.770: DEBUG/dalvikvm(22167): GC freed 3108 objects / 563192 bytes in 37ms 02-04 08:18:54.400: DEBUG/dalvikvm(6709): GC freed 7509 objects / 469016 bytes in 35ms 02-04 08:18:55.900: DEBUG/dalvikvm(22167): GC freed 3121 objects / 572920 bytes in 38ms 02-04 08:18:58.150: DEBUG/dalvikvm(6709): GC freed 7408 objects / 465456 bytes in 35ms 02-04 08:18:58.710: DEBUG/dalvikvm(1129): GC freed 6908 objects / 276440 bytes in 107ms 02-04 08:18:59.190: DEBUG/dalvikvm(22167): GC freed 3160 objects / 563144 bytes in 38ms 02-04 08:19:02.080: DEBUG/dalvikvm(6709): GC freed 7436 objects / 468040 bytes in 36ms 02-04 08:19:02.380: DEBUG/dalvikvm(22167): GC freed 3104 objects / 557600 bytes in 39ms 02-04 08:19:05.050: DEBUG/dalvikvm(22167): GC freed 2860 objects / 570072 bytes in 35ms 02-04 08:19:05.810: DEBUG/dalvikvm(6709): GC freed 7508 objects / 469080 bytes in 35ms 02-04 08:19:06.500: DEBUG/skia(22167): --- decoder->decode returned false 02-04 08:19:07.960: DEBUG/dalvikvm(22167): GC freed 2747 objects / 520008 bytes in 36ms 02-04 08:19:08.180: DEBUG/dalvikvm(1129): GC freed 7866 objects / 317304 bytes in 107ms 02-04 08:19:09.540: DEBUG/dalvikvm(6709): GC freed 8220 objects / 539688 bytes in 36ms 02-04 08:19:10.810: DEBUG/dalvikvm(22167): GC freed 2898 objects / 596824 bytes in 37ms 02-04 08:19:13.360: DEBUG/dalvikvm(22167): GC freed 2503 objects / 398936 bytes in 35ms 02-04 08:19:13.370: INFO/dalvikvm-heap(22167): Grow heap (frag case) to 5.029MB for 570264-byte allocation 02-04 08:19:13.400: DEBUG/dalvikvm(22167): GC freed 702 objects / 24976 bytes in 31ms 02-04 08:19:13.400: DEBUG/skia(22167): --- decoder->decode returned false 02-04 08:19:13.540: DEBUG/dalvikvm(6709): GC freed 7481 objects / 466544 bytes in 36ms 02-04 08:19:15.600: DEBUG/WifiService(1129): got ACTION_DEVICE_IDLE 02-04 08:19:15.960: INFO/wpa_supplicant(2522): CTRL-EVENT-DRIVER-STATE STOPPED 02-04 08:19:15.960: VERBOSE/WifiMonitor(1129): Event [CTRL-EVENT-DRIVER-STATE STOPPED] 02-04 08:19:17.270: DEBUG/dalvikvm(22167): GC freed 2372 objects / 1266992 bytes in 36ms 02-04 08:19:17.520: DEBUG/dalvikvm(6709): GC freed 7996 objects / 519128 bytes in 37ms 02-04 08:19:18.150: DEBUG/dalvikvm(1129): GC freed 7110 objects / 285032 bytes in 108ms 02-04 08:19:20.460: DEBUG/dalvikvm(22167): GC freed 3327 objects / 565264 bytes in 36ms 02-04 08:19:21.250: DEBUG/dalvikvm(6709): GC freed 7632 objects / 486024 bytes in 37ms 02-04 08:19:26.470: DEBUG/dalvikvm(31774): GC freed 345 objects / 16160 bytes in 96ms 02-04 08:19:30.423: WARN/System.err(22536): java.lang.Exception: You must call com.mercuryintermedia.productconfiguration.initialize() first 02-04 08:19:30.423: WARN/System.err(22536): at com.mercuryintermedia.ProductConfiguration.getProductName(ProductConfiguration.java:136) 02-04 08:19:30.423: WARN/System.err(22536): at com.mercuryintermedia.api.rest.Item.getPublishingContainersItems(Item.java:15) 02-04 08:19:30.423: WARN/System.err(22536): at com.mercuryintermedia.mflow.ContainerHelper.getContainerFromServer(ContainerHelper.java:68) 02-04 08:19:30.423: WARN/System.err(22536): at com.mercuryintermedia.mflow.ContainerHelper.run(ContainerHelper.java:46) 02-04 08:20:05.280: DEBUG/dalvikvm(1813): GC freed 741 objects / 36840 bytes in 91ms 02-04 08:20:23.580: DEBUG/WifiService(1129): ACTION_BATTERY_CHANGED pluggedType: 2 02-04 08:20:30.423: WARN/System.err(22536): java.lang.Exception: You must call com.mercuryintermedia.productconfiguration.initialize() first 02-04 08:20:30.423: WARN/System.err(22536): at com.mercuryintermedia.ProductConfiguration.getProductName(ProductConfiguration.java:136) 02-04 08:20:30.423: WARN/System.err(22536): at com.mercuryintermedia.api.rest.Item.getPublishingContainersItems(Item.java:15) 02-04 08:20:30.423: WARN/System.err(22536): at com.mercuryintermedia.mflow.ContainerHelper.getContainerFromServer(ContainerHelper.java:68) 02-04 08:20:30.423: WARN/System.err(22536): at com.mercuryintermedia.mflow.ContainerHelper.run(ContainerHelper.java:46) 02-04 08:20:53.970: INFO/FastDormancyManager(1129): Fast Dormant executed. ExecuteCount:2683 NonExecuteCount:25773 I really hope you can help me.

    Read the article

  • GridBagConstraints problem-moved to left and size isn't the same

    - by Damir
    I have in Java two panels which need to have same layout, there is my functions for initializations panels. private void InitializePanelCom(){ pnlCom=new JPanel(); pnlCom.setSize(300,160); pnlCom.setLocation(10, 60); add(pnlCom); GridBagLayout gb=new GridBagLayout(); GridBagConstraints gc=new GridBagConstraints(); pnlCom.setLayout(gb); jLabelcommPort = setJLabel("Com Port : "); jLabelbaudRate = setJLabel("Baud Rate : "); jLabelplcAddress = setJLabel("Plc Address : "); jLabelsendTime = setJLabel("Send Time : "); jLabelx50 = setJLabel(" x 50 ms (2 - 99)"); jComboBoxcommPort = setJComboBox(commPortList); jComboBoxbaudRate = setJComboBox(bitRateList); jTextAreaPlcAddress = setJTextField(""); jTextAreaSendTime = setJTextField(""); gc.insets = new Insets(10,0,0,0); gc.ipadx = 120; gc.weightx = 1; gc.gridx = 0; gc.gridy = 0; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jLabelcommPort,gc); gc.insets = new Insets(10,0,0,0); gc.ipadx = 120; gc.weightx = 1; gc.gridx = 1; gc.gridy = 0; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jComboBoxcommPort,gc); gc.insets=new Insets(10,0,0,0); gc.ipadx=120; gc.weightx=1; gc.gridx=0; gc.gridy=1; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jLabelbaudRate,gc); gc.insets=new Insets(10,0,0,0); gc.ipadx=120; gc.weightx=1; gc.gridx=1; gc.gridy=1; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jComboBoxbaudRate,gc); gc.insets=new Insets(10,0,0,0); gc.ipadx=120; gc.weightx=1; gc.gridx=0; gc.gridy=2; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jLabelplcAddress,gc); gc.insets=new Insets(10,0,0,0); gc.ipadx=120; gc.weightx=1; gc.gridx=1; gc.gridy=2; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jTextAreaPlcAddress,gc); gc.insets=new Insets(10,0,0,0); gc.ipadx=120; gc.weightx=1; gc.gridx=0; gc.gridy=3; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jLabelsendTime,gc); gc.insets=new Insets(10,0,0,0); gc.ipadx=120; gc.weightx=1; gc.gridx=1; gc.gridy=3; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jTextAreaSendTime,gc); gc.insets=new Insets(10,0,0,0); gc.ipadx=120; gc.weightx=1; gc.gridx=2; gc.gridy=3; gc.anchor=GridBagConstraints.EAST; pnlCom.add(jLabelx50,gc); } ![alt text][1] private void InitializePanelTcp(){ pnlTcp=new JPanel(); pnlTcp.setSize(300,160); pnlTcp.setLocation(10, 60); add(pnlTcp); GridBagLayout gb=new GridBagLayout(); GridBagConstraints gc=new GridBagConstraints(); pnlTcp.setLayout(gb); lblIPAddress=setJLabel("IP Address : "); txtIPAddress=setJTextField(""); lblPort=setJLabel("Port : "); txtPort=setJTextField(""); cmbBaudRateTCP = setJComboBox(bitRateList); lblBaudRateTCP = setJLabel("Baud Rate : "); lblParityCheck=setJLabel("Parity check : "); txtParityCheck=setJTextField(""); gc.insets = new Insets(10,0,0,0); //gc.ipadx = 20; gc.weightx = 0.3; gc.gridx = 0; gc.gridy = 0; gc.anchor=GridBagConstraints.WEST; pnlTcp.add(lblIPAddress,gc); gc.insets = new Insets(10,0,0,0); //gc.ipadx = 80; gc.weightx = 0.7; gc.gridx = 1; gc.gridy = 0; gc.anchor=GridBagConstraints.WEST; pnlTcp.add(txtIPAddress,gc); gc.insets=new Insets(10,0,0,0); //gc.ipadx=120; gc.weightx=0.3; gc.gridx=0; gc.gridy=1; gc.anchor=GridBagConstraints.WEST; pnlTcp.add(lblPort,gc); gc.insets=new Insets(10,0,0,0); //gc.ipadx=80; gc.weightx=0.7; gc.gridx=1; gc.gridy=1; gc.anchor=GridBagConstraints.WEST; pnlTcp.add(txtPort,gc); gc.insets=new Insets(10,0,0,0); //gc.ipadx=120; gc.weightx=0.3; gc.gridx=0; gc.gridy=2; gc.anchor=GridBagConstraints.WEST; pnlTcp.add(lblBaudRateTCP,gc); gc.insets=new Insets(10,0,0,0); //gc.ipadx=0; gc.weightx=0.7; gc.gridx=1; gc.gridy=2; gc.anchor=GridBagConstraints.WEST; pnlTcp.add(cmbBaudRateTCP,gc); gc.insets=new Insets(10,0,0,0); //gc.ipadx=120; gc.weightx=0.3; gc.gridx=0; gc.gridy=3; gc.anchor=GridBagConstraints.WEST; pnlTcp.add(lblParityCheck,gc); gc.insets=new Insets(10,0,0,0); //gc.ipadx=0; gc.weightx=1.7; gc.gridx=1; gc.gridy=3; gc.anchor=GridBagConstraints.WEST; pnlTcp.add(txtParityCheck,gc); } Problem is that second panel (initializetcp, second picture doesn't look the same, labels are moved at left , it is different ). Can anybody help, I am new with GridBagContsraints at all ?

    Read the article

  • UseConcMarkSweepGC verbose gc output shows memory drops

    - by user1864747
    I have an application for which I have enabled GC logging. The heap appears to grow then takes a sudden drop, but does not log a Full GC. If there some startup parameter that I can enable that will show me what GC event is reducing the heap size? My environment: Linux 64-Bit, java 1.6.0_31, Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) VM args: -server -Xms2560m -Xmx2560m -XX:+UseConcMarkSweepGC -XX:MaxPermSize=256m -XX:-PrintGC -XX: -PrintGCDetails -XX:-PrintGCTimeStamps -Xloggc:/xxxxx/gc.log -Dsun.rmi.dgc.client.gcInterval=86400000 -Dsun.rmi.dgc.server.gcInterval=86400000 3057.609: [GC 2397254K->2385777K(2619328K), 0.0572310 secs] 3058.898: [GC 2402801K->2391301K(2619328K), 0.0566620 secs] 3059.940: [GC 2408325K->2397156K(2619328K), 0.0534080 secs] 3059.995: [GC 2397265K(2619328K), 0.0069950 secs] 3065.635: [GC 2414180K->2404934K(2619328K), 0.0732700 secs] 3065.849: [GC 2419994K(2619328K), 0.1150630 secs] 3070.248: [GC 1593931K->1591825K(2619328K), 0.1084230 secs] 3072.440: [GC 1608552K->1606431K(2619328K), 0.0533140 secs] 3087.759: [GC 1623455K->1614544K(2619328K), 0.0215850 secs] What event is causing the heap to shrink between the output at 3065.849 and 3070.248? Is there a VM param that will log it? I tried adding -verbose:gc but that does not change the output.

    Read the article

  • What could be the reason for continuous Full GC's during application startup.

    - by Kumar225
    What could be the reason for continuous Full GC's during application (webapplication deployed on tomcat) startup? JDK 1.6 Memory settings -Xms1024M -Xmx1024M -XX:PermSize=200M -XX:MaxPermSize=512M -XX:+UseParallelOldGC jmap output is below Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 1073741824 (1024.0MB) NewSize = 2686976 (2.5625MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio = 8 PermSize = 209715200 (200.0MB) MaxPermSize = 536870912 (512.0MB) 0.194: [GC [PSYoungGen: 10489K->720K(305856K)] 10489K->720K(1004928K), 0.0061190 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 0.200: [Full GC (System) [PSYoungGen: 720K->0K(305856K)] [ParOldGen: 0K->594K(699072K)] 720K->594K(1004928K) [PSPermGen: 6645K->6641K(204800K)], 0.0516540 secs] [Times: user=0.10 sys=0.00, real=0.06 secs] 6.184: [GC [PSYoungGen: 262208K->14797K(305856K)] 262802K->15392K(1004928K), 0.0354510 secs] [Times: user=0.18 sys=0.04, real=0.03 secs] 9.549: [GC [PSYoungGen: 277005K->43625K(305856K)] 277600K->60736K(1004928K), 0.0781960 secs] [Times: user=0.56 sys=0.07, real=0.08 secs] 11.768: [GC [PSYoungGen: 305833K->43645K(305856K)] 322944K->67436K(1004928K), 0.0584750 secs] [Times: user=0.40 sys=0.05, real=0.06 secs] 15.037: [GC [PSYoungGen: 305853K->43619K(305856K)] 329644K->72932K(1004928K), 0.0688340 secs] [Times: user=0.42 sys=0.01, real=0.07 secs] 19.372: [GC [PSYoungGen: 273171K->43621K(305856K)] 302483K->76957K(1004928K), 0.0573890 secs] [Times: user=0.41 sys=0.01, real=0.06 secs] 19.430: [Full GC (System) [PSYoungGen: 43621K->0K(305856K)] [ParOldGen: 33336K->54668K(699072K)] 76957K->54668K(1004928K) [PSPermGen: 36356K->36296K(204800K)], 0.4569500 secs] [Times: user=1.77 sys=0.02, real=0.46 secs] 19.924: [GC [PSYoungGen: 4280K->128K(305856K)] 58949K->54796K(1004928K), 0.0041070 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 19.928: [Full GC (System) [PSYoungGen: 128K->0K(305856K)] [ParOldGen: 54668K->54532K(699072K)] 54796K->54532K(1004928K) [PSPermGen: 36300K->36300K(204800K)], 0.3531480 secs] [Times: user=1.19 sys=0.10, real=0.35 secs] 20.284: [GC [PSYoungGen: 4280K->64K(305856K)] 58813K->54596K(1004928K), 0.0040580 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 20.288: [Full GC (System) [PSYoungGen: 64K->0K(305856K)] [ParOldGen: 54532K->54532K(699072K)] 54596K->54532K(1004928K) [PSPermGen: 36300K->36300K(204800K)], 0.2360580 secs] [Times: user=1.01 sys=0.01, real=0.24 secs] 20.525: [GC [PSYoungGen: 4280K->96K(305856K)] 58813K->54628K(1004928K), 0.0030960 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 20.528: [Full GC (System) [PSYoungGen: 96K->0K(305856K)] [ParOldGen: 54532K->54533K(699072K)] 54628K->54533K(1004928K) [PSPermGen: 36300K->36300K(204800K)], 0.2311320 secs] [Times: user=0.88 sys=0.00, real=0.23 secs] 20.760: [GC [PSYoungGen: 4280K->96K(305856K)] 58814K->54629K(1004928K), 0.0034940 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 20.764: [Full GC (System) [PSYoungGen: 96K->0K(305856K)] [ParOldGen: 54533K->54533K(699072K)] 54629K->54533K(1004928K) [PSPermGen: 36300K->36300K(204800K)], 0.2381600 secs] [Times: user=0.85 sys=0.01, real=0.24 secs] 21.201: [GC [PSYoungGen: 5160K->354K(305856K)] 59694K->54888K(1004928K), 0.0019950 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 21.204: [Full GC (System) [PSYoungGen: 354K->0K(305856K)] [ParOldGen: 54533K->54792K(699072K)] 54888K->54792K(1004928K) [PSPermGen: 36300K->36300K(204800K)], 0.2358570 secs] [Times: user=0.98 sys=0.01, real=0.24 secs] 21.442: [GC [PSYoungGen: 4280K->64K(305856K)] 59073K->54856K(1004928K), 0.0022190 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 21.444: [Full GC (System) [PSYoungGen: 64K->0K(305856K)] [ParOldGen: 54792K->54792K(699072K)] 54856K->54792K(1004928K) [PSPermGen: 36300K->36300K(204800K)], 0.2475970 secs] [Times: user=0.95 sys=0.00, real=0.24 secs] 21.773: [GC [PSYoungGen: 11200K->741K(305856K)] 65993K->55534K(1004928K), 0.0030230 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 21.776: [Full GC (System) [PSYoungGen: 741K->0K(305856K)] [ParOldGen: 54792K->54376K(699072K)] 55534K->54376K(1004928K) [PSPermGen: 36538K->36537K(204800K)], 0.2550630 secs] [Times: user=1.05 sys=0.00, real=0.25 secs] 22.033: [GC [PSYoungGen: 4280K->96K(305856K)] 58657K->54472K(1004928K), 0.0032130 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 22.036: [Full GC (System) [PSYoungGen: 96K->0K(305856K)] [ParOldGen: 54376K->54376K(699072K)] 54472K->54376K(1004928K) [PSPermGen: 36537K->36537K(204800K)], 0.2507170 secs] [Times: user=1.01 sys=0.01, real=0.25 secs] 22.289: [GC [PSYoungGen: 4280K->96K(305856K)] 58657K->54472K(1004928K), 0.0038060 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 22.293: [Full GC (System) [PSYoungGen: 96K->0K(305856K)] [ParOldGen: 54376K->54376K(699072K)] 54472K->54376K(1004928K) [PSPermGen: 36537K->36537K(204800K)], 0.2640250 secs] [Times: user=1.07 sys=0.02, real=0.27 secs] 22.560: [GC [PSYoungGen: 4280K->128K(305856K)] 58657K->54504K(1004928K), 0.0036890 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 22.564: [Full GC (System) [PSYoungGen: 128K->0K(305856K)] [ParOldGen: 54376K->54377K(699072K)] 54504K->54377K(1004928K) [PSPermGen: 36537K->36536K(204800K)], 0.2585560 secs] [Times: user=1.08 sys=0.01, real=0.25 secs] 22.823: [GC [PSYoungGen: 4533K->96K(305856K)] 58910K->54473K(1004928K), 0.0020840 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 22.825: [Full GC (System) [PSYoungGen: 96K->0K(305856K)] [ParOldGen: 54377K->54377K(699072K)] 54473K->54377K(1004928K) [PSPermGen: 36536K->36536K(204800K)], 0.2505380 secs] [Times: user=0.99 sys=0.01, real=0.25 secs] 23.077: [GC [PSYoungGen: 4530K->32K(305856K)] 58908K->54409K(1004928K), 0.0016220 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 23.079: [Full GC (System) [PSYoungGen: 32K->0K(305856K)] [ParOldGen: 54377K->54378K(699072K)] 54409K->54378K(1004928K) [PSPermGen: 36536K->36536K(204800K)], 0.2320970 secs] [Times: user=0.95 sys=0.00, real=0.23 secs] 24.424: [GC [PSYoungGen: 87133K->800K(305856K)] 141512K->55179K(1004928K), 0.0038230 secs] [Times: user=0.01 sys=0.01, real=0.01 secs] 24.428: [Full GC (System) [PSYoungGen: 800K->0K(305856K)] [ParOldGen: 54378K->54950K(699072K)] 55179K->54950K(1004928K) [PSPermGen: 37714K->37712K(204800K)], 0.4105190 secs] [Times: user=1.25 sys=0.17, real=0.41 secs] 24.866: [GC [PSYoungGen: 4280K->256K(305856K)] 59231K->55206K(1004928K), 0.0041370 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 24.870: [Full GC (System) [PSYoungGen: 256K->0K(305856K)] [ParOldGen: 54950K->54789K(699072K)] 55206K->54789K(1004928K) [PSPermGen: 37720K->37719K(204800K)], 0.4160520 secs] [Times: user=1.12 sys=0.19, real=0.42 secs] 29.041: [GC [PSYoungGen: 262208K->12901K(275136K)] 316997K->67691K(974208K), 0.0170890 secs] [Times: user=0.11 sys=0.00, real=0.02 secs]

    Read the article

  • Anything wrong with spamming GC.KeepAlive(KeyboardHookPointer)?

    - by Alex
    GC.KeepAlive() References the specified object, which makes it ineligible for garbage collection from the start of the current routine to the point where this method is called. Not really sure about what GC.KeepAlive does other than simply store a reference so the Garbage Collector doesn't collect the object. But does calling GC.KeepAlive() on an object permanently keep an object from being collected? Or do you have to re-call GC.KeepAlive() every so often (and if so, how often)? I want to keep my keyboard hook alive.

    Read the article

  • Duration of Excessive GC Time in "java.lang.OutOfMemoryError: GC overhead limit exceeded"

    - by jilles de wit
    Occasionally, somewhere between once every 2 days to once every 2 weeks, my application crashes in a seemingly random location in the code with: java.lang.OutOfMemoryError: GC overhead limit exceeded. If I google this error I come to this SO question and that lead me to this piece of sun documentation which expains: The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line. Which tells me that my application is apparently spending 98% of the total time in garbage collection to recover only 2% of the heap. But 98% of what time? 98% of the entire two weeks the application has been running? 98% of the last millisecond? I'm trying to determine a best approach to actually solving this issue rather than just using -XX:-UseGCOverheadLimit but I feel a need to better understand the issue I'm solving.

    Read the article

  • Forcing the GC to collect JNI proxy objects

    - by SyBer
    Hi. While I do my best to clean JNI objects to free native memory in the end of the usage, there are still some that hang around for a long time, wasting system native memory. Is there any way to force the GC to give priority in collection of these JNI proxies? I mean is there a way to cause GC to concentrate on a particular kind of object, namely the JNI proxies? Thanks.

    Read the article

  • On configuring GC 10.2.0.5 to monitor LISTENER SCAN using UDMs ...

    - by [email protected]
    Hi,Looks like Grid Control 10.2.0.5 is not fully prepared for monitoringthe Grid Infrastructure (11gR2).Even I'm pretty sure the upcoming version of GC (11g) will of course support all the new features of 11gR2, some customersare asking for some "hand-made" procedures for monitoring all the new stuff.I think one of the most critical components that cant be monitored are the LISTENER SCAN, so I have developed a little script for doing sousing the GC User Defined Metrics ( at host level )I am more than happy to share with you:#!/bin/ksh   ###    NAME###     monitor_scan.sh######    DESCRIPTION###      SCAN Listener monitoring######    RETURNS######    NOTES######    MODIFIED           (DD/MM/YY)###      Oracle            25/03/10     - Creation###export ORACLE_HOME=/opt/oracle/soft/11.2/gridRSC_KEY=$1AWK=/sbin/awk   LISTENER_DOWN_COUNT=$(${ORACLE_HOME}/bin/crsctl status resource -w 'TYPE = ora.scan_listener.type' | grep OFFLINE | wc -l)if [ ${LISTENER_DOWN_COUNT} != 0 ]; then  SCAN_DOWN_LIST=$(${ORACLE_HOME}/bin/crsctl status resource  -w 'TYPE = ora.scan_listener.type' | $AWK \ 'BEGIN { FS="="; state = 0; }  $1~/NAME/ && $2~/'$RSC_KEY'/ {appname = $2; state=1};  state == 0 {next;}  $1~/TARGET/ && state == 1 {apptarget = $2; state=2;}  $1~/STATE/ && state == 2 {appstate = $2; state=3;}  state == 3 {printf "%-45s %-10s %-18s\n", appname, apptarget, appstate; state=0;}' | grep OFFLINE | awk '{ print $1 }')  echo em_result=ALERT  echo em_message=There are LISTENER SCAN with down status: [${SCAN_DOWN_LIST}]else  echo em_result=NORMAL  echo em_message=All SCAN Listener are UPfiHope it helpsL

    Read the article

  • JVM throws OutOfMemory during gc though there are plenty memory left...

    - by Shu L.
    I have my java application configured to use 5G memory. I got an OutOfMemory out of blue. I inspected the gc log and found plenty of memory left: young generation occupies 4% allocated space, tenure generation occupancy is 5% and perm generation is 43%. I am puzzled why JVM throws an OutOfMemory at the gc time. Does anyone know why this is happening? Your help is greatly appreciated. JVM memory and gc settings: -server -Xms5g -Xmx5g -Xss256k -XX:NewSize=2g -XX:MaxNewSize=2g -XX:+UseParallelOldGC -XX:+UseTLAB -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:+DisableExplicitGC gc.log 2009-09-19T03:34:59.741+0000: 92836.778: [GC Desired survivor size 152567808 bytes, new threshold 1 (max 15) [PSYoungGen: 1941492K-144057K(1947072K)] 3138022K-1340830K(5092800K), 0.1947640 secs] [Times: user=0.61 sys=0.01, real=0.19 secs] 2009-09-19T03:35:29.918+0000: 92866.954: [GC Desired survivor size 152109056 bytes, new threshold 1 (max 15) [PSYoungGen: 1941625K-144049K(1948608K)] 3138398K-1341080K(5094336K), 0.1942000 secs] [Times: user=0.61 sys=0.01, real=0.20 secs] 2009-09-19T03:35:56.883+0000: 92893.920: [GC Desired survivor size 156565504 bytes, new threshold 1 (max 15) [PSYoungGen: 1567994K-115427K(1915072K)] 2765026K-1312820K(5060800K), 0.1586320 secs] [Times: user=0.50 sys=0.01, real=0.16 secs] 2009-09-19T03:35:57.042+0000: 92894.079: [GC Desired survivor size 179961856 bytes, new threshold 1 (max 15) [PSYoungGen: 115427K-0K(1898560K)] 1312820K-1313987K(5044288K), 0.0775650 secs] [Times: user=0.42 sys=0.19, real=0.08 secs] 2009-09-19T03:35:57.120+0000: 92894.157: [Full GC [PSYoungGen: 0K-0K(1898560K)] [ParOldGen: 1313987K-159522K(3145728K)] 1313987K-159522K(5044288K) [PSPermGen: 20025K-19942K(40256K)], 0.56923 00 secs] [Times: user=2.18 sys=0.05, real=0.57 secs] 2009-09-19T03:35:57.690+0000: 92894.726: [GC Desired survivor size 197066752 bytes, new threshold 1 (max 15) [PSYoungGen: 0K-0K(1745728K)] 159522K-159522K(4891456K), 0.0072590 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 2009-09-19T03:35:57.698+0000: 92894.734: [Full GC [PSYoungGen: 0K-0K(1745728K)] [ParOldGen: 159522K-158627K(3145728K)] 159522K-158627K(4891456K) [PSPermGen: 19942K-19934K(45504K)], 0.3280480 secs] [Times: user=1.46 sys=0.00, real=0.33 secs] Heap PSYoungGen total 1745728K, used 87233K [0x00002aab73650000, 0x00002aabf3650000, 0x00002aabf3650000) eden space 1745664K, 4% used [0x00002aab73650000,0x00002aab78b80778,0x00002aabddf10000) from space 64K, 0% used [0x00002aabddf10000,0x00002aabddf10000,0x00002aabddf20000) to space 192448K, 0% used [0x00002aabe7a60000,0x00002aabe7a60000,0x00002aabf3650000) ParOldGen total 3145728K, used 158627K [0x00002aaab3650000, 0x00002aab73650000, 0x00002aab73650000) object space 3145728K, 5% used [0x00002aaab3650000,0x00002aaabd138d28,0x00002aab73650000) PSPermGen total 45504K, used 19965K [0x00002aaaae250000, 0x00002aaab0ec0000, 0x00002aaab3650000) object space 45504K, 43% used [0x00002aaaae250000,0x00002aaaaf5cf668,0x00002aaab0ec0000) I am on 64-bit Linux and JRE 1.6.0_10: $uname -a Linux x 2.6.24-etchnhalf.1-amd64 #1 SMP Tue Oct 14 03:11:45 UTC 2008 x86_64 GNU/Linux $java -version java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode)

    Read the article

  • GC.AddMemoryPressure

    - by Steve Sheldon
    I am writing an application in C# that makes use of a 3rd party COM DLL, this dll creates a lot of resources (like bitmaps, video, data structures) in unmanaged memory. While digging around I came across the following call for the Garbage Collector: GC.AddMemoryPressure(long long bytesAllocated) It is documented in MSDN here: http://msdn.microsoft.com/en-us/library/system.gc.addmemorypressure.aspx This sounds like something I should be calling since this external dll is createing a lot of resources the CLR is unaware of. I guess I have two questions... How do I know how much memory pressure to add when the dll is 3rd party and it's not possible for me to know exactly how much memory this dll is allocating. How important is it to do this?

    Read the article

  • GC.AddMemoryPressure in C#

    - by ssheldon
    I am writing an application in C# that makes use of a 3rd party COM DLL, this dll creates a lot of resources (like bitmaps, video, data structures) in unmanaged memory. While digging around I came across the following call for the Garbage Collector: GC.AddMemoryPressure(long long bytesAllocated) It is documented in MSDN here: http://msdn.microsoft.com/en-us/library/system.gc.addmemorypressure.aspx This sounds like something I should be calling since this external dll is createing a lot of resources the CLR is unaware of. I guess I have two questions... How do I know how much memory pressure to add when the dll is 3rd party and it's not possible for me to know exactly how much memory this dll is allocating. How important is it to do this?

    Read the article

  • lua userdata gc

    - by anon
    Is it possible for a piece of lua user data to hold reference to a lua object? (Like a table, or another piece of user data?). Basically, what I want to know is: Can I create a piece of userdata in such a way taht when the gc runs, the user data can say: "Hey! I'm holding references to these other objects, mark them as well." Thanks!

    Read the article

  • How to reduce java concurrent mode failure and excessive gc

    - by jimx
    In Java, the concurrent mode failure means that the concurrent collector failed to free up enough memory space form tenured and permanent gen and has to give up and let the full stop-the-world gc kicks in. The end result could be very expensive. I understand this concept but never had a good comprehensive understanding of A) what could cause a concurrent mode failure and B) what's the solution?. This sort of unclearness leads me to write/debug code without much of hints in mind and often has to shop around those performance flags from Foo to Bar without particular reasons, just have to try. I'd like to learn from developers here how your experience is. If you had previous encountered such performance issue, what was the cause and how you addressed it? If you have coding recommendations, please don't be too general. Thanks!

    Read the article

  • Counting number of GC cleanups on an object

    - by tsps
    How do I keep a count of the number of times that objects of a specific class (type?) are getting disposed in the lifetime of my application. Imagine I have a class A, now, I want to count how many times the objects of A get collected by the GC. I hope I am phrasing this right because I was asked this in an interview today and the answer I gave did not satisfy the interviewer. And this is what I imagine he was trying to ask. What I said was that one could keep a static field called count in the class A and increment it in the Finalize() call of that object. The answer he was expecting was something called a static block. I've never heard of this in .NET/C#. Can someone explain what's this static block?

    Read the article

  • Are C or C++ The Only Viable Languages for a GC

    - by user95312
    Background I have just finished writing a compiler for a functional language compiling to the JVM as a learning project. However, since I'm just doing this to learn, I thought it might be interesting to write a native backend and a RTS for it. As I've been planning out what this new backend will look like, the one point I'm stumbling on is the garbage collector. I've implemented the compiler in Haskell. But I have no desire to write the GC in Haskell since, while it may be possible, it'd suck. Question I've looked at several FOSS garbage collectors prior to posting and most of them were implemented in good old ANSI C. Is this still the most accepted choice for writing a GC nowadays? I've seen that this site tends to frown upon questions with multiple answers so I hope this will make it more specific: If some startup was writing a professional grade gc today, are the only viable choice for them C or C++? It's my first question here so please comment and let me know if this question is ill-suited for for programmers.

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >