RFR: 8306851: Move Method access flags [v3]
Matias Saavedra Silva
matsaave at openjdk.org
Fri Apr 28 14:32:53 UTC 2023
On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access.
>>
>> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign.
>>
>> Tested with tier1-6, and some manual verification of printing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>
> Remove bool argument from ConstMethodFlags.set function.
Nice change! Just some small nits but it otherwise looks good.
src/hotspot/share/oops/method.hpp line 606:
> 604:
> 605: bool compute_has_loops_flag();
> 606: bool set_has_loops() { set_has_loops_flag(); set_has_loops_flag_init(); return true; }
Since this has multiple statements it should probably be on different lines
src/hotspot/share/oops/method.hpp line 615:
> 613: // has not been computed yet.
> 614: bool guaranteed_monitor_matching() const { return monitor_matching(); }
> 615: void set_guaranteed_monitor_matching() { set_monitor_matching(); }
Is this method just obsolete now? If so it might be worth replacing the callers with `set_monitor_matching()` unless `set_monitor_matching()` is still meant to be private.
-------------
Changes requested by matsaave (Committer).
PR Review: https://git.openjdk.org/jdk/pull/13654#pullrequestreview-1406036462
PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1180462644
PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1180472698
More information about the serviceability-dev
mailing list