StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PONeed an explanation for apparent heap size reduction
primarykey
Id
20684266
data
AcceptedAnswerId
20684618
AnswerCount
2
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-12-19T14:28:58.923
FavoriteCount
0
LastActivityDate
2014-01-09T10:18:55.033
LastEditDate
2014-01-09T07:51:03.440
LastEditorUserId
3119494
OwnerUserId
3119494
ParentId
0
PostTypeId
1
Score
1
ViewCount
590
LastEditorDisplayName
text
Body
From the GC logs, it appears that the heap size is being reduced across young and old generations after sometime. Below are three entries from the logs. {Heap before gc invocations=5: PSYoungGen total 44800K, used 44180K [0x18220000, 0x1b420000, 0x24a20000) eden space 38400K, 100% used [0x18220000,0x1a7a0000,0x1a7a0000) from space 6400K, 90% used [0x1ade0000,0x1b3853c8,0x1b420000) to space 6400K, 0% used [0x1a7a0000,0x1a7a0000,0x1ade0000) PSOldGen total 51200K, used 16K [0x0ba20000, 0x0ec20000, 0x18220000) object space 51200K, 0% used [0x0ba20000,0x0ba24128,0x0ec20000) PSPermGen total 32768K, used 12417K [0x03a20000, 0x05a20000, 0x0ba20000) object space 32768K, 37% used [0x03a20000,0x046406c0,0x05a20000) 1047.599: [GC [PSYoungGen: 44180K->5990K(44032K)] 44197K->6006K(95232K), 0.0046671 secs] Heap after gc invocations=5: PSYoungGen total 44032K, used 5990K [0x18220000, 0x1b5a0000, 0x24a20000) eden space 37632K, 0% used [0x18220000,0x18220000,0x1a6e0000) from space 6400K, 93% used [0x1a7a0000,0x1ad79990,0x1ade0000) to space 7552K, 0% used [0x1ae40000,0x1ae40000,0x1b5a0000) PSOldGen total 51200K, used 16K [0x0ba20000, 0x0ec20000, 0x18220000) object space 51200K, 0% used [0x0ba20000,0x0ba24128,0x0ec20000) PSPermGen total 32768K, used 12417K [0x03a20000, 0x05a20000, 0x0ba20000) object space 32768K, 37% used [0x03a20000,0x046406c0,0x05a20000) } <hr> {Heap before gc invocations=174: PSYoungGen total 9728K, used 9666K [0x18220000, 0x18d30000, 0x24a20000) eden space 8640K, 99% used [0x18220000,0x18a8fa58,0x18a90000) from space 1088K, 94% used [0x18a90000,0x18b910f0,0x18ba0000) to space 1344K, 0% used [0x18be0000,0x18be0000,0x18d30000) PSOldGen total 51200K, used 21113K [0x0ba20000, 0x0ec20000, 0x18220000) object space 51200K, 41% used [0x0ba20000,0x0cebe540,0x0ec20000) PSPermGen total 32768K, used 12611K [0x03a20000, 0x05a20000, 0x0ba20000) object space 32768K, 38% used [0x03a20000,0x04670fa0,0x05a20000) 26968.748: [GC [PSYoungGen: 9666K->1271K(9920K)] 30780K->22465K(61120K), 0.0025274 secs] Heap after gc invocations=174: PSYoungGen total 9920K, used 1271K [0x18220000, 0x18d50000, 0x24a20000) eden space 8576K, 0% used [0x18220000,0x18220000,0x18a80000) from space 1344K, 94% used [0x18be0000,0x18d1dd00,0x18d30000) to space 1408K, 0% used [0x18a80000,0x18a80000,0x18be0000) PSOldGen total 51200K, used 21194K [0x0ba20000, 0x0ec20000, 0x18220000) object space 51200K, 41% used [0x0ba20000,0x0ced29e0,0x0ec20000) PSPermGen total 32768K, used 12611K [0x03a20000, 0x05a20000, 0x0ba20000) object space 32768K, 38% used [0x03a20000,0x04670fa0,0x05a20000) } <hr> {Heap before gc invocations=23195: PSYoungGen total 1536K, used 1372K [0x18220000, 0x18440000, 0x24a20000) eden space 896K, 100% used [0x18220000,0x18300000,0x18300000) from space 640K, 74% used [0x183a0000,0x184173e8,0x18440000) to space 640K, 0% used [0x18300000,0x18300000,0x183a0000) PSOldGen total 6272K, used 4627K [0x0ba20000, 0x0c040000, 0x18220000) object space 6272K, 73% used [0x0ba20000,0x0bea4d70,0x0c040000) PSPermGen total 32768K, used 12930K [0x03a20000, 0x05a20000, 0x0ba20000) object space 32768K, 39% used [0x03a20000,0x046c0aa0,0x05a20000) 71908.146: [GC [PSYoungGen: 1372K->533K(1536K)] 6000K->5423K(7808K), 0.0107964 secs] Heap after gc invocations=23195: PSYoungGen total 1536K, used 533K [0x18220000, 0x18460000, 0x24a20000) eden space 896K, 0% used [0x18220000,0x18220000,0x18300000) from space 640K, 83% used [0x18300000,0x18385438,0x183a0000) to space 704K, 0% used [0x183b0000,0x183b0000,0x18460000) PSOldGen total 6272K, used 4890K [0x0ba20000, 0x0c040000, 0x18220000) object space 6272K, 77% used [0x0ba20000,0x0bee6868,0x0c040000) PSPermGen total 32768K, used 12930K [0x03a20000, 0x05a20000, 0x0ba20000) object space 32768K, 39% used [0x03a20000,0x046c0aa0,0x05a20000) } <hr> The (relevant) JVM parameters used are as follows : -server -Xms600m -Xss256k -XX:+UseParallelGC -XX:+PrintHeapAtGC -XX:+HeapDumpOnOutOfMemoryError -Xloggc:verbose_gc.log -Djavax.net.debug=none -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:+PrintClassHistogram -Xmx800m -XX:NewRatio=1 -XX:CompileThreshold=1500 -XX:PermSize=32m -XX:MaxPermSize=128m An assumption that memory was being consumed by too many threads (based on the understanding that stack memory was different from heap memory) was shown to be false with a sample application that simply created new threads, when observed using visual vm (the young and tenured generations filled up). Is there any explanation to this behaviour? Update #1: Correction and Update: The above sample application also included an array object being created with each thread. The array size was a non trivial fraction of the total heap. The issue is observable in JDK 1.5. -R
Tags
<java><memory><garbage-collection><stack><heap>
Title
Need an explanation for apparent heap size reduction
singulars
PostAcceptedAnswerId
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
PostParentId
1. This table or related slice is empty.
PostTypePostTypeId
1. PTQuestion
UserLastEditorUserId
1. USR2D2
UserOwnerUserId
1. USR2D2
plurals
PostLinksPostIdRelatedPostId
1. PL
 singulars
 LinkTypeLinkTypeId
 LTLinked
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PONeed an explanation for apparent heap size reduction
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.