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.

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

8265518: C1: Intrinsic support for Preconditions.checkIndex #3615

Closed
wants to merge 11 commits into from

Conversation

@kelthuzadx
Copy link
Member

@kelthuzadx kelthuzadx commented Apr 22, 2021

The JDK codebase re-created many variants of checkIndex(grep -I -r 'cehckIndex' jdk/). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version.

In fact, there is an utility method jdk.internal.util.Preconditions.checkIndex(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot.

But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later:

  1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase.
  2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag

Testing: cds, compiler and jdk


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8265518: C1: Intrinsic support for Preconditions.checkIndex

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615
$ git checkout pull/3615

Update a local copy of the PR:
$ git checkout pull/3615
$ git pull https://git.openjdk.java.net/jdk pull/3615/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3615

View PR using the GUI difftool:
$ git pr show -t 3615

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3615.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 22, 2021

👋 Welcome back yyang! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

Loading

@openjdk openjdk bot added the rfr label Apr 22, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 22, 2021

@kelthuzadx The following label will be automatically applied to this pull request:

  • hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

Loading

@openjdk openjdk bot added the hotspot label Apr 22, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 22, 2021

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented Apr 22, 2021

/label add hotspot-compiler
/label add nio

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Apr 22, 2021

@kelthuzadx
The hotspot-compiler label was successfully added.

Loading

@openjdk openjdk bot added the nio label Apr 22, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 22, 2021

@kelthuzadx
The nio label was successfully added.

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented Apr 22, 2021

/label add core-libs

Loading

@openjdk openjdk bot added the core-libs label Apr 22, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 22, 2021

@kelthuzadx
The core-libs label was successfully added.

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented Apr 26, 2021

Can I have a review of this PR? Thanks!

Loading

if ((i < 0) || (i >= limit))
throw new IndexOutOfBoundsException();
return i;
return Objects.checkIndex(i, limit);
Copy link
Contributor

@AlanBateman AlanBateman Apr 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing Buffer.checkIndex to use Objects.checkIndex is okay.

Loading

@vnkozlov
Copy link
Contributor

@vnkozlov vnkozlov commented Apr 26, 2021

@veresov please look on C1 changes.

Loading

inline_target->name() == ciSymbols::checkIndex_name()) {
return;
}

Copy link
Contributor

@veresov veresov Apr 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to keep this flag?

Loading

Copy link
Member Author

@kelthuzadx kelthuzadx Apr 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to keep this flag?

Exactly, the flag should be removed.

Thanks,
Yang

Loading

try {
Preconditions.checkIndex(1, 1, null);
} catch (IndexOutOfBoundsException e) {
// got it!
}
Copy link
Member

@dfuch dfuch Apr 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In all places where Precondition.checkIndex is expected to throw, an AssertionError should be generated if it doesn't throw:

        try {
            Preconditions.checkIndex(1, 1, null);
            throw new AssertionError("Expected IndexOutOfBoundsException not thrown");
        } catch (IndexOutOfBoundsException e) {
            // got it!
        }

Loading

Copy link
Member Author

@kelthuzadx kelthuzadx Apr 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it does make sense

Loading

