openjdk8_j9_extended.system_x86-64_mac DaaLoadTest_all_ConcurrentScavenge_0_FAILED Segmentation error vmState=0x00020003 #8020
Labels
Milestone
Comments
|
@dmitripivkine can you pls take a look. |
|
@amicic FYI |
|
This crash occur because Mark Map for heap range above |
|
@RSalman Would you please take a look? |
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Jan 13, 2020
- MarkMap init consolidated MarkMap init logic has been merged to resolve the timing hole outlined in eclipse-openj9/openj9#8020. MarkMap init is dependent on Concurrent State of the global collector, with the init logic split between `heapAddRange` and `heapReconfigured`, any changes in states between the two may leave expanded mark map uninited. Hence, the decision to init (`setMarkBitsInRange`) the mark map has been moved from `heapAddRange` to `heapReconfigured` which is where we determine if an update to the init table is required (`tuneToHeap`/`determineInitWork`). As a result, init is no longer affected by the change in Concurrent state and we eliminate the timing window. This guarantee that the MarkMap will be inited, either on the spot or afterwards by updating the init table. - Introduced HeapReconfigReason and reworked heapReconfigred API heapReconfigred now distinguishes different reasons for reconfiguration (Expand, contract, etc), this functionality is required for the Mark Map init changes, specifically for Gencon and it is used when Scavenger resizes tenure _(PhysicalSubArenaVirtualMemorySemiSpace)_ or global collecter preforms a resize _(PhysicalSubArenaVirtualMemoryFlat)_. At the time, this is new information is only consumed by Concurrent Global Collecter (ConcurrentGC.cpp), for policies making use of other collectors the HeapReconfigReason param defaults to `NONE`. The Reconfig reasons are dealt in the following ways by Concurrent Global Collector: - We should never end up in `heapReconfigured` with `RECONFIG_NONE` reason - `RECONFIG_CONTRACT` signifies that `heapRemoveRange` had taken place, in which case, we just need to update init table (`tuneToHeap`) when Concurrent is Off, otherwise just `adjustTraceTargets` - If `heapAddRange` takes place then `heapReconfigured` is called with `RECONFIG_EXPAND` and have have two different cases: 1) heapAddRange was successful (return true), heap reconfig should be provided with `lowAddress` & `highAddress` which will be used to init mark map 2) heapAddRange returns false, signifies a failed `heapAddRange`, address params are expected to be NULL, in which case mark map won't be inited but we'll still either `tuneToHeap` or `adjustTraceTarget`. Signed-off-by: Salman Rana <salman.rana@ibm.com>
|
The issue always seems to be when Concurrent kickoff occurs in the middle of heap expansion (which is fine but we have a very specific timing hole) At a minimum, when expanding, the mark map must be either set/cleared or added to init ranges table (which will end up eventually initing) . However, there is a very specific timing window where neither is done, which I believe is causing the crash. The logic to init the mark map is dependent on Concurrent State, as a result concurrent kickoff in a middle of expansion can have some unintended side effects. The timing hole is a result of the following:
If Expansion starts before Concurrent KO and we commit the mark map while concurrent is off, we won’t clear it, we would except the init ranges table to be updated given Concurrent is off. However, this is not the case if Concurrent starts and init is completed by the time we go to check Concurrent state to rebuild init ranges table. This is possible, heapAddRange does the first check to clear the mark map and heapReconfigured does the second check to rebuild the table.. hence we have an issue in the following:
The mark map is never initialized. If the expansion had completed before KO init, we would of updated init ranges table and it would of been visible to KO init and eventually gotten inited/cleared…. if the expansion had started right after KO init, we would of simply cleared and delayed updating mark map until next safe point! Since neither is done and this was expanded after a contract, we are dealing with corrupted piece of mark map. |
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Jan 14, 2020
- MarkMap init consolidated MarkMap init logic has been merged to resolve the timing hole outlined in eclipse-openj9/openj9#8020. MarkMap init is dependent on Concurrent State of the global collector, with the init logic split between `heapAddRange` and `heapReconfigured`, any changes in states between the two may leave expanded mark map uninited. Hence, the decision to init (`setMarkBitsInRange`) the mark map has been moved from `heapAddRange` to `heapReconfigured` which is where we determine if an update to the init table is required (`tuneToHeap`/`determineInitWork`). As a result, init is no longer affected by the change in Concurrent state and we eliminate the timing window. This guarantee that the MarkMap will be inited, either on the spot or afterwards by updating the init table. - Introduced HeapReconfigReason and reworked heapReconfigred API heapReconfigred now distinguishes different reasons for reconfiguration (Expand, contract, etc), this functionality is required for the Mark Map init changes, specifically for Gencon and it is used when Scavenger resizes tenure _(PhysicalSubArenaVirtualMemorySemiSpace)_ or global collecter preforms a resize _(PhysicalSubArenaVirtualMemoryFlat)_. At the time, this is new information is only consumed by Concurrent Global Collecter (ConcurrentGC.cpp), for policies making use of other collectors the HeapReconfigReason param defaults to `NONE`. The Reconfig reasons are dealt in the following ways by Concurrent Global Collector: - We should never end up in `heapReconfigured` with `RECONFIG_NONE` reason - `RECONFIG_CONTRACT` signifies that `heapRemoveRange` had taken place, in which case, we just need to update init table (`tuneToHeap`) when Concurrent is Off, otherwise just `adjustTraceTargets` - If `heapAddRange` takes place then `heapReconfigured` is called with `RECONFIG_EXPAND` and have have two different cases: 1) heapAddRange was successful (return true), heap reconfig should be provided with `lowAddress` & `highAddress` which will be used to init mark map 2) heapAddRange returns false, signifies a failed `heapAddRange`, address params are expected to be NULL, in which case mark map won't be inited but we'll still either `tuneToHeap` or `adjustTraceTarget`. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Jan 14, 2020
- MarkMap init consolidated MarkMap init logic has been merged to resolve the timing hole outlined in eclipse-openj9/openj9#8020. MarkMap init is dependent on Concurrent State of the global collector, with the init logic split between `heapAddRange` and `heapReconfigured`, any changes in states between the two may leave expanded mark map uninited. Hence, the decision to init (`setMarkBitsInRange`) the mark map has been moved from `heapAddRange` to `heapReconfigured` which is where we determine if an update to the init table is required (`tuneToHeap`/`determineInitWork`). As a result, init is no longer affected by the change in Concurrent state and we eliminate the timing window. This guarantee that the MarkMap will be inited, either on the spot or afterwards by updating the init table. - Introduced HeapReconfigReason and reworked heapReconfigred API heapReconfigred now distinguishes different reasons for reconfiguration (Expand, contract, etc), this functionality is required for the Mark Map init changes, specifically for Gencon and it is used when Scavenger resizes tenure _(PhysicalSubArenaVirtualMemorySemiSpace)_ or global collecter preforms a resize _(PhysicalSubArenaVirtualMemoryFlat)_. At the time, this is new information is only consumed by Concurrent Global Collecter (ConcurrentGC.cpp), for policies making use of other collectors the HeapReconfigReason param defaults to `NONE`. The Reconfig reasons are dealt in the following ways by Concurrent Global Collector: - We should never end up in `heapReconfigured` with `RECONFIG_NONE` reason - `RECONFIG_CONTRACT` signifies that `heapRemoveRange` had taken place, in which case, we just need to update init table (`tuneToHeap`) when Concurrent is Off, otherwise just `adjustTraceTargets` - If `heapAddRange` takes place then `heapReconfigured` is called with `RECONFIG_EXPAND` and have have two different cases: 1) heapAddRange was successful (return true), heap reconfig should be provided with `lowAddress` & `highAddress` which will be used to init mark map 2) heapAddRange returns false, signifies a failed `heapAddRange`, address params are expected to be NULL, in which case mark map won't be inited but we'll still either `tuneToHeap` or `adjustTraceTarget`. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Jan 14, 2020
- MarkMap init consolidated MarkMap init logic has been merged to resolve the timing hole outlined in eclipse-openj9/openj9#8020. MarkMap init is dependent on Concurrent State of the global collector, with the init logic split between `heapAddRange` and `heapReconfigured`, any changes in states between the two may leave expanded mark map uninited. Hence, the decision to init (`setMarkBitsInRange`) the mark map has been moved from `heapAddRange` to `heapReconfigured` which is where we determine if an update to the init table is required (`tuneToHeap`/`determineInitWork`). As a result, init is no longer affected by the change in Concurrent state and we eliminate the timing window. This guarantee that the MarkMap will be inited, either on the spot or afterwards by updating the init table. - Introduced HeapReconfigReason and reworked heapReconfigred API heapReconfigred now distinguishes different reasons for reconfiguration (Expand, contract, etc), this functionality is required for the Mark Map init changes, specifically for Gencon and it is used when Scavenger resizes tenure _(PhysicalSubArenaVirtualMemorySemiSpace)_ or global collecter preforms a resize _(PhysicalSubArenaVirtualMemoryFlat)_. At the time, this is new information is only consumed by Concurrent Global Collecter (ConcurrentGC.cpp), for policies making use of other collectors the HeapReconfigReason param defaults to `NONE`. The Reconfig reasons are dealt in the following ways by Concurrent Global Collector: - We should never end up in `heapReconfigured` with `RECONFIG_NONE` reason - `RECONFIG_CONTRACT` signifies that `heapRemoveRange` had taken place, in which case, we just need to update init table (`tuneToHeap`) when Concurrent is Off, otherwise just `adjustTraceTargets` - If `heapAddRange` takes place then `heapReconfigured` is called with `RECONFIG_EXPAND` and have have two different cases: 1) heapAddRange was successful (return true), heap reconfig should be provided with `lowAddress` & `highAddress` which will be used to init mark map 2) heapAddRange returns false, signifies a failed `heapAddRange`, address params are expected to be NULL, in which case mark map won't be inited but we'll still either `tuneToHeap` or `adjustTraceTarget`. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Jan 15, 2020
- MarkMap init consolidated MarkMap init logic has been merged to resolve the timing hole outlined in eclipse-openj9/openj9#8020. MarkMap init is dependent on Concurrent State of the global collector, with the init logic split between `heapAddRange` and `heapReconfigured`, any changes in states between the two may leave expanded mark map uninited. Hence, the decision to init (`setMarkBitsInRange`) the mark map has been moved from `heapAddRange` to `heapReconfigured` which is where we determine if an update to the init table is required (`tuneToHeap`/`determineInitWork`). As a result, init is no longer affected by the change in Concurrent state and we eliminate the timing window. This guarantee that the MarkMap will be inited, either on the spot or afterwards by updating the init table. - Introduced HeapReconfigReason and reworked heapReconfigred API heapReconfigred now distinguishes different reasons for reconfiguration (Expand, contract, etc), this functionality is required for the Mark Map init changes, specifically for Gencon and it is used when Scavenger resizes tenure _(PhysicalSubArenaVirtualMemorySemiSpace)_ or global collecter preforms a resize _(PhysicalSubArenaVirtualMemoryFlat)_. At the time, this is new information is only consumed by Concurrent Global Collecter (ConcurrentGC.cpp), for policies making use of other collectors the HeapReconfigReason param defaults to `NONE`. The Reconfig reasons are dealt in the following ways by Concurrent Global Collector: - We should never end up in `heapReconfigured` with `RECONFIG_NONE` reason - `RECONFIG_CONTRACT` signifies that `heapRemoveRange` had taken place, in which case, we just need to update init table (`tuneToHeap`) when Concurrent is Off, otherwise just `adjustTraceTargets` - If `heapAddRange` takes place then `heapReconfigured` is called with `RECONFIG_EXPAND` and have have two different cases: 1) heapAddRange was successful (return true), heap reconfig should be provided with `lowAddress` & `highAddress` which will be used to init mark map 2) heapAddRange returns false, signifies a failed `heapAddRange`, address params are expected to be NULL, in which case mark map won't be inited but we'll still either `tuneToHeap` or `adjustTraceTarget`. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Jan 15, 2020
- MarkMap init consolidated MarkMap init logic has been merged to resolve the timing hole outlined in eclipse-openj9/openj9#8020. MarkMap init is dependent on Concurrent State of the global collector, with the init logic split between `heapAddRange` and `heapReconfigured`, any changes in states between the two may leave expanded mark map uninited. Hence, the decision to init (`setMarkBitsInRange`) the mark map has been moved from `heapAddRange` to `heapReconfigured` which is where we determine if an update to the init table is required (`tuneToHeap`/`determineInitWork`). As a result, init is no longer affected by the change in Concurrent state and we eliminate the timing window. This guarantee that the MarkMap will be inited, either on the spot or afterwards by updating the init table. - Introduced HeapReconfigReason and reworked heapReconfigred API heapReconfigred now distinguishes different reasons for reconfiguration (Expand, contract, etc), this functionality is required for the Mark Map init changes, specifically for Gencon and it is used when Scavenger resizes tenure _(PhysicalSubArenaVirtualMemorySemiSpace)_ or global collecter preforms a resize _(PhysicalSubArenaVirtualMemoryFlat)_. At the time, this is new information is only consumed by Concurrent Global Collecter (ConcurrentGC.cpp), for policies making use of other collectors the HeapReconfigReason param defaults to `NONE`. The Reconfig reasons are dealt in the following ways by Concurrent Global Collector: - We should never end up in `heapReconfigured` with `RECONFIG_NONE` reason - `RECONFIG_CONTRACT` signifies that `heapRemoveRange` had taken place, in which case, we just need to update init table (`tuneToHeap`) when Concurrent is Off, otherwise just `adjustTraceTargets` - If `heapAddRange` takes place then `heapReconfigured` is called with `RECONFIG_EXPAND` and have have two different cases: 1) heapAddRange was successful (return true), heap reconfig should be provided with `lowAddress` & `highAddress` which will be used to init mark map 2) heapAddRange returns false, signifies a failed `heapAddRange`, address params are expected to be NULL, in which case mark map won't be inited but we'll still either `tuneToHeap` or `adjustTraceTarget`. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/openj9
that referenced
this issue
Jan 16, 2020
`heapReconfigured` API changes resulting from eclipse-omr/omr#4716 Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Jan 16, 2020
- MarkMap init consolidated MarkMap init logic has been merged to resolve the timing hole outlined in eclipse-openj9/openj9#8020. MarkMap init is dependent on Concurrent State of the global collector, with the init logic split between `heapAddRange` and `heapReconfigured`, any changes in states between the two may leave expanded mark map uninited. Hence, the decision to init (`setMarkBitsInRange`) the mark map has been moved from `heapAddRange` to `heapReconfigured` which is where we determine if an update to the init table is required (`tuneToHeap`/`determineInitWork`). As a result, init is no longer affected by the change in Concurrent state and we eliminate the timing window. This guarantee that the MarkMap will be inited, either on the spot or afterwards by updating the init table. - Introduced HeapReconfigReason and reworked heapReconfigred API heapReconfigred now distinguishes different reasons for reconfiguration (Expand, contract, etc), this functionality is required for the Mark Map init changes, specifically for Gencon and it is used when Scavenger resizes tenure _(PhysicalSubArenaVirtualMemorySemiSpace)_ or global collecter preforms a resize _(PhysicalSubArenaVirtualMemoryFlat)_. At the time, this is new information is only consumed by Concurrent Global Collecter (ConcurrentGC.cpp), for policies making use of other collectors the HeapReconfigReason param defaults to `NONE`. The Reconfig reasons are dealt in the following ways by Concurrent Global Collector: - We should never end up in `heapReconfigured` with `RECONFIG_NONE` reason - `RECONFIG_CONTRACT` signifies that `heapRemoveRange` had taken place, in which case, we just need to update init table (`tuneToHeap`) when Concurrent is Off, otherwise just `adjustTraceTargets` - If `heapAddRange` takes place then `heapReconfigured` is called with `RECONFIG_EXPAND` and have have two different cases: 1) heapAddRange was successful (return true), heap reconfig should be provided with `lowAddress` & `highAddress` which will be used to init mark map 2) heapAddRange returns false, signifies a failed `heapAddRange`, address params are expected to be NULL, in which case mark map won't be inited but we'll still either `tuneToHeap` or `adjustTraceTarget`. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/openj9
that referenced
this issue
Jan 17, 2020
`heapReconfigured` API changes resulting from eclipse-omr/omr#4716 Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Aug 4, 2021
Fixes eclipse-openj9/openj9#13206 This change switches the order between updating INIT table (tuneToHeap call) and setting mark bits in place. This way, we guarantee that MM bits are set in place when we miss to update INIT table (or it's not updated in time) given overlap of KO and Tenure Expand. The issue being resolved is similar to what has been outlined in a previous issue [eclipse-openj9/openj9#8020 (comment)], where Mark Map Bits get missed for init. Here, we have another similar timing hole, when one thread kicks off concurrent, Concurrent_OFF -> (Concurrent_INIT or INIT Complete), while the expanding thread is in middle of heapReconfigured. With the original ordering of heapReconfigured, we first attempt to set the mark bits in place when Concurrent is ON. With Concurrent_OFF, we delay setting the bits until Concurrent_INIT. This requires update to the init table. Hence, for Concurrent_OFF we forgo setting bits and update the init table, we will expect `tuneToHeap` to do `determineInitRanges` to update init ranges table. The issue occurs when we don't set mark bits in place (given concurrent_OFF) but concurrent starts after the check and prior to updating the init ranges. Here,we either don't update init table (since init is in progress) or miss to update it in time. With these changes of reordering heapReonfig, we will try to set mark bits in place only after check to update init range table. With this, any state transitions resulting in init table not being updated (or being updated to late) will be caught and accounted for as bits will be set after. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Aug 4, 2021
Fixes eclipse-openj9/openj9#13206 This change switches the order between updating INIT table (tuneToHeap call) and setting mark bits in place. This way, we guarantee that MM bits are set in place when we miss to update INIT table (or it's not updated in time) given overlap of KO and Tenure Expand. The issue being resolved is similar to what has been outlined in a previous issue [eclipse-openj9/openj9#8020 (comment)], where Mark Map Bits get missed for init. Here, we have another similar timing hole, when one thread kicks off concurrent, Concurrent_OFF -> (Concurrent_INIT or INIT Complete), while the expanding thread is in middle of heapReconfigured. With the original ordering of heapReconfigured, we first attempt to set the mark bits in place when Concurrent is ON. With Concurrent_OFF, we delay setting the bits until Concurrent_INIT. This requires update to the init table. Hence, for Concurrent_OFF we forgo setting bits and update the init table, we will expect `tuneToHeap` to do `determineInitRanges` to update init ranges table. The issue occurs when we don't set mark bits in place (given concurrent_OFF) but concurrent starts after the check and prior to updating the init ranges. Here,we either don't update init table (since init is in progress) or miss to update it in time. With these changes of reordering heapReonfig, we will try to set mark bits in place only after check to update init range table. With this, any state transitions resulting in init table not being updated (or being updated to late) will be caught and accounted for as bits will be set after. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Aug 10, 2021
Fixes eclipse-openj9/openj9#13206 This change switches the order between updating INIT table (tuneToHeap call) and setting mark bits in place. This way, we guarantee that MM bits are set in place when we miss to update INIT table (or it's not updated in time) given overlap of KO and Tenure Expand. The issue being resolved is similar to what has been outlined in a previous issue [eclipse-openj9/openj9#8020 (comment)], where Mark Map Bits get missed for init. Here, we have another similar timing hole, when one thread kicks off concurrent, Concurrent_OFF -> (Concurrent_INIT or INIT Complete), while the expanding thread is in middle of heapReconfigured. With the original ordering of heapReconfigured, we first attempt to set the mark bits in place when Concurrent is ON. With Concurrent_OFF, we delay setting the bits until Concurrent_INIT. This requires update to the init table. Hence, for Concurrent_OFF we forgo setting bits and update the init table, we will expect `tuneToHeap` to do `determineInitRanges` to update init ranges table. The issue occurs when we don't set mark bits in place (given concurrent_OFF) but concurrent starts after the check and prior to updating the init ranges. Here,we either don't update init table (since init is in progress) or miss to update it in time. With these changes of reordering heapReonfig, we will try to set mark bits in place only after check to update init range table. With this, any state transitions resulting in init table not being updated (or being updated to late) will be caught and accounted for as bits will be set after. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Aug 10, 2021
Fixes eclipse-openj9/openj9#13206 This change switches the order between updating INIT table (tuneToHeap call) and setting mark bits in place. This way, we guarantee that MM bits are set in place when we miss to update INIT table (or it's not updated in time) given overlap of KO and Tenure Expand. The issue being resolved is similar to what has been outlined in a previous issue [eclipse-openj9/openj9#8020 (comment)], where Mark Map Bits get missed for init. Here, we have another similar timing hole, when one thread kicks off concurrent, Concurrent_OFF -> (Concurrent_INIT or INIT Complete), while the expanding thread is in middle of heapReconfigured. With the original ordering of heapReconfigured, we first attempt to set the mark bits in place when Concurrent is ON. With Concurrent_OFF, we delay setting the bits until Concurrent_INIT. This requires update to the init table. Hence, for Concurrent_OFF we forgo setting bits and update the init table, we will expect `tuneToHeap` to do `determineInitRanges` to update init ranges table. The issue occurs when we don't set mark bits in place (given concurrent_OFF) but concurrent starts after the check and prior to updating the init ranges. Here,we either don't update init table (since init is in progress) or miss to update it in time. With these changes of reordering heapReonfig, we will try to set mark bits in place only after check to update init range table. With this, any state transitions resulting in init table not being updated (or being updated to late) will be caught and accounted for as bits will be set after. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Aug 11, 2021
Fixes eclipse-openj9/openj9#13206 This change switches the order between updating INIT table (tuneToHeap call) and setting mark bits in place. This way, we guarantee that MM bits are set in place when we miss to update INIT table (or it's not updated in time) given overlap of KO and Tenure Expand. The issue being resolved is similar to what has been outlined in a previous issue [eclipse-openj9/openj9#8020 (comment)], where Mark Map Bits get missed for init. Here, we have another similar timing hole, when one thread kicks off concurrent, Concurrent_OFF -> (Concurrent_INIT or INIT Complete), while the expanding thread is in middle of heapReconfigured. With the original ordering of heapReconfigured, we first attempt to set the mark bits in place when Concurrent is ON. With Concurrent_OFF, we delay setting the bits until Concurrent_INIT. This requires update to the init table. Hence, for Concurrent_OFF we forgo setting bits and update the init table, we will expect `tuneToHeap` to do `determineInitRanges` to update init ranges table. The issue occurs when we don't set mark bits in place (given concurrent_OFF) but concurrent starts after the check and prior to updating the init ranges. Here,we either don't update init table (since init is in progress) or miss to update it in time. With these changes of reordering heapReonfig, we will try to set mark bits in place only after check to update init range table. With this, any state transitions resulting in init table not being updated (or being updated to late) will be caught and accounted for as bits will be set after. Signed-off-by: Salman Rana <salman.rana@ibm.com>
RSalman
added a commit
to RSalman/omr
that referenced
this issue
Aug 11, 2021
Fixes eclipse-openj9/openj9#13206 This change switches the order between updating INIT table (tuneToHeap call) and setting mark bits in place. This way, we guarantee that MM bits are set in place when we miss to update INIT table (or it's not updated in time) given overlap of KO and Tenure Expand. The issue being resolved is similar to what has been outlined in a previous issue [eclipse-openj9/openj9#8020 (comment)], where Mark Map Bits get missed for init. Here, we have another similar timing hole, when one thread kicks off concurrent, Concurrent_OFF -> (Concurrent_INIT or INIT Complete), while the expanding thread is in middle of heapReconfigured. With the original ordering of heapReconfigured, we first attempt to set the mark bits in place when Concurrent is ON. With Concurrent_OFF, we delay setting the bits until Concurrent_INIT. This requires update to the init table. Hence, for Concurrent_OFF we forgo setting bits and update the init table, we will expect `tuneToHeap` to do `determineInitRanges` to update init ranges table. The issue occurs when we don't set mark bits in place (given concurrent_OFF) but concurrent starts after the check and prior to updating the init ranges. Here,we either don't update init table (since init is in progress) or miss to update it in time. With these changes of reordering heapReonfig, we will try to set mark bits in place only after check to update init range table. With this, any state transitions resulting in init table not being updated (or being updated to late) will be caught and accounted for as bits will be set after. Signed-off-by: Salman Rana <salman.rana@ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Failure link
https://ci.eclipse.org/openj9/job/Test_openjdk8_j9_extended.system_x86-64_mac_Nightly/213/tapResults/
Optional info
Failure output (captured from console output)
This appears different from #8019.
The text was updated successfully, but these errors were encountered: