Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update to avoid initial LOA size is smaller than largeObjectMinimumSize #4860

Merged
merged 1 commit into from Mar 26, 2020
Merged

Update to avoid initial LOA size is smaller than largeObjectMinimumSize #4860

merged 1 commit into from Mar 26, 2020

Conversation

LinHu2016
Copy link
Contributor

@LinHu2016 LinHu2016 commented Feb 24, 2020 •
edited 

LOA size should be bigger than largeObjectMinimumSize, otherwise
the assertion would be triggered during allocation.
small initial heap size via custom Xms option might cause the case.
Update the code to set LOA = 0 if initial LOA size is smaller
than largeObjectMinimumSize.
use inline function isSizeEnoughForLOA() to reduce code duplication.

Signed-off-by: Lin Hu linhu@ca.ibm.com

@LinHu2016
Copy link
Contributor Author

local test result:

./java -Xms1m -verbose:gc -version

<?xml version="1.0" ?>

<verbosegc xmlns="http://www.ibm.com/j9/verbosegc" version="37236c4_CMPRSS">

<initialized id="1" timestamp="2020-02-24T16:53:10.120">
  <attribute name="gcPolicy" value="-Xgcpolicy:gencon" />
  <attribute name="maxHeapSize" value="0x20000000" />
  <attribute name="initialHeapSize" value="0x100000" />
  <attribute name="compressedRefs" value="true" />
  <attribute name="compressedRefsDisplacement" value="0x0" />
  <attribute name="compressedRefsShift" value="0x0" />
  <attribute name="pageSize" value="0x200000" />
  <attribute name="pageType" value="not used" />
  <attribute name="requestedPageSize" value="0x200000" />
  <attribute name="requestedPageType" value="not used" />
  <attribute name="gcthreads" value="64" />
  <attribute name="gcthreads Concurrent Mark" value="1" />
  <attribute name="packetListSplit" value="8" />
  <attribute name="cacheListSplit" value="8" />
  <attribute name="splitFreeListSplitAmount" value="8" />
  <attribute name="numaNodes" value="0" />
  <system>
    <attribute name="physicalMemory" value="67473666048" />
    <attribute name="numCPUs" value="80" />
    <attribute name="architecture" value="amd64" />
    <attribute name="os" value="Linux" />
    <attribute name="osVersion" value="2.6.32-504.12.2.el6.x86_64" />
  </system>
  <vmargs>
    <vmarg name="-Xoptionsfile=/bluebird/builds/bld_440417/sdk/xa6480/jre/lib/amd64/compressedrefs/options.default" />
    <vmarg name="-Xlockword:mode=default,noLockword=java/lang/String,noLockword=java/util/MapEntry,noLockword=java/util/HashMap$Entry,noLockword..." />
    <vmarg name="-Djava.lang.stringBuffer.growAggressively=false" />
    <vmarg name="-XX:+OriginalJDK8HeapSizeCompatibilityMode" />
    <vmarg name="-Xjcl:jclse29" />
    <vmarg name="-Dcom.ibm.oti.vm.bootstrap.library.path=/bluebird/builds/bld_440417/sdk/xa6480/jre/lib/amd64/compressedrefs:/bluebird/builds/bl..." />
    <vmarg name="-Dsun.boot.library.path=/bluebird/builds/bld_440417/sdk/xa6480/jre/lib/amd64/compressedrefs:/bluebird/builds/bld_440417/sdk/xa6..." />
    <vmarg name="-Djava.library.path=/bluebird/builds/bld_440417/sdk/xa6480/jre/lib/amd64/compressedrefs:/bluebird/builds/bld_440417/sdk/xa6480/..." />
    <vmarg name="-Djava.home=/bluebird/builds/bld_440417/sdk/xa6480/jre" />
    <vmarg name="-Djava.ext.dirs=/bluebird/builds/bld_440417/sdk/xa6480/jre/lib/ext" />
    <vmarg name="-Duser.dir=/bluebird/builds/bld_440417/sdk/xa6480/jre/bin" />
    <vmarg name="-Djava.class.path=." />
    <vmarg name="-Xms1m" />
    <vmarg name="-verbose:gc" />
    <vmarg name="-Dsun.java.launcher=SUN_STANDARD" />
    <vmarg name="-Dsun.java.launcher.pid=16923" />
  </vmargs>
</initialized>

<exclusive-start id="2" timestamp="2020-02-24T16:53:10.227" intervalms="107.406">
  <response-info timems="0.046" idlems="0.046" threads="0" lastid="0000000001954D00" lastname="main" />
