RFR (round2) JDK-8038654: Separate SymbolTable and StringTable code

Stefan Karlsson stefan.karlsson at oracle.com
Tue May 6 08:27:56 UTC 2014


On 2014-05-05 23:07, Coleen Phillimore wrote:
>
> Hi,
>
> I don't see how this compiles without precompiled headers without 
> including symbolTable.hpp - there are files with SymbolTable::unlink() 
> so it must be included transitively (but I haven't found which file 
> indirectly includes it yet).

I took a look at the include tree for concurrentMarkSweepGeneration.cpp 
(by passing -H to gcc), and apparently classFileParser.hpp includes 
symbolTable.hpp.

> I think it's better not to include symbolTable.hpp transitively but to 
> include it directly in the files that use functions in SymbolTable, ie 
> all the GC files use SymbolTable::unlink.

I agree with Coleen. Thanks for catching this.

StefanK

> Actually, I think the set of files that use stringTable and not 
> symbolTable are very small (or none).
>
> Coleen
>
> On 5/2/14, 12:57 PM, Gerard Ziemski wrote:
>> hi all,
>>
>> Please review this simple enhancement, which refactors symbolTable 
>> into symbolTable and stringTable
>>
>> The changes since rev0:
>>
>> Re: Stefan Karlsson
>>
>> - sorted includes
>> - replaced "#include symbolTable.hpp" with just "#include 
>> stringTable.hpp" as needed
>> - stringTable.cpp no longer includes symbolTable.hpp
>> - stringTable.hpp forward declares Symbol instead of including 
>> symbolTable.hpp
>>
>>
>> Webrev: http://cr.openjdk.java.net/~gziemski/8038654_rev1
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8038654
>>
>> Tested with hotspot jtreg, vm.quicklooks and JPRT. Locally builds on 
>> Mac OS X and Linux.
>>
>> Thank you.
>>
>>
>>
>>
>



More information about the hotspot-runtime-dev mailing list