RFR: Two line change in documentation
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Tue Mar 13 21:32:42 UTC 2018
Hi Jc,
Yes, these are typos.
Thank you for fixing them!
Is it a formal review request (RFR) ?
If so, then a bug number is needed.
I've filed one:
https://bugs.openjdk.java.net/browse/JDK-8199561
The fix looks good.
I think, this can be fixed under a trivial fix rule with just one review.
I'll sponsor it for you.
Thanks,
Serguei
On 3/13/18 10:37, JC Beyler wrote:
> Hi all,
>
> I saw an error in the SetEventNotificationMode method where the
> parameter is called event_thread but the documentation was referring
> to it as thread. I then went and did a quick scan of the documentation
> and found one type of "couse" instead of "course".
>
> Here is the diff, not sure it was worth doing a webrev for it but let
> me know:
> diff -r 2d1d0c66966b src/hotspot/share/prims/jvmti.xml
> --- a/src/hotspot/share/prims/jvmti.xmlMon Mar 12 14:11:54 2018 -0700
> +++ b/src/hotspot/share/prims/jvmti.xmlTue Mar 13 10:35:03 2018 -0700
> @@ -693,7 +693,7 @@
> mechanism causes the unload (an unload mechanism is not specified
> in this document)
> or the library is (in effect) unloaded by the termination of the
> VM whether through
> normal termination or VM failure, including start-up failure.
> - Uncontrolled shutdown is, of couse, an exception to this rule.
> + Uncontrolled shutdown is, of course, an exception to this rule.
> Note the distinction between this function and the
> <eventlink id="VMDeath">VM Death event</eventlink>: for the VM
> Death event
> to be sent, the VM must have run at least to the point of
> initialization and a valid
> @@ -9405,7 +9405,7 @@
> the event <paramlink id="event_type"></paramlink> will be disabled
> </constant>
> </constants>
> -If <code>thread</code> is <code>NULL</code>,
> +If <code>event_thread</code> is <code>NULL</code>,
> the event is enabled or disabled globally; otherwise, it is
> enabled or disabled for a particular thread.
> An event is generated for
>
> Thanks,
> Jc
More information about the serviceability-dev
mailing list