</exclusive-start>
<af-start id="3" threadId="0000000001955680" totalBytesRequested="16392" timestamp="2020-02-24T16:53:10.227" intervalms="107.488" type="nursery" />
<cycle-start id="4" type="scavenge" contextid="0" timestamp="2020-02-24T16:53:10.227" intervalms="107.532" />
<gc-start id="5" type="scavenge" contextid="4" timestamp="2020-02-24T16:53:10.227">
  <mem-info id="6" free="740368" total="1048576" percent="70">
    <mem type="nursery" free="0" total="262144" percent="0">
      <mem type="allocate" free="0" total="131072" percent="0" />
      <mem type="survivor" free="0" total="131072" percent="0" />
    </mem>
    <mem type="tenure" free="740368" total="786432" percent="94">
      <mem type="soa" free="740368" total="786432" percent="94" />
      <mem type="loa" free="0" total="0" percent="0" />
    </mem>
    <remembered-set count="805" />
  </mem-info>
</gc-start>
<allocation-stats totalBytes="148816" >
  <allocated-bytes non-tlh="62456" tlh="86360" />
  <largest-consumer threadName="main" threadId="0000000001954D00" bytes="148816" />
</allocation-stats>
<gc-op id="7" type="scavenge" timems="1.423" contextid="4" timestamp="2020-02-24T16:53:10.229">
  <scavenger-info tenureage="2" tenuremask="fffc" tiltratio="50" />
  <memory-copied type="nursery" objects="1568" bytes="96192" bytesdiscarded="34704" />
  <finalization candidates="2" enqueued="0" />
  <references type="soft" candidates="1" cleared="0" enqueued="0" dynamicThreshold="32" maxThreshold="32" />
  <references type="weak" candidates="1" cleared="0" enqueued="0" />
</gc-op>
<gc-end id="8" type="scavenge" contextid="4" durationms="1.547" usertimems="1.000" systemtimems="0.000" timestamp="2020-02-24T16:53:10.229" activeThreads="1">
  <mem-info id="9" free="740368" total="1048576" percent="70">
    <mem type="nursery" free="0" total="262144" percent="0">
      <mem type="allocate" free="0" total="131072" percent="0" />
      <mem type="survivor" free="0" total="131072" percent="0" />
    </mem>
    <mem type="tenure" free="740368" total="786432" percent="94">
      <mem type="soa" free="740368" total="786432" percent="94" />
      <mem type="loa" free="0" total="0" percent="0" />
    </mem>
    <remembered-set count="805" />
  </mem-info>
</gc-end>
<cycle-end id="10" type="scavenge" contextid="4" timestamp="2020-02-24T16:53:10.229" />

@LinHu2016
Copy link
Contributor Author

@amicic @dmitripivkine please review the change, thanks

@LinHu2016 LinHu2016 force-pushed the PR143196 branch 4 times, most recently from dcc70d4 to 4b5d839 Compare February 26, 2020 18:33
@LinHu2016 LinHu2016 force-pushed the PR143196 branch 3 times, most recently from 4238fed to e5ed6a7 Compare March 4, 2020 21:23
@amicic
Copy link
Contributor

amicic commented Mar 10, 2020

@youngar or @rwy0717, please proceed with further review

@rwy7
Copy link
Member

rwy7 commented Mar 12, 2020

@genie-omr build all

@youngar
Copy link
Member

youngar commented Mar 19, 2020

@genie-omr build aix

youngar
youngar suggested changes Mar 19, 2020
View reviewed changes
gc/base/MemoryPoolLargeObjects.cpp Show resolved Hide resolved
gc/base/MemoryPoolLargeObjects.hpp Outdated Show resolved Hide resolved
gc/base/MemoryPoolLargeObjects.hpp Outdated Show resolved Hide resolved
gc/base/MemoryPoolLargeObjects.hpp Outdated Show resolved Hide resolved
@youngar
Copy link
Member

youngar commented Mar 19, 2020

lgtm with a couple nitpicks

@LinHu2016
Update to avoid initial LOA size is smaller than largeObjectMinimumSize
af827ba 
	LOA size should be bigger than largeObjectMinimumSize, otherwise
	the assertion would be triggered during allocation.
	small initial heap size via custom Xms option might cause the case.
	Update the code to set LOA = 0 if initial LOA size is smaller
	than largeObjectMinimumSize.
	- use inline function checkAndSetSizeForLOA() to reduce code
duplication.

Signed-off-by: Lin Hu <linhu@ca.ibm.com>
@youngar
Copy link
Member

youngar commented Mar 26, 2020

@genie-omr build all

@youngar youngar self-assigned this Mar 26, 2020
@youngar
Copy link
Member

youngar commented Mar 26, 2020

ignoring z/os due to infrastructure issue

@youngar youngar merged commit cf39567 into eclipse:master Mar 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@youngar youngar youngar approved these changes

@amicic amicic amicic approved these changes

@charliegracie charliegracie Awaiting requested review from charliegracie

@rwy7 rwy7 Awaiting requested review from rwy7

Assignees

@youngar youngar

Labels
comp:gc
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
5 participants
@LinHu2016 @amicic @rwy7 @youngar @0xdaryl