RFR(M): 8245226: Clean-up FlagSetting and remove misuse.

Patric Hedlin patric.hedlin at oracle.com
Thu Jul 9 11:56:52 UTC 2020


Hi David,

On 2020-07-09 11:09, David Holmes wrote:
> Hi Patric,
>
> On 9/07/2020 5:17 am, Patric Hedlin wrote:
>> Dear all,
>>
>> I would like to ask for help to review the following change/update:
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245226
>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8245226/
>>
>>
>> FlagSetting is sometimes used as a general mechanism for local 
>> save/modify and restore. This is not the intention (it should work as 
>> a red-flag when modifying debug options). Instead, use a general 
>> mechanism in these cases (introduced in here), and preserve 
>> FlagSetting for its intended purpose (including clean-up).
>
> Sorry but I'm not seeing why FlagSetting can't be used as a general 
> mechanism even though it is described as being for debug flags. 
> Introducing a similar mechanism seems redundant to me.
>

Let me ask you this. How well do you think 'FlagSetting' describes the 
actual operation performed in the general use-case? Is it more clear 
than explicitly stating that you intend a save/modify and a restore in 
the local context? It is not as much about if it can be used as it is 
about if it should be used. The use of 'FlagSetting' and friends should 
be moved aside, given a new name (signalling the thin ice you are 
entering) and restricted to use on admissible flag/options only. I'm 
assuming you agree that modifying global options might have undesirable 
effects. But that can wait until after, or be part of, the rework. This 
part is about separating the use-cases. If you feel strongly about 
preserving 'FlagSetting' (and friends), please make your argument based 
on the merits of the current concept and implementation (such as the use 
of memcpy), not a dismissive "I don't see the point".


/Patric



More information about the hotspot-dev mailing list