RFR: 6522873 - Java not print "Unrecognized option" when it is invalid option.
Daniel D. Daugherty
daniel.daugherty at oracle.com
Mon Dec 8 18:40:38 UTC 2014
> Webrev: http://cr.openjdk.java.net/~jwilhelm/6522873/webrev.00/
General: I agree that this should be fixed (again). I think we're
early enough in JDK9 to make this change and deal with any
fall out.
src/share/vm/runtime/arguments.cpp
These are the only lines that caught my eye:
line 3140 } else if (match_option(option, "vfprintf")) {
line 3141 _vfprintf_hook = CAST_TO_FN_PTR(vfprintf_hook_t,
option->extraInfo);
line 3142 } else if (match_option(option, "exit")) {
line 3143 _exit_hook = CAST_TO_FN_PTR(exit_hook_t,
option->extraInfo);
line 3144 } else if (match_option(option, "abort")) {
line 3145 _abort_hook = CAST_TO_FN_PTR(abort_hook_t,
option->extraInfo);
These strange options will not likely make it past the Java
launcher so they must only be available via a JNI invocation.
I'm going to bet that they also worked with the ancient gamma
launcher (that's been removed).
Lines 3140, 3142, and 3144 date back to this Teamware delta:
$ sp -r1.92.7.1 src/share/vm/runtime/arguments.cpp
src/share/vm/runtime/SCCS/s.arguments.cpp:
D 1.92.7.1 99/05/18 11:24:40 renes 227 216 00032/00022/00619
MRs:
COMMENTS:
This delta predates when the HotSpot project used bug IDs
in the delta comments so I can't nail this down to a
specific bug ID (if there was one).
Since the 'extraInfo' field only shows up in jni.h, that supports
that these options can only be used from a JNI invocation:
$ rgrep extraInfo src
src/share/vm/prims/jni.h: void *extraInfo;
src/share/vm/runtime/arguments.cpp:
process_java_launcher_argument(tail, option->extraInfo);
src/share/vm/runtime/arguments.cpp: _vfprintf_hook =
CAST_TO_FN_PTR(vfprintf_hook_t, option->extraInfo);
src/share/vm/runtime/arguments.cpp: _exit_hook =
CAST_TO_FN_PTR(exit_hook_t, option->extraInfo);
src/share/vm/runtime/arguments.cpp: _abort_hook =
CAST_TO_FN_PTR(abort_hook_t, option->extraInfo);
See the JNI spec for JNI_CreateJavaVM() where those options
are discussed, e.g.:
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html#wp16334
Thumbs up on this change!
Dan
On 12/5/14 6:39 AM, Jesper Wilhelmsson wrote:
> Hi,
>
> Please review this patch to make argument parsing stop accepting
> random characters at the end of command line flags. This topic was
> discussed in hotspot-dev at openjdk.java.net and I strongly believe that
> this bug should be reopened and fixed.
>
> Short summary of the problem:
> Today some (not all) flags are accepted even though they have random
> characters appended to them. Some examples are -Xconcgc, -Xcomp,
> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted when
> written for instance -Xconcgcnoway, -Xcomposer, -Xboundthreadstodogs
> or -XX:+AlwaysTenureAtBlueMoon
>
> There is a potential problem here since we will also accept things
> like -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and
> of course without running with G1).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6522873
> Webrev: http://cr.openjdk.java.net/~jwilhelm/6522873/webrev.00/
>
>
> The full list of flags affected by this change is:
>
> -Xnoclassgc
> -Xconcgc
> -Xnoconcgc
> -Xbatch
> -green
> -native
> -Xsqnopause
> -Xrs
> -Xusealtsigs
> -Xoptimize
> -Xprof
> -Xconcurrentio
> -Xinternalversion
> -Xprintflags
> -Xint
> -Xmixed
> -Xcomp
> -Xshare:dump
> -Xshare:on
> -Xshare:auto
> -Xshare:off
> -Xdebug
> -Xnoagent
> -Xboundthreads
> vfprintf
> exit
> abort
> -XX:+AggressiveHeap
> -XX:+NeverTenure
> -XX:+AlwaysTenure
> -XX:+CMSPermGenSweepingEnabled
> -XX:-CMSPermGenSweepingEnabled
> -XX:+UseGCTimeLimit
> -XX:-UseGCTimeLimit
> -XX:+ResizeTLE
> -XX:-ResizeTLE
> -XX:+PrintTLE
> -XX:-PrintTLE
> -XX:+UseTLE
> -XX:-UseTLE
> -XX:+DisplayVMOutputToStderr
> -XX:+DisplayVMOutputToStdout
> -XX:+ExtendedDTraceProbes
> -XX:+FullGCALot
> -XX:+ManagementServer
> -XX:+PrintVMOptions
> -XX:-PrintVMOptions
> -XX:+IgnoreUnrecognizedVMOptions
> -XX:-IgnoreUnrecognizedVMOptions
> -XX:+PrintFlagsInitial
> -XX:+PrintFlagsWithComments
>
>
> Thanks,
> /Jesper
More information about the hotspot-runtime-dev
mailing list