Implemented apple.awt.windowTitleVisible property to control window title visibility

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8265005: Introduce the new client property for mac: apple.awt.windowTitleVisible

Reviewers

• Sergey Bylokhov (@mrserb - Reviewer)

Reviewing

Greetings,

please help review this enhancement to let JFR sample object allocations by default.

A description is provided in the JIRA issue.

Thanks Markus

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8257602: Introduce JFR Event Throttling and new jdk.ObjectAllocationSample event (enabled by default)

Reviewers

• Erik Gahlin (@egahlin - Reviewer)
• Jaroslav Bachorik (@jbachorik - Reviewer)

Contributors

• Jaroslav Bachorik <[email protected]>

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1624/head:pull/1624 $ git checkout pull/1624

Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size.

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8256155: Allow multiple large page sizes to be used on Linux

Reviewers

• Thomas Stuefe (@tstuefe - Reviewer)
• Stefan Johansson (@kstefanj - Reviewer)

Contributors

• Marcus G K Williams <[email protected]>
• Stefan Johansson <[email protected]>
• Thomas Stuefe <[email protected]>

Reviewing

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8252842: Extend JMap to support parallel heap dump

Reviewers

• Ralf Schmelter (@schmelter-sap - Committer)
• Chris Plummer (@plummercj - Reviewer) ⚠️ Review applies to 6d8e944f3ec7cf1a6870f2f59e4433fcd8252946

Reviewing

Please review the implementation of JEP 391: macOS/AArch64 Port.

It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64.

Major changes are in:

• src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
• src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
• src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
• src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issues

• JDK-8253795: Implementation of JEP 391: macOS/AArch64 Port
• JDK-8253816: Support macOS W^X
• JDK-8253817: Support macOS Aarch64 ABI in Interpreter
• JDK-8253818: Support macOS Aarch64 ABI for compiled wrappers
• JDK-8253819: Implement os/cpu for macOS/AArch64
• JDK-8253839: Update tests and JDK code for macOS/Aarch64
• JDK-8254941: Implement Serviceability Agent for macOS/AArch64
• JDK-8255776: Change build system for macOS/AArch64
• JDK-8262903: [macos_aarch64] Thread::current() called on detached thread

Reviewers

• Erik Joelsson (@erikj79 - Reviewer) ⚠️ Review applies to 5add92694acc27de74b13368d93dd525f092039b
• Magnus Ihse Bursie (@magicus - Reviewer) ⚠️ Review applies to 5add92694acc27de74b13368d93dd525f092039b
• Phil Race (@prrace - Reviewer) ⚠️ Review applies to ab72613cf5a9790dbc96199030bfad01f01b6402
• Chris Plummer (@plummercj - Reviewer) ⚠️ Review applies to 0c2cb0a372bf1a8607810d773b53d6959616a816
• Stefan Karlsson (@stefank - Reviewer) ⚠️ Review applies to f6fb01b24f525e578692a1c6f2ff0a55b8233576
• Gerard Ziemski (@gerard-ziemski - Committer) ⚠️ Review applies to ab72613cf5a9790dbc96199030bfad01f01b6402
• Andrew Haley (@theRealAph - Reviewer) ⚠️ Review applies to 5add92694acc27de74b13368d93dd525f092039b
• Monica Beckwith (@mo-beck - Author) ⚠️ Review applies to 5add92694acc27de74b13368d93dd525f092039b
• Ludovic Henry (@luhenry - Author) ⚠️ Review applies to 5add92694acc27de74b13368d93dd525f092039b

Contributors

• Vladimir Kempik <[email protected]>
• Bernhard Urban-Forster <[email protected]>
• Ludovic Henry <[email protected]>
• Monica Beckwith <[email protected]>

Download

To checkout this PR locally: $ git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200 $ git checkout pull/2200

To update a local copy of the PR: $ git checkout pull/2200 $ git pull https://git.openjdk.java.net/jdk pull/2200/head

Hello,

here's a PR for a patch submitted on March 2020 1 when Mercurial was a thing.

