RFR (M): 8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing

[gerard ziemski]

hi Dmitry,

You are absolutely right. It was pointed out to me already that those unused value may in fact be used. I believe I will 
go with a 0xffffffff constant here since it's a bit flag value.


cheers

On 09/29/2015 07:21 AM, Dmitry Dmitriev wrote:
> Hi Gerard,
>
> Thank you for fixing that! One comment inline:
>
> On 28.09.2015 21:12, gerard ziemski wrote:
>>
>>> 4) I think that max range for "TraceRedefineClasses" should be "max_juint" instead of "0x80000000". Each bit in
>>> TraceRedefineClasses defines event to trace, here a part of the
>>> hotspot/src/share/vm/prims/jvmtiRedefineClassesTrace.hpp(lines 38-74):
>>> //    0x00000000 |          0 - default; no tracing messages
>>> //    0x00000001 |          1 - name each target class before loading, after
>>> //                              loading and after redefinition is completed
>>> ...
>>> //    0x00000010 |         16 - unused
>>> //    0x00000020 |         32 - unused
>>> //    0x00000040 |         64 - unused
>>> //    0x00000080 |        128 - unused
>>> //    0x00000100 |        256 - previous class weak reference addition
>>> //    0x00000200 |        512 - previous class weak reference mgmt during
>>> //                              class unloading checks (GC)
>>> ...
>>> //    0x40000000 | 1073741824 - unused
>>> //    0x80000000 | 2147483648 - unused
>>>
>>> Thus "0x80000000 == unused" mean that this bit just currently not used.
>>>
>>
>> We know the range max can not be bigger than that (yes it's a bit value, but also bigger than all flags turned ON), so
>> why not use the biggest >>known<< value here?
> If you want to leave max range as "0x80000000" I'm okay with that :) My point is that "0x80000000" is a valid, but
> unused value and if someone will try to use that bit in future, then he should also revise max range.
>
> Thanks,
> Dmitry
>