<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
First my usual disclaimer: You should not use substitutions at all. They are a maintenance nightmare.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Nothing has changed in the substitution system for a long time, so the comment is still accurate.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The problem are virtual method calls in target classes. The image generator delegates all virtual method resolution to the HotSpot VM via JVMCI. But the HotSpot VM does not know anything about the substitutions and target classes. So if you have a virtual dispatch
in a target class, very strange things could happen. Forcing target classes to be final and inheriting directly from Object means that there are only invokespecial and no dynamic dispatch.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Virtual method calls would also be the only reason for inheriting from target classes. All other use cases can be handled by having separate target classes, e.g. when you have classes A extends B, you can have separate Target_A and Target_B. And you can cast
freely between A, B, Target_A, and Target_B - at run time only classes A and B exist.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-Christian<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> graalvm-dev-bounces@oss.oracle.com <graalvm-dev-bounces@oss.oracle.com> on behalf of Foivos Zakkak <fzakkak@redhat.com><br>
<b>Sent:</b> Thursday, February 18, 2021 2:26 PM<br>
<b>To:</b> graalvm-dev@oss.oracle.com <graalvm-dev@oss.oracle.com><br>
<b>Subject:</b> [graalvm-dev] Question regarding "target class must inherit directly from Object"</font>
<div> </div>
</div>
<div>
<p>Hello all,</p>
<p>In [1] I see:<br>
</p>
<pre>// Not sure what happens if the target class is in a hierarchy - so prohibit that for now.
guarantee(annotatedClass.isInterface() == originalClass.isInterface(), "if original is interface, target must also be interface: %s", annotatedClass);
guarantee(originalClass.getSuperclass() == Object.class || originalClass.isInterface(), "target class must inherit directly from Object: %s", originalClass);</pre>
<p>I was wondering if anything changed since that comment and the corresponding guarantees were added?<br>
Does anyone know it's now safe to remove those guarantees?<br>
<br>
Thanks in advance!<br>
</p>
<p>[1] <a class="x_moz-txt-link-freetext" href="https://github.com/oracle/graal/blob/51fe078b16e61bc50d95bdbbee9b0b0886b4c98d/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/substitute/AnnotationSubstitutionProcessor.java#L573-L575">
https://github.com/oracle/graal/blob/51fe078b16e61bc50d95bdbbee9b0b0886b4c98d/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/substitute/AnnotationSubstitutionProcessor.java#L573-L575</a><br>
</p>
<pre class="x_moz-signature" cols="72">--
Foivos Zakkak
Senior Software Engineer, R&D Middleware
Red Hat
7B40 69D9 29BA AE91 C0B3 220A 0846 BFD1 03F0 4EA1</pre>
</div>
</body>
</html>