RFC: DMH lambda form arguments by jlink
claes.redestad at oracle.com
Wed Aug 28 09:24:30 UTC 2019
https://bugs.openjdk.java.net/browse/JDK-8230302 to deal with the bug
that the plugin can and does generate some invalid DMHs
https://bugs.openjdk.java.net/browse/JDK-8230301 to re-examine the
ability to hardcode default sets of DMHs, invokers etc. This can and
should be controlled by generating and providing a property file to
jlink, which we currently do at build time.
On 2019-08-25 21:45, Claes Redestad wrote:
> (bcc jdk-dev, add core-libs-dev)
> Hi Andrey,
> I think you might be right that L_L of invoke virtual is non-sensical
> and should be removed. I vaguely recall that it at one point have been
> coded so that the receiver was implied for these forms when translating.
> Also worth noting that the intent was to remove the hardcoded "default"
> signatures as the technique to record the set of LFs generated by
> typical applications matured. I think we might be at that point now, and
> should evaluate if all these "defaults" in GenerateJLIClassesPlugin can
> be removed.
> On 2019-08-23 19:28, Andrey Petushkov wrote:
>> Dear JDK developers,
>> (I'm apologising if posted to wrong alias, please forward as appropriate)
>> The question is about lambda form cache, created by jlink. More precisely
>> by jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java.
>> It appears to me that it has a bug in set of signatures, specifically in
>> attempt to create LF for invocation of invokevirtual type with
>> signature of
>> "L_L" . According to documentation  and supported by the code the
>> arguments to lambda form must be the arguments of the target method
>> prepended by DMH itself. Hence the invokevirtual linkage should always be
>> supplied with at least two oop arguments coming first (DMH and receiver)
>> If I'm correct this bug is totally harmless, since such lambda form
>> although buggy (the native wrapper for respective MethodHandle intrinsic
>> have register clash between receiver (receiver_reg) and MemberName
>> (member_reg) at ) it will never be actually used, because the
>> actual MH
>> invoke will not have such signature. But for the sake of consistency I'd
>> rather remove the signature in question.
>> The problem is actually found by jtreg tests on aarch32 platform 
>> (please don't confuse with arm port) where it happen to exist assert
>> checking for mentioned register clash 
>> Will be happy if someone could confirm if this is indeed correct
>> description of what's happening or point to mistake in analysis, as
>>  https://wiki.openjdk.java.net/display/HotSpot/Direct+method+handles
More information about the core-libs-dev