Ignored Xjit args do not show up in the IGNOREDARGS list

[gjdeval]

OpenJ9 will only accept one -Xjit:<blah-blah> argument; if more than one -Xjit:<blah-blah> argument is presented on the command line, all but one is ignored. However, the ignored -Xjit arguments are not included in the 1CIIGNOREDARGS Ignored Args: list.

It would be nice if ignored -Xjit arguments were in the list, so that the user or support team could clearly see that not all the -Xjit arguments were actually applied.

[pshipton]

@hzongaro fyi

[hzongaro]

@mpirvu, would this be something for the "control" team to consider?

[mpirvu]

@gjdeval I am not familiar with 1CIIGNOREDARGS but it can get complicated because under -Xjit there are suboptions. So if we do java -Xjit:optionA,optionB -Xjit:optionB,optionC only optionA should appear under the ignored list. This means parsing all -Xjit occurrences and intersecting the sets.
Will you accept a solution where the entire -Xjit:optionA,optionB string appears as ignored?

[gjdeval]

@mpirvu That would probably be an improvement over the current situation. Both (all/any) of the Xjit combinations would appear in the 2CIUSERARG list so the user could compare that list to the 1CIIGNOREDARGS entries.

However, since I opened this issue, another developer brought another complicating factor to my attention, which is the -XX:+MergeCompilerOptions option, which tries to provide a union of functions from multiple -Xjit:<blah-blah> entries. That is nice, but sadly the JVM does not AFAIK report what -Xjit: options are actually active in the JVM after the entries have been merged.

Perhaps rather than 1CIIGNOREDARGS the better solution for Xjit (and Xaot?) would be an entry in the javacore, "Xjit options applied: " which shows what the JVM is actually using? That would be the clearest signal to the user, with no reason for confusion or misunderstanding. And it would probably be the simplest javacore entry to create, since the options to apply must already be determined by the JVM.

[mpirvu]

It's actually not that easy to determine all options in effect because we don't track them and some of them are determined internally (some options, -Xjit: or -XX:, can turn on/off other options).

[gjdeval]

Oh! Well it looks like (not for the first time) I underestimated the implementation complexity - sorry about that. :-)

But that would be the most useful way to let a user (or more likely our support staff) understand what Xjit options are applied.

[mpirvu]

What I propose we do is:

1. If Xjit is followed by -Xint or -Xnojit, then any -Xjit:optionString appears as ignored
2. If XX:+MergeCompilerOptions is present, we don't show anything as ignored.
3. If multiple Xjit string appear, all but the last one will appear as ignored.

Same for -Xaot:

[mpirvu]

I started liberty after adding "-Xshareclasses:name=scc1 -Xshareclasses:name=scc2" to JVM_ARGS and I expected to see -Xshareclasses:name=scc1 in the javacore as ignored, but it's not. I only see:

2CIUSERARG               -Xshareclasses:name=scc1
2CIUSERARG               -Xshareclasses:name=scc2

I have no experience with 1CIIGNOREDARGS, so I don't know if that's expected or not.

[gjdeval]

That is probably another gap in "ignored args" coverage. Originally it applied to -XX:<blah-blah> options mostly I think.
If you want to demo it, try adding -XX:nonsense to the command line.

[gjdeval]

To me, Marius' proposal is OK, at least better than what we have now.

It would be more helpful to be able to say outright what -Xjit or -Xaot options were applied ... but I guess some things in life are not knowable. ;-)

[mpirvu]

Attn: @luke-li-2003