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
