RFR: 8230302: GenerateJLIClassesPlugin can generate invalid DirectMethodHandle methods

[Claes Redestad]

Hi Mandy,

On 2019-08-28 19:11, Mandy Chung wrote:
> 
> 
> On 8/28/19 7:38 AM, Claes Redestad wrote:
>> Hi,
>>
>> we currently spin code for a non-sensical invokeVirtual DMH, so let's
>> remove that.
>>
>> Such methods are benign since we won't ever attempt to resolve such
>> nonsensical forms, but surely a waste of space. This patch tightens
>> checks conservatively (could possibly apply the same restriction to
>> invokeSpecial?) and adds a few negative tests using inputs that jlink
>> should refuse.
>>
> 
> I also think same check (first parameter is the receiver) can be applied 
> to invokespecial for DMH.

While tightening this up would be good, I also want to make absolutely
certain there aren't any edge cases that we're missing where omitting
the receiver would actually be fine. I need to study the specification a
bit more (and add more tests), so for now I think I'd like to leave
things as is.

Again, while it might be possible to make the plugin generate a LF that
doesn't make sense, it's AFAICT not possible to construct a DMH at
runtime that would pick that up, so making things stricter is mainly
about good hygiene.

> 
>> Webrev: http://cr.openjdk.java.net/~redestad/8230302/webrev.00/
>>
> 
> This looks okay.   

Thanks!

> It'd be good to move away from hardcoded defaults as 
> tracked by JDK-8230301.

Yes, I have that lined up, running tests etc. I just need to ensure
there are no regressions, but since we now have build-time profile
guidance on what to pregenerate it seems most of the things in the
defaults are now either redundant or dead weight.

/Claes