tag:blogger.com,1999:blog-7735872642513631302.comments2023-07-15T17:54:51.492+01:00Alexey RagozinAlexey Ragozinhttp://www.blogger.com/profile/13720493857045012756noreply@blogger.comBlogger335125tag:blogger.com,1999:blog-7735872642513631302.post-82705707767156375312023-07-15T17:54:51.492+01:002023-07-15T17:54:51.492+01:00Fast version neither computes retained size, nor s...Fast version neither computes retained size, nor supports backward reference traversing. It is using very compact in-memory index and doesn't create on disk index files. Usually I use domain specific traversing rules so forward only traversing is sufficient for my purposes. Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-64998453593537473312023-07-14T13:12:55.643+01:002023-07-14T13:12:55.643+01:00Does the fast version compute retainedSize? Can yo...Does the fast version compute retainedSize? Can you share how does it compute the dominator tree (and retained size)? Doesn't look like it is using Tarjan's and co's sdom() approach and doing so via brute force approach will take ages. HVnoreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-61048586588488045582023-06-22T23:57:33.205+01:002023-06-22T23:57:33.205+01:00If summary means class histogram, 12 hours is outr...If summary means class histogram, 12 hours is outrageous. I'm not running my code with non "fast" version of heap parser though, so I'm have missed some performance issue. I suggest<br />1. Try fast heap version<br />2. Use profiler to pin point how code during processing history.<br />I do not have any good large heap dump files at the moment to verify issue, so your feedback is much appreciated.Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-15746815246581755242023-06-20T12:31:29.595+01:002023-06-20T12:31:29.595+01:00Tried opening a 20GB hprof using original nb code ...Tried opening a 20GB hprof using original nb code (https://github.com/aragozin/heaplib/tree/master/hprof-heap/src/main/java/org/netbeans/lib/profiler/heap) (not the fast version you had added), and good lord, it took 12 hours to parse it! It had created a ~20GB map file within 2 minutes though, but took 12 hours just to print summary of the heap. <br /><br />Am I missing anything, or Is that the expected speed of the vanilla version?HVnoreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-26609649346992377642022-12-02T02:24:09.789+00:002022-12-02T02:24:09.789+00:00so clear.thanks
so clear.thanks<br />vellai varananhttps://www.blogger.com/profile/09831570147065929187noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-52412143138184121852021-11-12T12:27:48.486+00:002021-11-12T12:27:48.486+00:00You can reach me via alexey.ragozin@gmail.com, blo...You can reach me via alexey.ragozin@gmail.com, blog comments is not good media for conversation. Also important point if you JDK is HotSpot based or J9 based. I have little experience with J9. Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-78353553448619569902021-11-12T09:20:55.096+00:002021-11-12T09:20:55.096+00:00Привет. Это Сергей С. (помнишь DOMS?) Интересный у...Привет. Это Сергей С. (помнишь DOMS?) Интересный у тебя блог, даже в поисковиках светится.<br />Есть проблема. У нас GC тратит порядка 80 секунд на выгрузку 460 тыс анонимных классов (в нагрузке это происходит примерно раз в 40 мин, а в проме пореже, пока даже не каждый день, размер кучи 8 Гб). В Java 8 этот шаг выполняется синхронно, т.е. с остановкой приложения. Оракл рекламирует ZGC в Java 11, но он даже там экспериментальный, а у нас даже не оракловая JVM, а от айбиэма. А для Java 8 знаешь какой-нибудь способ решить это? Я обратил внимание, что выгрузка классов требует примерно квадратичного времени от их количества, т.е. perm region как был помойкой с линейным поиском 15 лет назад, так, видимо, и сейчас остался. Очевидный шаг - уменьшить -Xmx, тогда major GC будет выполняться чаще и примерно квадратично быстрее. Но нужно решение, которое может работать на больших кучах и без апгрейда джавы.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-54743553836881906742021-09-16T05:55:34.982+01:002021-09-16T05:55:34.982+01:00FixedFixedAlexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-71302670036072866792021-09-15T19:14:18.250+01:002021-09-15T19:14:18.250+01:00Github link 404?Github link 404?Roger Packhttps://www.blogger.com/profile/01578246846716577925noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-87286123707922736412020-08-16T09:15:10.373+01:002020-08-16T09:15:10.373+01:00thank you ! Looking forward for Hotspot JVM GC opt...thank you ! Looking forward for Hotspot JVM GC options cheat sheet for Java 11heylichenhttps://www.blogger.com/profile/17099007555185938433noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-6030411845065656802020-05-03T08:37:09.899+01:002020-05-03T08:37:09.899+01:00GoodGoodAnonymoushttps://www.blogger.com/profile/00759469385272269997noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-22805800330698437902020-01-23T15:33:47.740+00:002020-01-23T15:33:47.740+00:00async-profiler is supposed to work around the Asyn...async-profiler is supposed to work around the AsyncGetCallTrace dropped samples issues<br />https://github.com/jvm-profiling-tools/async-profilerDanhttps://www.blogger.com/profile/15443470427462853268noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-14908865519322325882019-11-22T11:56:55.978+00:002019-11-22T11:56:55.978+00:00Good questions. I do not know exact answer. Some i...Good questions. I do not know exact answer. Some implementations are using bitmap for that purpose.<br />Though, I think bit manipulation would require more instructions for write barrier. In addition, I believe extra values of byte may be used during CMS concurrent preclean phase.Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-41794750385983694152019-11-22T08:01:43.552+00:002019-11-22T08:01:43.552+00:00Great article! I have a question. If card table is...Great article! I have a question. If card table is just used to mark a 512Bytes page is dirty or clean, a bit is enough, why a byte is needed?Anonymoushttps://www.blogger.com/profile/04816447360335350748noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-41182674889560163462019-04-10T09:53:01.748+01:002019-04-10T09:53:01.748+01:00I love you Mr. Ragozin. And I apologize for my exa...I love you Mr. Ragozin. And I apologize for my exaggerations and many other transgressions... Nice post :-)Nitsanhttps://www.blogger.com/profile/10496299147100350513noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-74196733143422774592019-03-23T05:02:32.516+00:002019-03-23T05:02:32.516+00:00JFR suspends thread (SuspendThread), then I uses O...JFR suspends thread (SuspendThread), then I uses OS API (GetThreadContext) to read registers and thus get a pointer to stack for the target thread. As thread is suspended during inspection it is safe to parse stack and virtual frame related data structures. Once inspection is complete, thread is resumed. Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-10088185206898725462019-03-22T20:41:01.395+00:002019-03-22T20:41:01.395+00:00Alexey,
Do you know what mechanism JFR uses on Win...Alexey,<br />Do you know what mechanism JFR uses on Windows platform to perform out-of-safepoint stack sampling? I think it is the only platform without SIGPROF, so I'm wondering what the mechanics are..<br />Taras Tielkeshttps://www.blogger.com/profile/05344242807993465842noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-57255197405525220212018-11-29T05:48:37.034+00:002018-11-29T05:48:37.034+00:00In your case Full GC is triggered by code (calling...In your case Full GC is triggered by code (calling System.gc() or similar API) as indicated by "System" reason. Seek for some problematic code abusing this call.Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-9718041356792384462018-11-29T03:46:04.923+00:002018-11-29T03:46:04.923+00:00Hi,
I need your help, we are seeing FULL GC cyc...Hi,<br /> I need your help, we are seeing FULL GC cycles.<br />2018-11-14T03:04:33.697-0500: 19.418: [GC 19.418: [ParNew: 748992K->28537K(811392K), 0.0567463 secs] 748992K->28537K(2559040K), 0.0569589 secs] [Times: user=0.35 sys=0.07, real=0.06 secs] <br />2018-11-14T03:05:00.090-0500: 45.810: [GC 45.810: [ParNew: 777529K->55659K(811392K), 0.0234679 secs] 777529K->55659K(2559040K), 0.0236537 secs] [Times: user=0.33 sys=0.03, real=0.02 secs] <br />2018-11-14T03:06:09.190-0500: 114.907: [GC 114.907: [ParNew: 804651K->42530K(811392K), 0.2476194 secs] 804651K->73544K(2559040K), 0.2479438 secs] [Times: user=1.22 sys=0.16, real=0.25 secs] <br />2018-11-14T03:06:13.450-0500: 119.166: [GC 119.167: [ParNew: 791522K->62400K(811392K), 0.4114889 secs] 822536K->304066K(2559040K), 0.4118205 secs] [Times: user=3.65 sys=0.16, real=0.41 secs] <br />2018-11-14T03:06:16.406-0500: 122.122: [GC 122.122: [ParNew: 811392K->54186K(811392K), 0.1041361 secs] 1053058K->358056K(2559040K), 0.1043932 secs] [Times: user=0.79 sys=0.05, real=0.10 secs] <br />2018-11-14T03:06:20.312-0500: 126.028: [GC 126.028: [ParNew: 803178K->27168K(811392K), 0.0128048 secs] 1107048K->331038K(2559040K), 0.0131012 secs] [Times: user=0.22 sys=0.01, real=0.01 secs] <br />2018-11-14T03:07:08.256-0500: 173.970: [GC 173.970: [ParNew: 776160K->51133K(811392K), 0.0726371 secs] 1080030K->355003K(2559040K), 0.0729020 secs] [Times: user=0.74 sys=0.01, real=0.07 secs] <br />2018-11-14T03:07:56.471-0500: 222.182: [GC 222.182: [ParNew: 800125K->45388K(811392K), 0.0387463 secs] 1103995K->365938K(2559040K), 0.0390502 secs] [Times: user=0.38 sys=0.01, real=0.04 secs] <br />2018-11-14T03:08:26.790-0500: 252.500: [Full GC (System) 252.500: [CMS: 320550K->233828K(1747648K), 2.3783255 secs] 1103625K->233828K(2559040K), [CMS Perm : 45043K->43742K(131072K)], 2.3786359 secs] [Times: user=2.36 sys=0.03, real=2.38 secs] <br />2018-11-14T03:08:58.467-0500: 284.176: [Full GC (System) 284.176: [CMS: 233828K->237278K(1747648K), 2.1129675 secs] 864165K->237278K(2559040K), [CMS Perm : 43917K->43828K(131072K)], 2.1132476 secs] [Times: user=2.12 sys=0.00, real=2.11 secs] <br />2018-11-14T03:09:30.706-0500: 316.413: [Full GC (System) 316.414: [CMS: 237278K->236191K(1747648K), 2.0984427 secs] 868179K->236191K(2559040K), [CMS Perm : 43920K->43866K(131072K)], 2.0987244 secs] [Times: user=2.46 sys=0.00, real=2.10 secs] <br />2018-11-14T03:10:02.311-0500: 348.016: [Full GC (System) 348.017: [CMS: 236191K->239342K(1747648K), 2.0877004 secs] 775331K->239342K(2559040K), [CMS Perm : 44042K->43927K(131072K)], 2.0879694 secs] [Times: user=2.09 sys=0.01, real=2.09 secs] <br />2018-11-14T03:10:34.245-0500: 379.949: [Full GC (System) 379.950: [CMS: 239342K->240377K(1747648K), 2.1087463 secs] 825427K->240377K(2559040K), [CMS Perm : 44014K->43954K(131072K)], 2.1090241 secs] [Times: user=2.11 sys=0.01, real=2.11 secs] <br />2018-11-14T03:11:05.890-0500: 411.593: [Full GC (System) 411.593: [CMS: 240377K->243060K(1747648K), 2.1120022 secs] 793646K->243060K(2559040K), [CMS Perm : 44124K->44062K(131072K)], 2.1122833 secs] [Times: user=2.11 sys=0.01, real=2.11 secs] <br /><br />and i suspect it is because of small young space. but also noticed that Perm space is not reclaimed after GC. Please suggest.<br /><br />Thanks,<br />-Girish<br />Anonymoushttps://www.blogger.com/profile/13124238014440492013noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-54949441300546201982018-05-18T16:24:09.201+01:002018-05-18T16:24:09.201+01:00It would get resolved eventually. One way or anoth...It would get resolved eventually. One way or another.<br /><br />- After few young GC, Y would be promoted to old just to die there.<br /><br />- Full GC collects both generation at the same time.<br /><br />Old one GC is effectively possible only in CMS. Mark Sweep Compact is during young / full collection.Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-10979519324628194552018-05-18T15:55:13.602+01:002018-05-18T15:55:13.602+01:00Hi, another question from me :)
Lets say that Obje...Hi, another question from me :)<br />Lets say that Object O is already in Old space and is live (root is pointing at him).<br />Now, object Y is in Eden and object O is pointing at it, thus is alive.<br />After some time:<br />Object O is not alive (no longer pointed by root), but is cross pointing with Object Y. Because it is mark and copy, minor GC cannot delete object Y (every time copy from survivor to survivor a dirty card is made).<br />During full GC, as I found here https://plumbr.io/handbook/garbage-collection-algorithms-implementations<br />First DefNew runs -> cannot delete object Y, because is pointed by object O.<br />Next Tenured -> cannot delete object O, because is pointed by object Y.<br /><br />How does it work then?Anonymoushttps://www.blogger.com/profile/07317015854230822802noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-53824591780343161102018-05-15T06:50:56.070+01:002018-05-15T06:50:56.070+01:00At step (4) all objects in young space are physica...At step (4) all objects in young space are physically moved to surviviour space, so object A would be updated with new address of B and thus marked as dirty.Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-48887658809300769452018-05-14T20:18:09.633+01:002018-05-14T20:18:09.633+01:00Hi. I have a question. When object gets to old fro...Hi. I have a question. When object gets to old from young it is marked as Dirty card (right?). Let's suppose that:<br />1. Object A is live and is reffering to Object B (in young collection)<br />2. After GC Object A is promoted to old (so is marked as dirty card).<br />3. Object A is not modified, but because it was marked as dirty card, Object B is still live, because of Object A.<br />4. Another GC -> Cards are reset.<br />5. Object A was not modified, so is not marked as dirty card.<br />6. Object B is deleted?<br /><br />Are old object marked somehow if they were found to have a reference to young object?<br /><br />Or maybe when objects are copied to one of survivor space, the references to them were changed, therefore objects in old generation were modified and marked as dirty cards?Anonymoushttps://www.blogger.com/profile/07317015854230822802noreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-23775563725050959242018-03-19T14:11:54.131+00:002018-03-19T14:11:54.131+00:00Thank you, Леша, for sharing your experience. It i...Thank you, Леша, for sharing your experience. It is very much valuable and it's so good to know. I am so glad you mentioned FPC here. It would prolly worth to mention and awesome Lazarus IDE for FreePascal as well.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7735872642513631302.post-61533059097187905452018-03-06T17:38:56.655+00:002018-03-06T17:38:56.655+00:00There are no pages. Each page is just DIRTY/CLEAN ...There are no pages. Each page is just DIRTY/CLEAN flag value in card table. There DIRTY means - corresponding 512 bytes of heap may contain object reference modified since last card table reset.Alexey Ragozinhttps://www.blogger.com/profile/13720493857045012756noreply@blogger.com