RFR (S) 8158851: MH.publicLookup() init circularity, triggered by custom SecurityManager with String concat and -limitmods java.base

[Claes Redestad]

On 2016-06-07 15:51, Alan Bateman wrote:
> On 07/06/2016 14:38, Aleksey Shipilev wrote:
>
>> Hi,
>>
>> Please review a fix for a MH.publicLookup() circularity, which is
>> triggered if you run existing String concat tests with -limitmods 
>> java.base:
>>    https://bugs.openjdk.java.net/browse/JDK-8158851
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~shade/8158851/webrev.01/
> As a short term fix then this looks okay. It may be (once there is 
> another round of work on MethodHandles w/modules) that PL moves back 
> to java.lang.Object but that has many discussion points for another 
> thread.
>
> If you want then the doPriv in LookupHelper can do away as it is not 
> required when you can guarantee that it is initialized before a 
> security manager is set.
>
> One downside to initializing PL early is that is LookupHelper will 
> trigger some ASM to be loaded. This could avoid by generating it at 
> link time and loading the class bytes as resource. Hard to know if 
> it's worth it as the first lambda usage is going to trigger these 
> classes to load anyway.

While moving the ASM code to jlink could solve this more elegantly, the 
byte[] for Unnamed seems trivial enough (empty class) and invariant 
across all platforms etc... couldn't we make an unhygienic exception and 
just generate the byte[] once and for all and put it in the source code?

         private static Class<?> createClass() {
             try {
                 byte[] bytes = { ... }; // such bytes
                 ClassLoader loader = ...
             }

/Claes

>
> -Alan.