The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.

Greetings Raffaello

Progress

• [x] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change requires a CSR request to be approved

Issues

• JDK-4511638: Double.toString(double) sometimes produces incorrect results
• JDK-8202555: Double.toString(double) sometimes produces incorrect results (CSR)

Reviewers

• Andrey Turbanov (@turbanoff - Committer) ⚠️ Review applies to c29dff76
• @limck599 (no known github.com user name / role) ⚠️ Review applies to 907abfd6
• Joe Darcy (@jddarcy - Reviewer)
• Brian Burkhalter (@bplb - Reviewer)

Reviewing

This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp

Naming is hard, but I think the following scheme is reasonable:

• log2i: any integral type. 0-hostile
• log2i_allow_zero: any integral type. gracefully handles zero (adds a branch)
• exact_log2i: any integral type. value must be a power of two

I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries.

Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch.

To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values:

[ RUN      ] power_of_2.log2_long_micro
[       OK ] power_of_2.log2_long_micro (3581 ms)
[ RUN      ] power_of_2.log2_long_small_micro
[       OK ] power_of_2.log2_long_small_micro (549 ms)
[ RUN      ] power_of_2.log2i_micro
[       OK ] power_of_2.log2i_micro (259 ms)
[ RUN      ] power_of_2.log2i_small_micro
[       OK ] power_of_2.log2i_small_micro (113 ms)

I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W

(Intending this for 17)

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8257815: Replace global log2 functions with efficient implementations

Reviewers

• Kim Barrett (@kimbarrett - Reviewer) ⚠️ Review applies to e21e1b7abaf5dbd2788254e92145cf050feac3e6
• Stefan Karlsson (@stefank - Reviewer) ⚠️ Review applies to e2332fb1a9792ecf03441cc686e4f798ca339ee5

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 $ git checkout pull/1663

