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
