Avoid receive timeout type pollution

[He-Pin]

Motivation

Identify implements both AutoReceivedMessage and NotInfluenceReceiveTimeout. On JVMs affected by JDK-8180450, alternating successful checks against those two secondary supertypes makes the same concrete Klass secondary-super cache ping-pong between marker types. The checks occur on the Actor receive-timeout path and can contend across actor-dispatcher threads.

The receive path also classified the same message against NotInfluenceReceiveTimeout twice.

Modification

• Classify final Identify with a concrete-class guard before the NotInfluenceReceiveTimeout marker check.
• Return the pre-cancellation timeout state and infer the post-receive reschedule decision from the state transition, removing the second marker check.
• Add focused classification coverage.
• Add a 12-thread JMH benchmark for the polluted, concrete-guarded, and final production-shaped paths.

Result

Receive-timeout behavior remains unchanged, while Identify no longer alternates the concrete class secondary-super cache between its two marker interfaces. The final path also performs one classification instead of two.

JMH throughput (ops/us, 12 threads, 3 forks, 5 x 1 s warmup and measurement iterations):

Runtime	Polluted path	Concrete guard	Final path	Final / polluted
JDK 17.0.17	824.700 +/- 10.066	1633.766 +/- 53.719	2205.529 +/- 92.313	2.67x
JDK 21.0.8	1125.827 +/- 16.496	1609.084 +/- 31.694	2158.924 +/- 36.895	1.92x
JDK 25.0.2	1717.703 +/- 77.349	1841.141 +/- 53.279	2467.700 +/- 262.562	1.44x

JDK 21.0.8 and JDK 25 contain the JVM fix, so their remaining gain primarily measures the removed classification/call rather than secondary-super-cache contention. The JDK 25 result was noisier than the other runs.

References

Refs #1668

• JDK-8180450