RFC: DMH lambda form arguments by jlink

[Claes Redestad]

Filed:

  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.

/Claes

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.
> 
> Thanks!
> 
> /Claes
> 
> 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" [1]. According to documentation [2] 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 [3]) 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 [4]
>> (please don't confuse with arm port) where it happen to exist assert
>> checking for mentioned register clash [5]
>>
>> Will be happy if someone could confirm if this is indeed correct
>> description of what's happening or point to mistake in analysis, as
>> appropriate
>>
>> Thanks,
>> Andrey
>>
>> [1]
>> http://hg.openjdk.java.net/jdk/jdk/file/00bf1e66de11/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java#l151 
>>
>> [2] https://wiki.openjdk.java.net/display/HotSpot/Direct+method+handles
>> [3]
>> http://hg.openjdk.java.net/jdk/jdk/file/00bf1e66de11/src/hotspot/cpu/x86/methodHandles_x86.cpp#l293 
>>
>> [4]
>> https://mail.openjdk.java.net/pipermail/aarch32-port-dev/2018-September/001093.html 
>>
>> [5]
>> http://cr.openjdk.java.net/~apetushkov/aarch32jdk11%2b28/src/hotspot/cpu/aarch32/methodHandles_aarch32.cpp.html 
>>
>> line
>> 269
>>