Truffle: executeCached, get, and other abstract methods? And a little generator bug.

[Stefan Marr]

Hi Christian:

Thanks for the thorough explanation!

On 04 Nov 2013, at 16:50, Christian Humer <christian.humer at gmail.com> wrote:

> I think, the feature you need is the generation of execute methods with
> evaluated children. This is also the feature you are already using, but the
> method should not be called executeCached* but instead executeEvaluated or
> something different.

Ah, right, I already forgot about those.

> I hope this answers your question. There are just these two magic features
> (the rest is more explicit using annotations): Getters for fields/children
> and the automatic implementation of execute methods. While the first is a
> convenience feature the second is an essential part of the DSL.

Ok, thanks.

> When the PolymorphicMyNode now gets called by its parent using an execute
> method it first executes its child operand. It then calls the first element
> of the polymorphic chain which is IntMyNode using executeChachedGeneric
> with the evaluated value of operand. The implementation of
> executeChachedGeneric in IntMyNode will then check if the value is
> compatible to this specialization and invoke the specialization if so. If
> not it will just call the next specialization in the chain stored in the
> next0 field. If an UninitializedMyNode is reached another entry to the
> polymorphic chain is added or if the maximum depth was reached the whole
> tree gets rewritten to GenericMyNode.

Is this feature somehow [ab]usable to realize polymorphic inline caches?
I.e., can I somehow define something like my MonomorphicMessageNode with it and get automatically a polymorphic behavior?
(https://github.com/smarr/TruffleSOM/blob/master/src/som/interpreter/nodes/specialized/MonomorpicMessageNode.java#L35)

I would assume that a failing guard on line 49 would be very similar to the situations you describe?

> Regarding the NPE: Null is not supported as a value by the DSL  at them
> moment (but it is supported by Truffle in general). If you want to
> represent null using the DSL, use a singleton value like MyNull.INSTANCE.
> It should not make a difference performance wise. It is on my list of
> things I want to add support for at some point. Please tell me if you need
> it. In this case I can try to give it a higher priority.

Hm, well, no. The error caused by the snipped below is a different one.
The `return null` can be changed to a `throw new RuntimeException();` or something.
To me it reads rather like a little edge case that’s not handled gracefully in the DSL processor causing the stack trace below.
At the moment I am not hitting that one, just stumbled over it while experimenting.

Thanks again
Stefan

Uncaught error in AnnotationProcessor while processing som.interpreter.nodes.TestNode: null 
java.lang.NullPointerException at 
com.oracle.truffle.dsl.processor.node.NodeParser.createGenericSpecialization(NodeParser.java:734) at 
com.oracle.truffle.dsl.processor.node.NodeParser.finalizeSpecializations(NodeParser.java:614) at 
com.oracle.truffle.dsl.processor.node.NodeParser.parseNode(NodeParser.java:206) at 
com.oracle.truffle.dsl.processor.node.NodeParser.resolveNode(NodeParser.java:119) at 
com.oracle.truffle.dsl.processor.node.NodeParser.parse(NodeParser.java:59) at 
com.oracle.truffle.dsl.processor.node.NodeParser.parse(NodeParser.java:1) at 
com.oracle.truffle.dsl.processor.AbstractParser.parse(AbstractParser.java:63) at 
com.oracle.truffle.dsl.processor.AnnotationProcessor.process(AnnotationProcessor.java:83) at 
com.oracle.truffle.dsl.processor.TruffleProcessor.processElement(TruffleProcessor.java:91) at 
com.oracle.truffle.dsl.processor.TruffleProcessor.processImpl(TruffleProcessor.java:79) at 
com.oracle.truffle.dsl.processor.TruffleProcessor.process(TruffleProcessor.java:53) at 
org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:139) at 
org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:121) at 
org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotatio
nProcessorManager.java:159) at 
org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnot
ationProcessorManager.java:134) at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:
820) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:434) at 
org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:366) at 
org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:329) at 
org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:303) at 
org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:134) at 
org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at 
org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193) at 
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:733) at 
org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206) at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) at 
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299) at 
org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302) at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358) at 
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381) at 
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143) at 
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241) at 
org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)


> 
> 
> Cheers,
> 
> - Christian Humer
> 
> 
> On Mon, Nov 4, 2013 at 12:49 PM, Stefan Marr <Stefan.Marr at vub.ac.be> wrote:
> 
>> Hi:
>> 
>> I found another useful abstract method in truffle node classes:
>> executeCachedGeneric, which allows me to execute the code of a specialized
>> node after replacing a more general one.
>> After inspecting the generator code, I also found that executeCached* is
>> probably working also for other kind of specializations.
>> 
>> And since there are also the accessors for node children (get$childName),
>> I was wondering whether the TruffleDSL has other similar gems hidden in
>> it, which might be useful?
>> 
>> As a related note, I also saw a null pointer exception that can be
>> reproduced with the code snippet below.
>> 
>> Best regards
>> Stefan
>> 
>> 
>> package som.interpreter.nodes.specialized;
>> 
>> import som.interpreter.Types;
>> import som.interpreter.nodes.ExpressionNode;
>> import som.vmobjects.SAbstractObject;
>> 
>> import com.oracle.truffle.api.dsl.NodeChild;
>> import com.oracle.truffle.api.dsl.Specialization;
>> import com.oracle.truffle.api.dsl.TypeSystemReference;
>> import com.oracle.truffle.api.frame.VirtualFrame;
>> import com.oracle.truffle.api.nodes.Node;
>> 
>> @TypeSystemReference(Types.class)
>> @NodeChild(value = "receiver", type = ExpressionNode.class)
>> public abstract class TestNode extends Node {
>> public abstract SAbstractObject executeCachedGeneric(final VirtualFrame
>> frame, final Object receiver);
>> 
>> @Specialization
>> public SAbstractObject doGeneric(final VirtualFrame frame,
>>     final SAbstractObject receiver) {
>>   return null;
>> }
>> }

-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525