@@ -78,7 +82,8 @@ static void check0() {

try {
// read fields
Preconditions.checkIndex(limit + 1, limit, (s, integers) -> new MyException("Reason:" + s +"::" + integers));
Preconditions.checkIndex(limit + 1, limit, (s, integers) -> new MyException("Reason:" + s + "::" + integers));
throw new AssertionError("Expected IndexOutOfBoundsException not thrown");
Copy link
Member

@dfuch dfuch Apr 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: well maybe here it should be:

throw new AssertionError("Expected MyException not thrown");

Loading


static void check1(int i) {
try {
Preconditions.checkIndex(i, 9999, (s, integers) -> new RuntimeException("ex"));
Copy link
Member

@dfuch dfuch Apr 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe

throw new AssertionError("Expected IndexOutOfBoundsException not thrown");

should be added in check1...check4 as well...

Loading

Copy link
Member Author

@kelthuzadx kelthuzadx Apr 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. They would throw desired exceptions only if i==9999. Nevertheless, I will tweak this test later.

Loading

dfuch
dfuch approved these changes Apr 30, 2021
Copy link
Member

@dfuch dfuch left a comment

Thanks for taking this feedback into account and updating the test!
Note: I only reviewed the test.

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Apr 30, 2021

@kelthuzadx This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8265518: C1: Intrinsic support for Preconditions.checkIndex

Reviewed-by: dfuchs, iveresov

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 142 new commits pushed to the master branch:

  • 4413142: 8268017: C2: assert(phi_type->isa_int() || phi_type->isa_ptr() || phi_type->isa_long()) failed: bad phi type
  • 2bfd708: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be
  • 4d1cf51: 8240349: jlink should not leave partial image output directory on failure
  • 07108c9: 8268241: deprecate JVM TI Heap functions 1.0
  • c9dbc4f: 8266891: Provide a switch to force the class space to a specific location
  • 2cc1977: 8268424: JFR tests fail due to GC cause 'G1 Preventive Collection' not in the valid causes after JDK-8257774
  • 58a59e3: 8240997: Remove more "hack" word in security codes
  • 1c3932f: 8264766: ClassCastException during template compilation (Variable cannot be cast to Param)
  • f6f82c3: 8266421: Deadlock in Sound System
  • bcaa2cb: 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages
  • ... and 132 more: https://git.openjdk.java.net/jdk/compare/379376f0783facba93e1d11db9b184ef8183a13b...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

Loading

@openjdk openjdk bot added the ready label Apr 30, 2021
@PaulSandoz
Copy link
Member

@PaulSandoz PaulSandoz commented Apr 30, 2021

It was my hope this would eventually happen when we added Objects.checkIndex and the underlying intrinsic. Very good!

Loading

@veresov
Copy link
Contributor

@veresov veresov commented Apr 30, 2021

Looks like now the test fails in the pre-submit tests?

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented May 8, 2021

It was my hope this would eventually happen when we added Objects.checkIndex and the underlying intrinsic. Very good!

Hi Paul,

Thank you for noticing this PR.

It was my hope this would eventually happen when we added Objects.checkIndex and the underlying intrinsic.
Yes, this patch adds C1 intrinsic supports for checkIndex, I will replace all variants of checkIndex with Objects.checkIndex in follow-up PRs.

It seems that Object.checkIndex can not meet our needs because it implicitly passes null to Preconditions.checkIndex, but we want to customize exception messages, so we might add extra APIs in Objects while doing the replacement.

Very good!
Thank you Paul~

Best Regards,
Yang

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented May 8, 2021

Looks like now the test fails in the pre-submit tests?

Hi Igor,

Can you take a look at the latest version? Now it passes all pre-submit tests.

Best Regards,
Yang

Loading

@PaulSandoz
Copy link
Member

@PaulSandoz PaulSandoz commented May 8, 2021

It seems that Object.checkIndex can not meet our needs because it implicitly passes null to Preconditions.checkIndex, but we want to customize exception messages, so we might add extra APIs in Objects while doing the replacement.

It might be possible to directly use Preconditions.checkIndex for such purposes, its package is non-exported but public for reuse within java.base. It's used in VarHandle byte array access code, see here.

I would caution against adding a public API to support this. The work in Preconditions was the basis for a public API, but it proved complicated. I am glad we did not expose that, it would of made exposing the long accepting Objects.checkIndex methods more difficult.

Paul.

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented May 25, 2021

Hi @veresov, may I ask your help to review this patch? Thanks a lot.

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented May 25, 2021

Thank you @veresov!

I'm glad to have more comments from hotspot-compiler group.

Later, I'd like to integrate it if there are no more comments/objections.

Thanks!
Yang

Loading

@openjdk openjdk bot added ready and removed merge-conflict labels Jun 2, 2021
@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented Jun 3, 2021

@veresov I've rebased to the latest commit and resolved all conflicts. Please take a look at this. Thank you!

Loading

@veresov
Copy link
Contributor

@veresov veresov commented Jun 3, 2021

test/jdk/java/util/Objects/CheckIndex.java and test/jdk/java/util/Objects/CheckLongIndex.java started failing. Please take a look.

test CheckIndex.testCheckIndex(0, -2147483647, false): failure
java.lang.AssertionError: Index 0 is out of bounds of [0, -2147483647), but was reported to be within bounds
	at org.testng.Assert.fail(Assert.java:94)
	at CheckIndex.lambda$testCheckIndex$3(CheckIndex.java:103)
	at CheckIndex.testCheckIndex(CheckIndex.java:117)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)
test CheckIndex.testCheckIndex(0, -2147483648, false): failure
java.lang.AssertionError: Index 0 is out of bounds of [0, -2147483648), but was reported to be within bounds
	at org.testng.Assert.fail(Assert.java:94)
	at CheckIndex.lambda$testCheckIndex$3(CheckIndex.java:103)
	at CheckIndex.testCheckIndex(CheckIndex.java:120)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)
test CheckIndex.testCheckIndex(1, -1, false): failure
java.lang.AssertionError: Index 1 is out of bounds of [0, -1), but was reported to be within bounds
	at org.testng.Assert.fail(Assert.java:94)
	at CheckIndex.lambda$testCheckIndex$3(CheckIndex.java:103)
	at CheckIndex.testCheckIndex(CheckIndex.java:130)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)

Loading

@veresov
Copy link
Contributor

@veresov veresov commented Jun 11, 2021

Alright, tests pass now. I think we're good to go.

Loading

@veresov
Copy link
Contributor

@veresov veresov commented Jun 11, 2021

/sponsor

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Jun 11, 2021

@veresov This change does not need sponsoring - the author is allowed to integrate it.

Loading

@veresov
Copy link
Contributor

@veresov veresov commented Jun 11, 2021

I guess you need to do the "integrate" command again.

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented Jun 12, 2021

I guess you need to do the "integrate" command again.

Okay,thank you all for taking time to look at this

/integrate

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Jun 12, 2021

Going to push as commit 5cee23a.
Since your change was applied there have been 204 commits pushed to the master branch:

  • a466b49: 8267634: Update --release 17 symbol information for JDK 17 build 26
  • 49112fa: 8265909: build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home
  • 94d0b0f: 8268565: runtime/records/RedefineRecord.java should be run in driver mode
  • df65237: 8267930: Refine code for loading hsdis library
  • 2e900da: 8268574: ProblemList tests failing due to UseBiasedLocking going away
  • 4fd2a14: 8267556: Enhance class paths check during runtime
  • 8c8422e: 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes
  • 1e1039a: 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java
  • 78cb677: 8268539: several serviceability/sa tests should be run in driver mode
  • 7267227: 8268361: Fix the infinite loop in next_line
  • ... and 194 more: https://git.openjdk.java.net/jdk/compare/379376f0783facba93e1d11db9b184ef8183a13b...master

Your commit was automatically rebased without conflicts.

Loading

@openjdk openjdk bot closed this Jun 12, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jun 12, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 12, 2021

@kelthuzadx Pushed as commit 5cee23a.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Loading

@kelthuzadx kelthuzadx deleted the consolidate_checkindex branch Jun 12, 2021
@simonis
Copy link
Member

@simonis simonis commented Jun 12, 2021

This change removed a product flag so I wonder how it could be integrated without a CSR?

Loading

@tstuefe
Copy link
Member

@tstuefe tstuefe commented Jun 12, 2021

This change removed a product flag so I wonder how it could be integrated without a CSR?

And if the intention was to remove it, should it not have been marked as obsolete first?

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented Jun 12, 2021

This change removed a product flag so I wonder how it could be integrated without a CSR?

It's a diagnostic product flag, so it’ okay to remove it without issuing CSR. But I am not 100% sure.

@dholmes-ora, do you have any comment about this? Thanks!

Loading

@simonis
Copy link
Member

@simonis simonis commented Jun 12, 2021

Loading

@tstuefe
Copy link
Member

@tstuefe tstuefe commented Jun 12, 2021

Hi Yi,

you may need to add the option to the obsolete-flags-table though as described in arguments.cpp:

* To remove internal options (e.g. diagnostic, experimental, develop options), use
* a 2-step model adding major release numbers to the obsolete and expire columns.

I think the point is to give a customer a grace period where the option is still accepted on the command line. I am not sure if that step is optional though, if one is reasonably sure that the option is unused. Maybe @dholmes-ora can chime in.

Cheers, Thomas

Loading

@kelthuzadx
Copy link
Member Author

@kelthuzadx kelthuzadx commented Jun 15, 2021

Hi Yi,

you may need to add the option to the obsolete-flags-table though as described in arguments.cpp:

* To remove internal options (e.g. diagnostic, experimental, develop options), use
* a 2-step model adding major release numbers to the obsolete and expire columns.

I think the point is to give a customer a grace period where the option is still accepted on the command line. I am not sure if that step is optional though, if one is reasonably sure that the option is unused. Maybe @dholmes-ora can chime in.

Cheers, Thomas

Hi Thomas,

I think what you said is right. It does not take too much time to do this but it can give users a smooth transition for unavailable options! I will create a new PR to do this stuff if there are no objections.

Thanks,
Yang

Loading

@veresov
Copy link
Contributor

@veresov veresov commented Jun 15, 2021

It's up to you, we can of course print a warning that the flag has been removed. In my opinion, we shouldn't waste time on this, that was an obscure non-product flag.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment