RFR: 8261125: Move VM_Operation to vmOperation.hpp [v3]

Ioi Lam iklam at openjdk.java.net
Thu Feb 11 06:57:39 UTC 2021


On Thu, 11 Feb 2021 03:56:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I'm fine with leaving vmOperations.hpp and vmOperation.hpp.  It's not a big deal.  commonVMOperations.hpp - too much noise!
>> I agree with David.  interfaceSupport.inline.hpp imports a lot of things so importing vmOperations.hpp is not a big deal.  vmOperations.hpp imports #include "runtime/threadSMR.hpp" otherwise it has all the same imports as interfaceSupport.inline.hpp anyway.
>> All these files are going to increase compilation time too.
>> I stand by my check mark above!
>
>> I'm fine with leaving vmOperations.hpp and vmOperation.hpp. It's not a big deal. commonVMOperations.hpp - too much noise!
>> I agree with David. interfaceSupport.inline.hpp imports a lot of things so importing vmOperations.hpp is not a big deal. vmOperations.hpp imports #include "runtime/threadSMR.hpp" otherwise it has all the same imports as interfaceSupport.inline.hpp anyway.
>> All these files are going to increase compilation time too.
>> I stand by my check mark above!
> 
> OK, since no one is fond of further splitting the headers, and no one has vetoed the vmOperation.hpp name, I'll keep everything as originally proposed. Will do more testing and integrate.

BTW, I found a few existing singular/plural pairs of hpp files. Admittedly I created ciSymbols.hpp recently, but the other 3 pairs have been there for quite some time.

share/ci/ciSymbol.hpp
share/ci/ciSymbols.hpp

share/interpreter/bytecode.hpp
share/interpreter/bytecodes.hpp

share/jfr/recorder/service/jfrEvent.hpp
share/jfr/jfrEvents.hpp

share/jfr/recorder/checkpoint/types/jfrType.hpp
share/jfr/utilities/jfrTypes.hpp

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

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


More information about the shenandoah-dev mailing list