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

Dmitry Dmitriev dmitry.dmitriev at oracle.com
Tue Sep 29 12:21:12 UTC 2015


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


More information about the hotspot-runtime-dev mailing list