RFR: 8253889: Remove ExecMem constant

David Holmes dholmes at openjdk.java.net
Tue Oct 6 07:32:41 UTC 2020


On Sat, 3 Oct 2020 05:30:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Maybe it did something in the past. Now it just seems to be a complicated way to say "false".
>> 
>> I think that's a Hotspot style. There are few other places where "symbolic values" for boolean parameters are used. For
>> example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const bool'` identify a few more. I personally find it a
>> tad more readable. So, it is not as useless...
>
>> > Maybe it did something in the past. Now it just seems to be a complicated way to say "false".
>> 
>> I think that's a Hotspot style. There are few other places where "symbolic values" for boolean parameters are used. For
>> example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const bool'` identify a few more. I personally find it a
>> tad more readable. So, it is not as useless...
> 
> Well in that case it is applied very inconsistently since most call sites just use false. Lets see if anyone else has
> an opinion on this.

It is a way of documenting the boolean more clearly. This example was introduced by JDK-8013057. In the RFR:

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-June/007617.html

Dan writes:

> As a secondary change, while visiting all os::commit_memory() calls, I also updated them to use the new ExecMem enum in
> order to make the executable status of the memory more clear. Since executable memory can be an attack vector, it is
> prudent to make the executable status of memory crystal clear. This also allowed me to remove the default executable
> flag value of 'false'. Now all new uses of commit_memory() must be clear about the executable status of the memory.

So IMO this is not something that needs changing.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk/pull/454


More information about the hotspot-runtime-dev mailing list