[jdk8u-dev] RFR: 6899049: G1: Clean up code in ptrQueue.[ch]pp and ptrQueue.inline.hpp [v2]
Sun Jianye
jianyesun at openjdk.org
Thu Sep 21 07:51:47 UTC 2023
On Wed, 20 Sep 2023 18:48:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:
> As to the test case itself, it's not clear to me what it's trying to test. Is it the command-line options? Or the actual allocation?
Well, as i described in issue [JDK-8316278](https://bugs.openjdk.org/browse/JDK-8316278) , the crash happends when looking for a element with a special index in PtrQueue's buf during G1GC STAB processing. Therefore, the value of G1SATBBufferSize is related to the size of the heap space or the size of the remaining heap space. We added this test which is already reported by other reporter (ie.see [JDK-8308169](https://bugs.openjdk.org/browse/JDK-8308169)) just to check whether this problem will still be triggered in linux x64. Maybe the test doesn't quite fit.
>Even with a working test, this is not the place to include something new unless it is specific to 8u. If you do want to include it, it needs to be separated from your backport and proposed to https://github.com/openjdk/jdk under its own bug ID. Once included there, it can be backported to 8u, as you have with JDK-6899049 here. Not only do we not want tests being unique to the 8u repository, but changes to the main repository get attention from those who are experts in this field. Stable update trees are generally expected to get fixes that have already been reviewed, but might need some minor modification to work on an older version, and so don't get the same reviewer coverage.
OK, i understand what you mean. Code's version management should really be considered. I have decided to delete the test.
By the way, this backport is clean. Indeed, the risk of index's type conversion is avoided. Therefore it is valuable. What do you think?
We will continue to pay attention to the reasons why other platforms failed to pass in the future. Thanks.
-------------
PR Comment: https://git.openjdk.org/jdk8u-dev/pull/374#issuecomment-1729037709
More information about the jdk8u-dev
mailing list