Add a new --source-date (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.

Signed-off-by: Andrew Leonard [email protected]

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed
• [x] Change requires a CSR request to be approved

Issues

• JDK-8276766: Enable jar and jmod to produce deterministic timestamped content
• JDK-8277755: Enable jar and jmod to produce deterministic timestamped content (CSR)

Reviewers

• Magnus Ihse Bursie (@magicus - Reviewer) ⚠️ Review applies to 6d3724368c48996db72e2120fd4951140f34dba2
• Lance Andersen (@LanceAndersen - Reviewer) ⚠️ Review applies to 0a69d014b2f4df51d9a9e7e542250f8d1381fd77
• Alan Bateman (@AlanBateman - Reviewer) ⚠️ Review applies to 59617359730268436daef813d4c861ca303ae11b
• John Neffenger (@jgneff - no project role) ⚠️ Review applies to 290a4903b79a5d517e550d3c839d19428f6b0699

Reviewing

This reimplements core reflection with method handles.

For Constructor::newInstance and Method::invoke, the new implementation uses MethodHandle. For Field accessor, the new implementation uses VarHandle. For the first few invocations of one of these reflective methods on a specific reflective object we invoke the corresponding method handle directly. After that we spin a dynamic bytecode stub defined in a hidden class which loads the target MethodHandle or VarHandle from its class data as a dynamically computed constant. Loading the method handle from a constant allows JIT to inline the method-handle invocation in order to achieve good performance.

The VM's native reflection methods are needed during early startup, before the method-handle mechanism is initialized. That happens soon after System::initPhase1 and before System::initPhase2, after which we switch to using method handles exclusively.

The core reflection and method handle implementation are updated to handle chained caller-sensitive method calls [1] properly. A caller-sensitive method can define with a caller-sensitive adapter method that will take an additional caller class parameter and the adapter method will be annotated with @CallerSensitiveAdapter for better auditing. See the detailed description from [2].

Ran tier1-tier8 tests.

[1] https://bugs.openjdk.java.net/browse/JDK-8013527 [2] https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issues

• JDK-8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle
• JDK-8013527: calling MethodHandles.lookup on itself leads to errors

Reviewers

• Maurizio Cimadamore (@mcimadamore - Reviewer) ⚠️ Review applies to c25d651a3f251a78e3c77f3e0b3c027dee3a6224
• Peter Levart (@plevart - Reviewer) ⚠️ Review applies to 86d34f482c257053d6315e2fa87c1634a2c65def
• Erik Gahlin (@egahlin - Reviewer) ⚠️ Review applies to 86d34f482c257053d6315e2fa87c1634a2c65def
• Claes Redestad (@cl4es - Reviewer) ⚠️ Review applies to 86d34f482c257053d6315e2fa87c1634a2c65def
• Chris Plummer (@plummercj - Reviewer) ⚠️ Review applies to c25d651a3f251a78e3c77f3e0b3c027dee3a6224
• Alan Bateman (@AlanBateman - Reviewer)

Contributors

• Peter Levart <[email protected]>
• Claes Redestad <[email protected]>
• Mandy Chung <[email protected]>

Reviewing

Changed the drawing area to be increased by 0.5 on the left side to prevent clipping

Progress

• [x] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8279614: The left line of the TitledBorder is not painted on 150 scale factor

Reviewers

• Alexander Zuev (@azuev-java - Reviewer) ⚠️ Review applies to 7b7732f8
• Alexey Ivanov (@aivanov-jdk - Reviewer)
• Phil Race (@prrace - Reviewer) ⚠️ Review applies to 325d09b4

Contributors

• Alexey Ivanov <[email protected]>

Reviewing

This patch provides a buffer to store asynchrounous messages and flush them to underlying files periodically.

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change must be properly reviewed

Issue

• JDK-8229517: Support for optional asynchronous/buffered logging

Reviewers

• Yasumasa Suenaga (@YaSuenag - Reviewer)
• Volker Simonis (@simonis - Reviewer)
• Thomas Stuefe (@tstuefe - Reviewer) ⚠️ Review applies to 348edfc0e822677aec20269d4553fb8f9f9cd589
• Paul Hohensee (@phohensee - Reviewer)
• David Holmes (@dholmes-ora - Reviewer)
• Albert Mingkun Yang (@albertnetymk - Committer)

Reviewing

After this change we will set correct pixel formatter when we initially create it, instead of updating the pixel formatter in native based on additional "isIntPacked" flag.

FYI: The fix for https://bugs.openjdk.org/browse/JDK-7124245 added the "isIntPacked" flag to mark the non-byte pixels layouts(like TYPE_INT_RGB).

• This flag is passed around even if it is not used by the pixel layout
• It may cause unnecessary creation of new transform if one type is "rgb && isIntPacked=true" and another one is "bgr && isIntPacked=false", but the actual data is the same see: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/2cf07dbdee64

Progress

• [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8299425: "LCMSImageLayout.isIntPacked" flag can be deleted

Reviewing

On the old SLES12 ppc64le machine we do not have memory.memsw.limit_in_bytes : ls -alL /sys/fs/cgroup/memory/memory.memsw.limit_in_bytes ls: cannot access /sys/fs/cgroup/memory/memory.memsw.limit_in_bytes: No such file or directory

This leads to

[0.163s][trace][os,container] Memory and Swap Limit is: 18446744073709551614 memory_and_swap_limit_in_bytes: not supported

And the check in containers/docker/TestMemoryWithCgroupV1.java fails :

java.lang.RuntimeException: 'Memory and Swap Limit is: 157286400' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221) at TestMemoryWithCgroupV1.testMemoryLimitWithSwappiness(TestMemoryWithCgroupV1.java:88) at TestMemoryWithCgroupV1.main(TestMemoryWithCgroupV1.java:61) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:1623)

Probably we should handle this situation and check for "memory_and_swap_limit_in_bytes: not supported" or something similar .

Progress

