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