RFR/RFC: JDK-8241356: Use a more reliable way to encode Symbol flags

[Jan Lahoda]

Hi,

Currently, (com.sun.tools.javac.code.)Symbol/s have a long field 
"flags_field", which holds various one-bit information ("Flags") about 
the given Symbol.

We currently have around 64 such Flags, which means we are out of bits 
in the long field, and adding new flags is not easy.

We could change the "flags_field" to be a Set over enums, but this would 
increase the memory footprint notably, and would also slow-down access 
to flags. Currently, flags operations in javac are very fast and very 
common, so this is probably too much burden. There are also flags to 
which we need to access as bit masks, e.g. due to writing to classfile.

My proposal here is to use an intermediate solution, until we find a 
better solution, or until a better solution is possible (like due to 
Valhalla). The idea is as follows:
-the current long-based Flags are split into 4 groups:
--"flat" Flags, long based, work exactly as before.
--enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, 
which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, 
respectively, and are checked using methods like Symbol.isFlagSet and 
set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these 
flags are mostly encapsulated, even though physically they are currently 
stored in the flags_field as well.

There are 37 "flat" flags and 16 TypeSymbolFlags (methods and vars have 
less flags), 53 in total. This gives us at least 10 new flags before we 
might run out of long bits in flags_field again - but even if we do, 
there are several easy mitigation strategies we could use, like:
-create a new int/long field on TypeSymbols for the TypeSymbolFlags 
(probably preferable)
-split TypeSymbolFlags into Class/Package/MethodSymbolFlags

The positives of this solution include:
-safe(r) access to the flags - the access to the 
extra/symbol-kind-specific flags is mostly encapsulated, and hence 
mostly safe
-improves the abstractions at least for some flags
-reasonably complex patch (attempts to encapsulate all the flags were 
troublesome in previous experiments)
-the performances appears to be acceptable.

The negative that I see is that the code includes several incompatible 
types of flags now. These cannot be easily confused by accident (as the 
type system will complain), but still we need to be aware of them when 
writing code.

Some more alternatives:
-add a new field to Symbol, like long extraFlags, and continue with bit 
masks as we did so far using this new field. The drawback is that it is 
more error prone (it would be difficult to ensure only the new/extra 
flags would be stored and read from extraFlags).
-have a new field, and "flat" and non-"flat" enum-based encapsulated 
Flags, but don't separate Type/Method/Var flags. Probably something to 
consider, even though I am a bit reluctant to add new fields without 
trying to avoid it .



Current proposed patch:
http://cr.openjdk.java.net/~jlahoda/8241356/webrev.00/

JBS: https://bugs.openjdk.java.net/browse/JDK-8241356


Any feedback is welcome!

Thanks,
     Jan