RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]

[Jan Lahoda]

On Wed, 3 Feb 2021 18:05:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I see what you mean - as I said, my worry is that, while this patch addresses the paucity of flags in an effective fashion, the resulting code base end up being worse than it was to begin with, as now a client will have to hunt flags in different enums. If the organization was consistent, I'd have no problem with giving each kind of flag its own enum - but given that the organization is more ad-hoc (e.g. driven by which use cases could be morphed into using enums), I'm unsure.
> 
> I mean, what's the advantage of the proposed solution vs. organizing the set of long flags in Flags by categories - so that there's no enum, but so that e.g. a variable symbol flag can reuse the same value as some other method symbol flag?
> 
> I think it would deliver same saving, w/o the need to change the flag API. Granted, we also not get any protection for when somebody tries to "merge" flags that are not mergeable - but I'm equally not sure as to whether the proposed solution offers a much more principled alternative?

I don't think this is a more principled alternative, the main goal here was to reuse the flag bits as safely as possible. Reusing the same bits across various Symbols manually is basically what we do now, but, for me, it is often difficult to prove that a bit is used only for (e.g.) VarSymbols and I can reuse it for MethodSymbols. With this patch, most of the (symbol-specific) checks are done statically, some are done at runtime (via casts), but we can't easily set a method-only flags on a VariableSymbol by accident.

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

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