RFR: 6632: Tighten up english rule messages

[Marcus Hirt]

On Thu, 21 Nov 2019 13:02:39 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> On Thu, 21 Nov 2019 13:02:37 GMT, Dan Benamy <github.com+16651846+dbenamydd at openjdk.org> wrote:
> 
>> 6632: Tighten up english rule messages
>> 
>> ----------------
>> 
>> Commits:
>>  - 36815004: Re-add spaces between values and units
>>  - c0bd90f2: Tighten up english rule messages
>> 
>> Changes: https://git.openjdk.java.net/jmc/pull/3/files
>>  Webrev: https://webrevs.openjdk.java.net/jmc/3/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JMC-6632
>>   Stats: 43 lines in 1 file changed: 0 ins; 1 del; 42 mod
>>   Patch: https://git.openjdk.java.net/jmc/pull/3.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jmc pull/3/head:pull/3
> 
> Issue number to refer to is 6632.
> 
> Aside from the project preference to use ISO 31-0 style space between the number and the percent sign, it all looks good to me.
> 
> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties line 58:
> 
>> 57: ApplicationHaltsRule_RULE_TEXT_OK=Application efficiency was not highly affected by halts.
>> 58: 
>> 59: AutoboxingRule_RULE_NAME=Primitive To Object Conversion
> 
> We try to keep a space between value and unit. See https://physics.nist.gov/cuu/Units/checklist.html. See also ISO 31-0.
> 
> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties line 127:
> 
>> 126: CodeCacheRuleFactory_WARN_LONG_DESCRIPTION=This causes the code cache to be swept more frequently, with even higher occupancy causing more frequent sweeps.
>> 127: CodeCacheRuleFactory_WARN_SEGMENTED_HEAP_SHORT_DESCRIPTION=The {0} code heap reached more than 50% occupancy during the recording.
>> 128: CodeCacheRuleFactory_WARN_SEGMENTED_HEAPS_SHORT_DESCRIPTION=The {0} code heaps reached more than 50% occupancy during the recording.
> 
> ISO 31-0.
> 
> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties line 283:
> 
>> 282: # {0} is a memory amount, {1} is a timespan, {2} is a timestamp, {3} is a number, {4} is a memory amount
>> 283: GcFreedRatioRule_RESULT_LONG_DESCRIPTION={0} per second was freed by garbage collections for {1} at {2}. This is {3} times the average liveset which was {4}.
>> 284: GcFreedRatioRule_RESULT_MORE_INFO=If the garbage collector can free a lot of memory, it may be because the application allocates a lot of short lived objects. Investigate the allocation stack traces to see which code paths cause the most allocations, and see if they can be reduced.
> 
> ISO 31-0.
> 
> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties line 332:
> 
>> 331: # {0} is a time period, {1} is a time stamp, {2} is a percentage
>> 332: HighGcRuleFactory_TEXT_INFO=The JVM was paused for {2} of the {0} at {1}.
>> 333: HighGcRuleFactory_TEXT_INFO_LONG=The time spent performing garbage collection may be reduced by increasing the heap size or by trying to reduce allocation.
> 
> ISO 31-0.
> 
> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/resources/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/messages.properties line 615:
> 
>> 614: UnlockExperimentalVMOptionsRuleFactory_TEXT_INFO=The recording was performed on a JVM that had Experimental VM Options enabled.
>> 615: UnlockExperimentalVMOptionsRuleFactory_TEXT_INFO_LONG=Experimental VM options may be unreliable and should not be used in a production environment. Unless you have to use an experimental option, you should avoid the '-XX:+UnlockExperimentalVMOptions' command line option.
>> 616: VMOperations_RULE_NAME=VMOperation Peak Duration
> 
> ISO 31-0.
> 
> ----------------
> 
> Changes requested by hirt (Lead).

Need to update the tests too! :)

PR: https://git.openjdk.java.net/jmc/pull/3