RFR: 8252505: C1/C2 compiler support for blackholes

[Vladimir Ivanov]

>>     * you subclass CallJavaNode, but then disable most of the features it
>> brings.
> 
> Yeah. On the upside, that effectively allow me to push the 
> CallBlackholeJava as if it is CallJavaNode, and create this special node 
> by trivially hijacking two CallGenerators. But maybe that is not as 
> clean, and we are better off lifting CallBlackhole to Call, and do its 
> own BlackholeCallGenerator.
> 
> For example, like this:
>    https://cr.openjdk.java.net/~shade/8252505/remodel-callblackhole.patch
> 
> Since we are now doing the whole setup for it ourselves, I think we can 
> avoid safepoint and debug info, and therefore ditch Ideal for it. 
> RegMask would still avoid register shuffles of "real" arguments. It 
> still has some x86_32 failures which I would attend to tomorrow, so I 
> cannot push it to the branch yet.

Yeah, it looks better. Still, IMO LibraryCallKit is a better place for 
it. It would require additional logic to attach intrinsic id to a 
method, but I think it's worth it.

>>     * what you try to achieve is closer to CallLeaf: it doesn't have
>> safepoint info attached.
> 
> Yeah, but CallLeaf is CallRuntime, which is weird.

Representing something non-existent in the generated code as a Call is 
already weird, isn't it? ;-)

>>     * but SafePoint is also close (except JVM state): it doesn't have any
>> arguments, but still keeps values alive through debug inputs; you could
>> try to turn arguments into debug info even for an ordinary call.
> 
> I am probably stupid, but I cannot get this part to work yet.

On my side it is more about pointing out similarities with existing 
concepts. I still think it's worth considering a special node without 
any ties to Call/Safepoint hierarchy.

One more idea: would a new flavor of mem-bar (CPUOrder-based one?) with 
debug info support solve the problem? It would have the following 
features: (1) don't produce anything in generated code; (2) don't 
require explicit matching; (3) keeps values alive, but don't touch them; 
(4) orders both control and memory graph.

(MemBarNode node extends MultiNode and is a sibling of SafePoint.)

>>     * you can try to avoid AD changes and construct a MachNode directly;
> 
> You mean hack Matcher to emit MachCallBlackholeNode for every 
> CallBlackholeNode without involving .ad? I guess I can try, but simple 
> .ad match rule seems a tad more clear and maintainable to me: it does 
> not do special hacks in Matcher.

Sure, it works nicely for Calls/Safepoints and you would only save on 
trivial declarations across all platforms. But once you untie the node 
from Call/Safepoint hierarchy, you have to be more explicit about the 
effects of the particular mach node flavor. Special handling of 
Call/Safepoints by Matcher covers that for you now.

Best regards,
Vladimir Ivanov