RFC: DMH lambda form arguments by jlink

[Claes Redestad]

(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
>