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

Thu Nov 7 05:27:26 PST 2013

Hi Stefan,

> 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?

Unfortunately it is not and I also failed myself to abuse it in that way.
There are some features (eg. caching of values) missing to declare
polymorphic inline caches using the DSL. At the moment all polymorphic
inline caches are implemented manually using Truffle API only. We are still
in phase of collecting required use-cases to compile a list of required DSL
features to support it. There are some concepts like resorting of cache
entries or generic cache entry promotion (not completely go to generic but
keep some hot cache entries) which would also be quite difficult to
support. But we would be happy if we could use your implementation as an
additional use-case for DSL support.

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.

Sorry i missed that. That's a bug, of course. Thanks for the report. Will
keep you posted.

Cheers,
Christian Humer

On Tue, Nov 5, 2013 at 1:42 AM, Stefan Marr <java at stefan-marr.de> wrote:

> 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
>
>