<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi GC team,<br>
    <br>
    The CR is here <a class="moz-txt-link-freetext" href="https://jbs.oracle.com/bugs/browse/JDK-8022892">https://jbs.oracle.com/bugs/browse/JDK-8022892</a>.<br>
    <br>
    First of all, Jon pointed out it's not a regression in hs24 since it
    reported against hs23. (Thank you, Jon) I think this is right. But
    i'm not sure, only with that, whether I can get through the deferral
    process.<br>
    <br>
    So, let me put down what I have found so far.<br>
    <br>
    1. In the CR,
    <meta charset="utf-8">
    <span style="color: rgb(0, 0, 0); font-family: Arial, FreeSans,
      Helvetica, sans-serif; font-size: 12.727272033691406px;
      font-style: normal; font-variant: normal; font-weight: normal;
      letter-spacing: normal; line-height: 15.454545021057129px;
      orphans: auto; text-align: start; text-indent: 0px;
      text-transform: none; white-space: normal; widows: auto;
      word-spacing: 0px; -webkit-text-stroke-width: 0px;
      background-color: rgb(255, 255, 255); display: inline !important;
      float: none;">¬†Exception Code:c0000005 </span>is seen and it
    means EXCEPTION_ACCESS_VIOLATION. This type of error is reported
    many times in different places inside and outside VM. Also, in the
    CR, it shows "
    <meta charset="utf-8">
    <span style="color: rgb(0, 0, 0); font-family: Arial, FreeSans,
      Helvetica, sans-serif; font-size: 12.727272033691406px;
      font-style: normal; font-variant: normal; font-weight: normal;
      letter-spacing: normal; line-height: 15.454545021057129px;
      orphans: auto; text-align: start; text-indent: 0px;
      text-transform: none; white-space: normal; widows: auto;
      word-spacing: 0px; -webkit-text-stroke-width: 0px;
      background-color: rgb(255, 255, 255); display: inline !important;
      float: none;">Fault Module Name:msvcr100.dll</span>", which
    indicates the top of stack frame is C native code/3rd party library
    from Microsoft. Thus, it may be not a VM problem at all, in this
    case.<br>
    <br>
    2. Let's look at the ILW priority mapping. The impact is high since
    it's crash. <br>
    <br>
    But there's ambiguity about its likelihood and workaround. I would
    think the likelihood is low according to the definition
    (<a class="moz-txt-link-freetext" href="http://wiki.se.oracle.com/display/JPGRM/ILW+and+priority+mapping+for+bugs#ILWandprioritymappingforbugs-DefectClassification">http://wiki.se.oracle.com/display/JPGRM/ILW+and+priority+mapping+for+bugs#ILWandprioritymappingforbugs-DefectClassification</a>)
    <br>
    <br>
    "
    <meta charset="utf-8">
    <span style="color: rgb(0, 0, 0); font-family: Arial, Helvetica,
      FreeSans, sans-serif; font-size: 13.63636302947998px; font-style:
      normal; font-variant: normal; font-weight: normal; letter-spacing:
      normal; line-height: 17.329545974731445px; orphans: auto;
      text-align: left; text-indent: 0px; text-transform: none;
      white-space: normal; widows: auto; word-spacing: 0px;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none;">The defect is
      encountered in an uncommon (or unsupported) use case or is
      intermittent in nature with a low frequency of occurrence</span>"<br>
    <br>
    Starting with initial heap size 140GB seems to be an uncommon use
    case (to me).<br>
    <br>
    Workaround: use other collector as the report stated or lower heap
    size. Low.<br>
    <br>
    ILW = HLL = P4.<br>
    <br>
    3. In fact, it's hard to find a windows machine configured with
    140GB memory. Probably there's no such machine if you refer to
    RAM/CPU limits of Windows machine stated in Microsoft website
    (<a class="moz-txt-link-freetext" href="http://support.microsoft.com/kb/2860880">http://support.microsoft.com/kb/2860880</a>). The RAM limit for Windows
    HPC Server 2008 R2 is 128GB. That's the reason why I think the
    likelihood is low.<br>
    <br>
    What I'm trying to do here is to use the Linux machine
    <meta charset="utf-8">
    <meta charset="utf-8">
    <span style="color: rgb(0, 0, 0); font-family: Arial, Helvetica,
      FreeSans, sans-serif; font-size: 13.63636302947998px; font-style:
      normal; font-variant: normal; font-weight: normal; letter-spacing:
      normal; line-height: 17.329545974731445px; orphans: auto;
      text-align: left; text-indent: 0px; text-transform: none;
      white-space: normal; widows: auto; word-spacing: 0px;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none;">sthdev05.se.oracle.com
    </span>listed here
    (<a class="moz-txt-link-freetext" href="http://wiki.se.oracle.com/display/JRPG/Development+Servers">http://wiki.se.oracle.com/display/JRPG/Development+Servers</a>). This
    machine have about 256GB memory. But the VM cannot allocate(commit)
    enough memory if I set -Xms to be 35g or higher. In this attempt, we
    are not yet close to reproducing.<br>
    <br>
    Ok, that's all I've found. <br>
    <br>
    Among all these, I'd like to add the 128GB RAM limit of this type of
    Windows server as the second justification.<br>
    <br>
    Could you read the email and look through the bug report to help
    obtain at least one more evidence for the deferral justification if
    possible?<br>
    <br>
    Thanks.<br>
    Tao<br>
    <br>
    <br>
    <meta charset="utf-8">
  </body>
</html>