Regression for TraceTruffleCompilationDetails?
Christian Humer
christian.humer at gmail.com
Wed Dec 18 08:10:55 PST 2013
Hi Stefan,
The problem is located in the VariableNode class. At the point where you
access frame it escapes. So Graal will materialize the frame in front of
the frame.getObject. Unfortunately the TraceTruffleCompilationDetails
option fails to handle this case. I will fix that.
However your implementation of VariableNode And VariableWriteNode is
completely off the current Truffle way. If you access your variable by
always materializing it first, you will end up having a lot materialization
of frames. This is also why pretty simple methods produce a lot of code in
your implementation.
It does not really make much sense if you try to optimize your arithmetics
until your variable accesses are not fixed. So I think you should focus on
that problem first. If you want to store a pointer to the parent frame, a
custom implementation of Arguments may be the place to store it. Please see
SL as a reference, which also implements a custom Arguments. Try to only
use VirtualFrames accesses on the fast path. For that you may also need to
create proper FrameDescriptors etc.
Hope this helps.
Cheers,
- Christian Humer
On Wed, Dec 18, 2013 at 4:45 PM, Christian Humer
<christian.humer at gmail.com>wrote:
> Hi Stefan,
>
> That --recursive seemed to have fixed my problem. Thx!
> Will have a look.
>
>
> - Christian Humer
>
>
> On Wed, Dec 18, 2013 at 4:22 PM, Stefan Marr <java at stefan-marr.de> wrote:
>
>> Hi Christian:
>>
>> Sorry, yes, TruffleSOM is not tested on Windows, and there are certainly
>> hidden problems.
>> Since I don’t have access to a windows box, I unfortunately can’t provide
>> you with something more robust, sorry.
>>
>> You are running here into problems because the TruffleSOM git repo uses
>> symlinks and core-lib is the git submodule to which the symlinks should be
>> pointing. And symlinks aren’t supported on NTFS…
>>
>> The problem you are seeing with the missing bitXor: primitive is probably
>> caused by a mismatch between the core-lib version on the TruffleSOM version.
>>
>> Please note the `--recursive` in the git command line: `git clone
>> --recursive https://github.com/smarr/TruffleSOM.git`<https://github.com/smarr/TruffleSOM.git>
>> The proper version should normally be loaded with the following commands
>> after a non-recursive clone:
>> git submodule init
>> git submodule update
>>
>> With regard to [1]: The simple answer is, because I didn’t write that
>> code. I’ll fix it.
>>
>> Either way, thanks for looking into it. Not sure whether it is an
>> important issue, but I worked around it by just swallowing the exception.
>>
>> Best regards
>> Stefan
>>
>> On 18 Dec 2013, at 16:03, Christian Humer <christian.humer at gmail.com>
>> wrote:
>>
>> > Hi Stefan,
>> >
>> > I gave it another try even so you did not provide me with a more robust
>> form for the command line. After I've hardcoded the Universe#fileSeparator
>> to a "/" I managed to at least run something [1] . After I've fixed the
>> class path provided in your -cp which is not where it should be if you do a
>> clean checkout from git I came up with this command line:
>> >
>> > mx --vm server vm -G:+TraceTruffleCompilationDetails
>> -Xbootclasspath/a:../TruffleSOM/build/classes;../TruffleSOM/libs/com.oracle.truffle.api.jar;../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar
>> som.vm.Universe -cp ../TruffleSOM/core-lib/Smalltalk
>> ../TruffleSOM/core-lib/Examples/Benchmarks/BenchmarkHarness.som IntegerLoop
>> 1 2 2000
>> >
>> > However I got this output on the console:
>> > Warning: Primitive bitXor: is not in class definition for class Double
>> > Exception in thread "main" java.lang.RuntimeException: This should not
>> happen in TruffleSOM
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.createCachedNode(BinarySendNode.java:162)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.specialize(BinarySendNode.java:141)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58)
>> > at
>> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43)
>> > at
>> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1)
>> > at som.interpreter.Method.messageSendExecution(Method.java:89)
>> > at som.interpreter.Method.execute(Method.java:77)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58)
>> > at
>> som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60)
>> > at
>> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43)
>> > at
>> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1)
>> > at som.interpreter.Method.messageSendExecution(Method.java:89)
>> > at som.interpreter.Method.execute(Method.java:77)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117)
>> > at
>> som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58)
>> > at
>> som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60)
>> > at
>> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43)
>> > at
>> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1)
>> > at som.interpreter.Method.messageSendExecution(Method.java:89)
>> > at som.interpreter.Method.execute(Method.java:77)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98)
>> > at
>> com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75)
>> > at com.oracle.truffle.api.CallTarget.call(CallTarget.java:62)
>> > at som.vmobjects.SMethod.invokeRoot(SMethod.java:86)
>> > at som.vm.Universe.execute(Universe.java:302)
>> > at som.vm.Universe.interpret(Universe.java:77)
>> > at som.vm.Universe.main(Universe.java:63)
>> >
>> > Whats this? I stopped investigating at this point.
>> >
>> > [1] Why didnt you just use the java.io.File API in the jdk to parse
>> your pathes?
>> >
>> >
>> > Cheers,
>> >
>> > - Christian Humer
>> >
>> >
>> > On Mon, Dec 16, 2013 at 2:57 PM, Stefan Marr <java at stefan-marr.de>
>> wrote:
>> > Hi Christian:
>> >
>> > Since I don’t know exactly whether there is anything Windows related
>> going wrong, perhaps a few additional notes on my setup.
>> > I think, the standard problems should be that either the paths in the
>> command line are not correct, or the git repo wasn’t checked out with its
>> submodules:
>> >
>> > To clone the git repo of TruffleSOM with its submodules:
>> > git clone --recursive https://github.com/smarr/TruffleSOM.git
>> >
>> > In contrast to other Truffle languages, TruffleSOM wasn’t yet adapted
>> to the mx compilation infrastructure, but uses a simple ant script.
>> >
>> > Executing `ant tests` should compile the necessary files and execute a
>> simple test.
>> > Note, it will download the necessary precompiled Truffle jars. I
>> guess, that should work on Windows.
>> >
>> > Afterwards, it will depend on where your Graal folder is located.
>> >
>> > The command line assumes that it is in a folder next to TruffleSOM, so
>> in the command line, `../TruffleSOM` would need to be replaced for other
>> locations accordingly. Perhaps the path separators need to be changed for
>> windows as well.
>> >
>> > > ./mx.sh --vm server vm -G:+TraceTruffleCompilationDetails
>> -Xbootclasspath/a:../TruffleSOM/build/classes:../TruffleSOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar
>> som.vm.Universe -cp ../TruffleSOM/Smalltalk
>> ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100
>> >
>> >
>> > After the mx.sh arguments, the bootclass path is set to include the
>> Truffle libraries, as well as the compiled TruffleSOM classes (from the
>> build/classes folder).
>> > The main class of TruffleSOM is som.vm.Universe, `-cp` gives a class
>> path to SOM to enabled to find its Smalltalk class library, and the main
>> script to be executed is
>> ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som with a name for the
>> benchmark and infos on how many iterations, and warmup cycles should be
>> executed.
>> >
>> > Thanks for looking into the issue. I worked around it by just catching
>> the exception for the moment.
>> >
>> > Best regards
>> > Stefan
>> >
>> > On 16 Dec 2013, at 11:51, Christian Humer <christian.humer at gmail.com>
>> wrote:
>> >
>> > > Hi Stefan,
>> > >
>> > > Could you please provide a little more robust command line for the
>> problem?
>> > > I just completely failed to run it on windows.
>> > >
>> > >
>> > > - Christian Humer
>> > >
>> > >
>> > > On Mon, Dec 16, 2013 at 11:13 AM, Stefan Marr <java at stefan-marr.de>
>> wrote:
>> > > Hi:
>> > >
>> > > I am running here into a class cast exception when using
>> -G:+TraceTruffleCompilationDetails:
>> > >
>> > > java.lang.ClassCastException:
>> com.oracle.graal.truffle.nodes.frame.NewFrameNode cannot be cast to
>> com.oracle.graal.nodes.ConstantNode
>> > > at
>> com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:193)
>> > >
>> > > The corresponding line is:
>> > > ConstantNode constantNode = (ConstantNode)
>> methodCallTargetNode.arguments().first();
>> > >
>> > > However, the first argument is not a ConstantNode but a NewFrameNode
>> (the new frame node looks like one of mine, i.e., for a TruffleSOM method
>> call).
>> > >
>> > > The targetMethod of is
>> `HotSpotMethod<FrameWithoutBoxing.getObject(FrameSlot)>`.
>> > >
>> > > The problem can be triggered for instance with the following
>> TruffleSOM benchmark:
>> > >
>> > > ./mx.sh -d --vm server vm -G:+TraceTruffleCompilationDetails
>> -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar
>> som.vm.Universe -cp ../som/Smalltalk
>> ../som/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100
>> > >
>> > > I suppose the receiver is here expected to be constant to print out
>> tracing information, but it isn’t in my case.
>> > >
>> > > Is there perhaps some simple work-around possible?
>> > >
>> > > Thanks
>> > > Stefan
>> > >
>> > > To check out TruffleSOM:
>> > >
>> > > git clone --recursive https://github.com/smarr/TruffleSOM.git
>> > > cd TruffleSOM
>> > > ant jar
>> > > cd $GRAAL
>> > >
>> > > --
>> > > 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
>> > >
>> > >
>> >
>> > --
>> > 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
>> >
>> >
>>
>> --
>> 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
>>
>>
>
More information about the graal-dev
mailing list