• [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8299424: containers/docker/TestMemoryWithCgroupV1.java fails on SLES12 ppc64le when testing Memory and Swap Limit

Reviewing

Hi,

This change introduces a heuristic in order to ensure that the asynchronous logging buffer is saturated more often. Before this change the logger often wrote single messages to the output, now it outputs singificantly more data at a time. I also believe that less uses of notify() means that the performance implication of using asynchronous logging is improved. Running stat perf consistently shows a smaller amount of context switches when run with this change, which supports this hypothesis.

The asynchronous logging tests was run and passed with:

_JAVA_OPTIONS='-Xlog:async' make CONF=linux-x64 test TEST='gtest:*Async*'

The choice of a ratio of 30% and a timeout of 1 second isn't based on data. It seemed reasonable that waiting 1 second for your sole log message is acceptable and that 30% is enough to not cause any message drops.

Data

All invocations of the JVM were run with -Xlog:async -Xlog:all=trace:file=logs.txt

As a measurement of buffer usage I logged the current number of messages and size of the buffer each time AsyncLogWriter::write(). Below I present how often AsyncLogWriter::write() was called with a certain number of messages in the buffer. For example, 1: 11 is read "AsyncLogWriter::write() was called with 1 message in the buffer 11 times".

Before:

message_count : occurrence_count
1 : 11
2 : 6
3 : 294
4 : 8
5 : 10
6 : 47
7 : 4
8 : 1
9 : 28
10 : 2
11 : 2
12 : 14
15 : 5
18 : 3
19 : 1
20 : 1
21 : 1
22 : 1
26 : 2
27 : 3
30 : 2
33 : 1
36 : 1
37 : 1
50 : 1
62 : 1
63 : 1
75 : 1
207 : 1
231 : 1
1395 : 1
2724 : 1
2789 : 1
3212 : 1
3278 : 1
3503 : 1
4069 : 1
4231 : 1
4305 : 1
4712 : 1
5640 : 1
5864 : 1
5912 : 1
5943 : 1
6096 : 1
6144 : 1
6204 : 1
6220 : 1
6222 : 1
6226 : 1
6268 : 1
6278 : 1
6302 : 1
6309 : 1
6339 : 1
6343 : 1
6369 : 1
6379 : 1
6439 : 1
6472 : 1
6516 : 1
6602 : 1
6714 : 1
6834 : 1
7078 : 1
7475 : 1

Call count Sum: 491

After

2002 : 1
2572 : 1
2821 : 1
3279 : 1
5003 : 1
5226 : 1
5749 : 1
5771 : 1
5803 : 1
5979 : 1
6011 : 1
6103 : 1
6140 : 1
6201 : 1
6252 : 1
6265 : 1
6266 : 1
6271 : 1
6288 : 1
6336 : 1
6360 : 1
6373 : 1
6451 : 1
6473 : 1
6515 : 1
6582 : 1
6600 : 1
6774 : 1
7228 : 1

Call count sum: 29

I ran the following command multiple times for gaining CPU counter information: sudo perf stat -ddd ./build/linux-x64/jdk/bin/java -Xlog:async -Xlog:all=trace:file=logz.txt. A before and after sample is provided below. See context-switches in particular.

Before:

                 5 568,53 msec task-clock                #    2,852 CPUs utilized
             1 481      context-switches          #  265,959 /sec
               139      cpu-migrations            #   24,962 /sec
            17 148      page-faults               #    3,079 K/sec
     7 492 468 406      cycles                    #    1,346 GHz                      (39,34%)
    11 820 424 570      instructions              #    1,58  insn per cycle           (46,99%)
     2 497 513 512      branches                  #  448,505 M/sec                    (54,60%)
        23 018 472      branch-misses             #    0,92% of all branches          (62,21%)
    26 465 666 080      slots                     #    4,753 G/sec                    (69,82%)
     9 638 436 928      topdown-retiring          #     33,4% retiring                (69,82%)
    10 041 432 678      topdown-bad-spec          #     34,8% bad speculation         (69,82%)
     8 310 642 872      topdown-fe-bound          #     28,8% frontend bound          (69,82%)
       879 846 428      topdown-be-bound          #      3,0% backend bound           (69,82%)
     3 339 457 604      L1-dcache-loads           #  599,702 M/sec                    (69,38%)
        92 744 182      L1-dcache-load-misses     #    2,78% of all L1-dcache accesses  (69,35%)
         5 575 831      LLC-loads                 #    1,001 M/sec                    (69,32%)
         1 173 449      LLC-load-misses           #   21,05% of all LL-cache accesses  (69,30%)
   <not supported>      L1-icache-loads
       339 072 313      L1-icache-load-misses                                         (30,94%)
     3 319 520 527      dTLB-loads                #  596,121 M/sec                    (31,19%)
           637 308      dTLB-load-misses          #    0,02% of all dTLB cache accesses  (31,38%)
   <not supported>      iTLB-loads
         3 026 652      iTLB-load-misses                                              (31,65%)
   <not supported>      L1-dcache-prefetches
   <not supported>      L1-dcache-prefetch-misses

       1,952442620 seconds time elapsed

       4,277701000 seconds user
       1,303833000 seconds sys

After:

          5 344,15 msec task-clock                #    2,867 CPUs utilized
               994      context-switches          #  185,998 /sec
               101      cpu-migrations            #   18,899 /sec
            16 902      page-faults               #    3,163 K/sec
     7 220 944 481      cycles                    #    1,351 GHz                      (39,36%)
    11 277 945 316      instructions              #    1,56  insn per cycle           (47,12%)
     2 371 729 681      branches                  #  443,799 M/sec                    (54,73%)
        22 683 816      branch-misses             #    0,96% of all branches          (62,18%)
    24 913 623 884      slots                     #    4,662 G/sec                    (69,76%)
     9 354 630 464      topdown-retiring          #     34,6% retiring                (69,76%)
     9 339 435 252      topdown-bad-spec          #     34,5% bad speculation         (69,76%)
     7 563 625 485      topdown-fe-bound          #     27,9% frontend bound          (69,76%)
       815 220 376      topdown-be-bound          #      3,0% backend bound           (69,76%)
     3 209 639 698      L1-dcache-loads           #  600,589 M/sec                    (69,62%)
        89 008 704      L1-dcache-load-misses     #    2,77% of all L1-dcache accesses  (69,55%)
         5 369 924      LLC-loads                 #    1,005 M/sec                    (69,16%)
         1 093 971      LLC-load-misses           #   20,37% of all LL-cache accesses  (69,32%)
   <not supported>      L1-icache-loads
       323 572 438      L1-icache-load-misses                                         (30,75%)
     3 096 980 739      dTLB-loads                #  579,509 M/sec                    (31,33%)
           616 949      dTLB-load-misses          #    0,02% of all dTLB cache accesses  (31,46%)
   <not supported>      iTLB-loads
         2 741 468      iTLB-load-misses                                              (31,51%)
   <not supported>      L1-dcache-prefetches
   <not supported>      L1-dcache-prefetch-misses

       1,864260247 seconds time elapsed

       4,129709000 seconds user
       1,225694000 seconds sys

Progress

• [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8299415: Saturate the async log buffer more often

Reviewing

[CommonComponentAccessibility getActionsWithEnv:] defines the getAccessibleActionCount method on the AccessibleAction class, however the call should go through CAccessibility so that it is executed on the Event Dispatch thread.

@azuev-java @mrserb @prrace please review

Progress

• [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8299412: JNI call of getAccessibleActionCount on a wrong thread

Reviewers

• @SWinxy (no known github.com user name / role)

Reviewing

Code cleanup of pre-C++11 <type_traits> implementations.

Progress

• [x] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8299397: Remove metaprogramming/isFloatingPoint.hpp

Reviewers

• Kim Barrett (@kimbarrett - Reviewer)

Reviewing

Code cleanup of pre-C++11 <type_traits> implementations.

Progress

• [x] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue

Issue

• JDK-8299402: Remove metaprogramming/isVolatile.hpp

Reviewers

• Kim Barrett (@kimbarrett - Reviewer)

Reviewing