On Tue, 8 Mar 2022 00:19:58 GMT, Joe Darcy <da...@openjdk.org> wrote:

> > The mapping from Location to AccessFlag(s) could be implemented event 
> > without using a Map. You just have to be careful not to use EnumSet for 
> > that (i.e. before AccessFlag enum constants are fully initialized) - an 
> > ArrayList is better for this case anyway. Also, conversion from 
> > ModuleDescriptor modifier(s) to AccessFlag(s) could be done without first 
> > creating a bitmask and then re-constructing a set of AccessFlag(s) from it. 
> > Reflective object modifiers can only be translated via bitmask, but various 
> > ModuleDescriptor Modifier(s) may have a direct mapping to corresponding 
> > AccessFlag(s). For example:
> > [plevart@5a3cd8f](https://github.com/plevart/jdk/commit/5a3cd8f6851a0deae7e3e5028bba9a51d7863929)
> 
> Yes, I made the same observation for the module-related modifiers when coding 
> this up; I'll look to add some API support to avoid the need to detour 
> through bitmasks.
> 
> To get the public API worked out, I wanted to avoid complications in 
> inter-dependent class initialization. Thanks for suggesting an alternative; 
> I'll consider that when I resume work on this PR (need to start writing some 
> tests...) Thanks.

On a second thought, maybe the common bitmask representation is the way to go. 
One one hand it must be computed from the set of module-related Modifier 
set(s), but then again such bitmask is very easy to cache economically (a 
single int field, no synchronization). When you have a bitmask at hand and a 
list of all possible elements (the universe), a very efficient implementation 
of a Set<AccessFlag> is possible (similar to EnumSet). Such AccessFlagSet 
instances do not need to be cached since they are just thin views over existing 
"permanent" structures and will, as such, typically be optimized away by JIT. 
Note the particularly efficient .contains() implementation which just checks 
two bitmasks (the flag mask and the location mask).

https://github.com/plevart/jdk/commit/de9f2614da56775be4ae07c6781cbec9fbd39930

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

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

Reply via email to