From michael.c.berg at intel.com  Fri Jul  1 03:30:38 2016
From: michael.c.berg at intel.com (Berg, Michael C)
Date: Fri, 1 Jul 2016 03:30:38 +0000
Subject: code review request for sin, cos and tan additions
Message-ID: <C568518E7B433348B114B6A7122D474756EC5F9B@FMSMSX102.amr.corp.intel.com>

Folks, the code is available as:

https://github.com/graalvm/graal-core/pull/192

For review.  

This change stages the first installment of intel libm intrinsics (sin, cos and tan). 
For Sin and Cos performance uplift is about 2.3x and Tan is about 1.9x.

Regards,
Michael

From michael.c.berg at intel.com  Fri Jul  1 03:33:46 2016
From: michael.c.berg at intel.com (Berg, Michael C)
Date: Fri, 1 Jul 2016 03:33:46 +0000
Subject: code review request for sin, cos and tan additions
In-Reply-To: <C568518E7B433348B114B6A7122D474756EC5F9B@FMSMSX102.amr.corp.intel.com>
References: <C568518E7B433348B114B6A7122D474756EC5F9B@FMSMSX102.amr.corp.intel.com>
Message-ID: <C568518E7B433348B114B6A7122D474756EC5FBA@FMSMSX102.amr.corp.intel.com>

Folks, the code is available as:

https://github.com/graalvm/graal-core/pull/192

For review.  

This change stages the next installment of intel libm intrinsics (sin, cos and tan). 
For Sin and Cos performance uplift is about 2.3x and Tan is about 1.9x.

Regards,
Michael

From juan.fumero at ed.ac.uk  Fri Jul  1 09:39:00 2016
From: juan.fumero at ed.ac.uk (Juan Fumero)
Date: Fri, 01 Jul 2016 10:39:00 +0100
Subject: FastR: Inlining failing
Message-ID: <1467365940.27326.12.camel@ed.ac.uk>

Hi all,?
??
?Within FastR, ?I am working now Tuples (RList with fixed types) in R
for the GPU. I get a runtime error when I am trying to compile the
function through the Partial Evaluator.?

<code>
# Simple test case
Tuple2 <- function(x, y) {
????t <- list(name="tuple2", a=x, b=y)??
????attr(t, "class") <- "tuple2"
????return(t)
}

gpuFunction <- function(x) {
?????return(Tuple2(x, x))
}

# R sapply for GPUs
result <- marawacc.sapply(1:1000, gpuFunction) ??

</code>

When Graal tries to compile the gpuFunction through the
OptimzedCallTarget, I get the following error in FastR. Any idea? I do
not get why this is a recursive inlining,?

[truffle] opt
fail?????????gpuFunction???????????????????????????????????????????????
??|Reason jdk.vm.ci.code.BailoutException: Too deep inlining, probably
caused by recursive inlining. Inlined methods ordered by inlining
frequency:
java.util.ResourceBundle.getObject(String) [488]
java.text.DecimalFormatSymbols.getInstance(Locale) [1]
java.util.Formatter.<init>(Locale, Appendable) [1]
com.oracle.graal.truffle.OptimizedCallTarget.callRoot(Object[]) [1]
java.lang.String.format(String, Object[]) [1]
com.oracle.graal.truffle.OptimizedCallTarget.callProxy(VirtualFrame)
[1]
java.text.DecimalFormatSymbols.<init>(Locale) [1]
java.util.Formatter.getZero(Locale) [1]
com.oracle.truffle.r.nodes.function.FunctionDefinitionNode.gpuExecution
(VirtualFrame) [1]
java.text.DecimalFormatSymbols.initialize(Locale) [1]
com.oracle.truffle.r.runtime.RInternalError.<init>(Throwable, String,
Object[]) [1]
java.util.Formatter.<init>() [1]
com.oracle.truffle.r.nodes.function.FunctionDefinitionNode.execute(Virt
ualFrame) [1]
sun.util.locale.provider.LocaleResources.getDecimalFormatSymbolsData()
[1]
sun.util.locale.provider.DecimalFormatSymbolsProviderImpl.getInstance(L
ocale) [1]?


It does work if, instead of returning as S3 object, I return an RList.?

<code>
gpuFunction <- function(x) {
? ? ?list(name="tuple2",x,x)?
}
</code>

As a work around I am working with RList directly, but I would like to return an S3 object. Any idea is welcome.

Cheers
Juan


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mail.openjdk.java.net/pipermail/graal-dev/attachments/20160701/26e84334/attachment.ksh>

From christian.wimmer at oracle.com  Fri Jul  1 15:03:48 2016
From: christian.wimmer at oracle.com (Christian Wimmer)
Date: Fri, 1 Jul 2016 08:03:48 -0700
Subject: FastR: Inlining failing
In-Reply-To: <1467365940.27326.12.camel@ed.ac.uk>
References: <1467365940.27326.12.camel@ed.ac.uk>
Message-ID: <74cfc1d8-0c3c-9449-e356-c66c85845294@oracle.com>

There is a missing @TruffleBoundary or 
CompilerDiretives.transferToInterpreter.  String formatting (the call to 
String.format) must not be reachable during partial evaluation. It is 
probably called from the RInternalError constructor.

-Christian


On 7/1/2016 2:39 AM, Juan Fumero wrote:
> Hi all,
>
>  Within FastR,  I am working now Tuples (RList with fixed types) in R
> for the GPU. I get a runtime error when I am trying to compile the
> function through the Partial Evaluator.
>
> <code>
> # Simple test case
> Tuple2 <- function(x, y) {
>     t <- list(name="tuple2", a=x, b=y)
>     attr(t, "class") <- "tuple2"
>     return(t)
> }
>
> gpuFunction <- function(x) {
>      return(Tuple2(x, x))
> }
>
> # R sapply for GPUs
> result <- marawacc.sapply(1:1000, gpuFunction)
>
> </code>
>
> When Graal tries to compile the gpuFunction through the
> OptimzedCallTarget, I get the following error in FastR. Any idea? I do
> not get why this is a recursive inlining,
>
> [truffle] opt
> fail         gpuFunction
>   |Reason jdk.vm.ci.code.BailoutException: Too deep inlining, probably
> caused by recursive inlining. Inlined methods ordered by inlining
> frequency:
> java.util.ResourceBundle.getObject(String) [488]
> java.text.DecimalFormatSymbols.getInstance(Locale) [1]
> java.util.Formatter.<init>(Locale, Appendable) [1]
> com.oracle.graal.truffle.OptimizedCallTarget.callRoot(Object[]) [1]
> java.lang.String.format(String, Object[]) [1]
> com.oracle.graal.truffle.OptimizedCallTarget.callProxy(VirtualFrame)
> [1]
> java.text.DecimalFormatSymbols.<init>(Locale) [1]
> java.util.Formatter.getZero(Locale) [1]
> com.oracle.truffle.r.nodes.function.FunctionDefinitionNode.gpuExecution
> (VirtualFrame) [1]
> java.text.DecimalFormatSymbols.initialize(Locale) [1]
> com.oracle.truffle.r.runtime.RInternalError.<init>(Throwable, String,
> Object[]) [1]
> java.util.Formatter.<init>() [1]
> com.oracle.truffle.r.nodes.function.FunctionDefinitionNode.execute(Virt
> ualFrame) [1]
> sun.util.locale.provider.LocaleResources.getDecimalFormatSymbolsData()
> [1]
> sun.util.locale.provider.DecimalFormatSymbolsProviderImpl.getInstance(L
> ocale) [1]
>
>
> It does work if, instead of returning as S3 object, I return an RList.
>
> <code>
> gpuFunction <- function(x) {
>      list(name="tuple2",x,x)
> }
> </code>
>
> As a work around I am working with RList directly, but I would like to return an S3 object. Any idea is welcome.
>
> Cheers
> Juan
>
>
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>

From chris.seaton at oracle.com  Sun Jul  3 16:03:41 2016
From: chris.seaton at oracle.com (Chris Seaton)
Date: Sun, 3 Jul 2016 17:03:41 +0100
Subject: New Truffle in graal-core
Message-ID: <698B3CB0-3BA3-4E0A-82B9-4384951A9BB4@oracle.com>

I?ve updated the Truffle version in graal-core to fbb6bb30803df787c07b1c8131789c94acfc2761

This should be a backwards compatible change.

Chris

From raffaello.giulietti at supsi.ch  Tue Jul  5 12:58:24 2016
From: raffaello.giulietti at supsi.ch (Raffaello Giulietti)
Date: Tue, 5 Jul 2016 12:58:24 +0000
Subject: ConditionProfile vs. BranchProfile
Message-ID: <c8f5dd0c-6e9f-3d66-c6c6-b761d864a84d@supsi.ch>

Hello,

while I think I understand the usefulness of Truffle's BranchProfile, I
don't get what the point is with ConditionProfile.

I mean, except when the condition profile indicates a zero count on
either the "then" or "else" parts, what is the real value of having such
a profile? The only reason I can figure out is something related to code
layout. I thought, however, that such optimizations were already
addressed by the hardware branch prediction mechanics. Granted, the
latter needs not necessarily be implemented on every CPU out there.

Any explanation is appreciated and welcome.

Greetings
Raffaello

From chris.seaton at oracle.com  Tue Jul  5 13:12:59 2016
From: chris.seaton at oracle.com (Chris Seaton)
Date: Tue, 5 Jul 2016 14:12:59 +0100
Subject: ConditionProfile vs. BranchProfile
In-Reply-To: <c8f5dd0c-6e9f-3d66-c6c6-b761d864a84d@supsi.ch>
References: <c8f5dd0c-6e9f-3d66-c6c6-b761d864a84d@supsi.ch>
Message-ID: <18771D96-9CD7-474F-BEB7-567C0E88EABE@oracle.com>

If you were to write

a = new BranchProfile();
b = new BranchProfile();

if (c) {
    a.enter();
    ?
} else {
    b.enter();
    ?
}

Then that?s almost the same thing as a ConditionProfile. So that?s useful on its own - it?s less code and less data than using two BranchProfiles.

As you say, ConditionProfile also introduces the branch counts and reorders the branches based on which is more likely. This works with the hardware branch predictor, because in most processors forward jumps are predicted not taken (or the other way around, I can?t remember but it?s in the Intel manual).

You ask if the hardware would predict this correctly anyway. Well the prediction cache is of course of limited size so it could run out. I would admit you may struggle to empirically prove that reordering branches like this makes a big difference on benchmarks. Maybe give it a go if you?re curious enough and tell us about the results?

Chris

> On 5 Jul 2016, at 13:58, Raffaello Giulietti <raffaello.giulietti at supsi.ch> wrote:
> 
> Hello,
> 
> while I think I understand the usefulness of Truffle's BranchProfile, I
> don't get what the point is with ConditionProfile.
> 
> I mean, except when the condition profile indicates a zero count on
> either the "then" or "else" parts, what is the real value of having such
> a profile? The only reason I can figure out is something related to code
> layout. I thought, however, that such optimizations were already
> addressed by the hardware branch prediction mechanics. Granted, the
> latter needs not necessarily be implemented on every CPU out there.
> 
> Any explanation is appreciated and welcome.
> 
> Greetings
> Raffaello


From christian.humer at gmail.com  Tue Jul  5 13:19:17 2016
From: christian.humer at gmail.com (Christian Humer)
Date: Tue, 05 Jul 2016 13:19:17 +0000
Subject: ConditionProfile vs. BranchProfile
In-Reply-To: <18771D96-9CD7-474F-BEB7-567C0E88EABE@oracle.com>
References: <c8f5dd0c-6e9f-3d66-c6c6-b761d864a84d@supsi.ch>
	<18771D96-9CD7-474F-BEB7-567C0E88EABE@oracle.com>
Message-ID: <em4e6240f7-0b22-4001-a005-09fa815d38e5@grashalm-work>

I'd like to add that branch probabilities are useful for some Graal 
optimizations like Partial Escape Analysis, where allocations are pushed 
into infrequent pathes.
This is something Graal can only do if you inject branch probabilities 
using a counting condition profile.

Cheers,
Christian Humer


On 05.07.2016 15:12:59, "Chris Seaton" <chris.seaton at oracle.com> wrote:

>If you were to write
>
>a = new BranchProfile();
>b = new BranchProfile();
>
>if (c) {
>     a.enter();
>     ?
>} else {
>     b.enter();
>     ?
>}
>
>Then that?s almost the same thing as a ConditionProfile. So that?s 
>useful on its own - it?s less code and less data than using two 
>BranchProfiles.
>
>As you say, ConditionProfile also introduces the branch counts and 
>reorders the branches based on which is more likely. This works with 
>the hardware branch predictor, because in most processors forward jumps 
>are predicted not taken (or the other way around, I can?t remember but 
>it?s in the Intel manual).
>
>You ask if the hardware would predict this correctly anyway. Well the 
>prediction cache is of course of limited size so it could run out. I 
>would admit you may struggle to empirically prove that reordering 
>branches like this makes a big difference on benchmarks. Maybe give it 
>a go if you?re curious enough and tell us about the results?
>
>Chris
>
>>  On 5 Jul 2016, at 13:58, Raffaello Giulietti 
>><raffaello.giulietti at supsi.ch> wrote:
>>
>>  Hello,
>>
>>  while I think I understand the usefulness of Truffle's BranchProfile, 
>>I
>>  don't get what the point is with ConditionProfile.
>>
>>  I mean, except when the condition profile indicates a zero count on
>>  either the "then" or "else" parts, what is the real value of having 
>>such
>>  a profile? The only reason I can figure out is something related to 
>>code
>>  layout. I thought, however, that such optimizations were already
>>  addressed by the hardware branch prediction mechanics. Granted, the
>>  latter needs not necessarily be implemented on every CPU out there.
>>
>>  Any explanation is appreciated and welcome.
>>
>>  Greetings
>>  Raffaello
>


From raffaello.giulietti at supsi.ch  Tue Jul  5 14:55:35 2016
From: raffaello.giulietti at supsi.ch (Raffaello Giulietti)
Date: Tue, 5 Jul 2016 14:55:35 +0000
Subject: ConditionProfile vs. BranchProfile
In-Reply-To: <em4e6240f7-0b22-4001-a005-09fa815d38e5@grashalm-work>
References: <c8f5dd0c-6e9f-3d66-c6c6-b761d864a84d@supsi.ch>
	<18771D96-9CD7-474F-BEB7-567C0E88EABE@oracle.com>
	<em4e6240f7-0b22-4001-a005-09fa815d38e5@grashalm-work>
Message-ID: <70b65205-e957-5dbe-e29b-599d441f02ee@supsi.ch>

Thanks Chris and Christian, your explanations make sense.

Greetings
Raffaello


On 2016-07-05 13:19, Christian Humer wrote:
> I'd like to add that branch probabilities are useful for some Graal
> optimizations like Partial Escape Analysis, where allocations are pushed
> into infrequent pathes.
> This is something Graal can only do if you inject branch probabilities
> using a counting condition profile.
> 
> Cheers,
> Christian Humer
> 
> 
> On 05.07.2016 15:12:59, "Chris Seaton" <chris.seaton at oracle.com> wrote:
> 
>> If you were to write
>>
>> a = new BranchProfile();
>> b = new BranchProfile();
>>
>> if (c) {
>>     a.enter();
>>     ?
>> } else {
>>     b.enter();
>>     ?
>> }
>>
>> Then that?s almost the same thing as a ConditionProfile. So that?s
>> useful on its own - it?s less code and less data than using two
>> BranchProfiles.
>>
>> As you say, ConditionProfile also introduces the branch counts and
>> reorders the branches based on which is more likely. This works with
>> the hardware branch predictor, because in most processors forward
>> jumps are predicted not taken (or the other way around, I can?t
>> remember but it?s in the Intel manual).
>>
>> You ask if the hardware would predict this correctly anyway. Well the
>> prediction cache is of course of limited size so it could run out. I
>> would admit you may struggle to empirically prove that reordering
>> branches like this makes a big difference on benchmarks. Maybe give it
>> a go if you?re curious enough and tell us about the results?
>>
>> Chris
>>
>>>  On 5 Jul 2016, at 13:58, Raffaello Giulietti
>>> <raffaello.giulietti at supsi.ch> wrote:
>>>
>>>  Hello,
>>>
>>>  while I think I understand the usefulness of Truffle's BranchProfile, I
>>>  don't get what the point is with ConditionProfile.
>>>
>>>  I mean, except when the condition profile indicates a zero count on
>>>  either the "then" or "else" parts, what is the real value of having
>>> such
>>>  a profile? The only reason I can figure out is something related to
>>> code
>>>  layout. I thought, however, that such optimizations were already
>>>  addressed by the hardware branch prediction mechanics. Granted, the
>>>  latter needs not necessarily be implemented on every CPU out there.
>>>
>>>  Any explanation is appreciated and welcome.
>>>
>>>  Greetings
>>>  Raffaello
>>
> 


From doug.simon at oracle.com  Tue Jul  5 19:35:21 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 5 Jul 2016 21:35:21 +0200
Subject: JVMCI JDK 8 binaries released on OTN
Message-ID: <3AC67219-AC68-4AB7-8A92-C6953637B6FE@oracle.com>

Hi,

There are now JVMCI JDK 8 binaries available at http://www.oracle.com/technetwork/oracle-labs/program-languages/downloads/index.html. These binaries can be used to develop Graal without having to build JVMCI. We?re still waiting for the first EA build of JDK 9 to be available that contains the latest JVMCI API changes. As such, Graal cannot yet be developed against JDK 9.

Note that the JDK binaries above are derived from an OracleJDK build. We hope to provide OpenJDK based builds at some point but can?t give any timelines just yet.

-Doug

From juan.fumero at ed.ac.uk  Wed Jul  6 11:08:01 2016
From: juan.fumero at ed.ac.uk (Juan Fumero)
Date: Wed, 06 Jul 2016 12:08:01 +0100
Subject: FastR: Inlining failing
In-Reply-To: <74cfc1d8-0c3c-9449-e356-c66c85845294@oracle.com>
References: <1467365940.27326.12.camel@ed.ac.uk>
	<74cfc1d8-0c3c-9449-e356-c66c85845294@oracle.com>
Message-ID: <1467803281.30218.2.camel@ed.ac.uk>

Hi Christian,
? ?it was that. I am modifying slightly bit the R AST interpreter for
the GPU execution. Need to put back some of the transferToInterpreter
directives.?

Thanks
Juan

On Fri, 2016-07-01 at 08:03 -0700, Christian Wimmer wrote:
> There is a missing @TruffleBoundary or?
> CompilerDiretives.transferToInterpreter.??String formatting (the call
> to?
> String.format) must not be reachable during partial evaluation. It
> is?
> probably called from the RInternalError constructor.
> 
> -Christian
> 
> 
> On 7/1/2016 2:39 AM, Juan Fumero wrote:
> > 
> > Hi all,
> > 
> > ?Within FastR,??I am working now Tuples (RList with fixed types) in
> > R
> > for the GPU. I get a runtime error when I am trying to compile the
> > function through the Partial Evaluator.
> > 
> > <code>
> > # Simple test case
> > Tuple2 <- function(x, y) {
> > ????t <- list(name="tuple2", a=x, b=y)
> > ????attr(t, "class") <- "tuple2"
> > ????return(t)
> > }
> > 
> > gpuFunction <- function(x) {
> > ?????return(Tuple2(x, x))
> > }
> > 
> > # R sapply for GPUs
> > result <- marawacc.sapply(1:1000, gpuFunction)
> > 
> > </code>
> > 
> > When Graal tries to compile the gpuFunction through the
> > OptimzedCallTarget, I get the following error in FastR. Any idea? I
> > do
> > not get why this is a recursive inlining,
> > 
> > [truffle] opt
> > fail?????????gpuFunction
> > ? |Reason jdk.vm.ci.code.BailoutException: Too deep inlining,
> > probably
> > caused by recursive inlining. Inlined methods ordered by inlining
> > frequency:
> > java.util.ResourceBundle.getObject(String) [488]
> > java.text.DecimalFormatSymbols.getInstance(Locale) [1]
> > java.util.Formatter.<init>(Locale, Appendable) [1]
> > com.oracle.graal.truffle.OptimizedCallTarget.callRoot(Object[]) [1]
> > java.lang.String.format(String, Object[]) [1]
> > com.oracle.graal.truffle.OptimizedCallTarget.callProxy(VirtualFrame
> > )
> > [1]
> > java.text.DecimalFormatSymbols.<init>(Locale) [1]
> > java.util.Formatter.getZero(Locale) [1]
> > com.oracle.truffle.r.nodes.function.FunctionDefinitionNode.gpuExecu
> > tion
> > (VirtualFrame) [1]
> > java.text.DecimalFormatSymbols.initialize(Locale) [1]
> > com.oracle.truffle.r.runtime.RInternalError.<init>(Throwable,
> > String,
> > Object[]) [1]
> > java.util.Formatter.<init>() [1]
> > com.oracle.truffle.r.nodes.function.FunctionDefinitionNode.execute(
> > Virt
> > ualFrame) [1]
> > sun.util.locale.provider.LocaleResources.getDecimalFormatSymbolsDat
> > a()
> > [1]
> > sun.util.locale.provider.DecimalFormatSymbolsProviderImpl.getInstan
> > ce(L
> > ocale) [1]
> > 
> > 
> > It does work if, instead of returning as S3 object, I return an
> > RList.
> > 
> > <code>
> > gpuFunction <- function(x) {
> > ?????list(name="tuple2",x,x)
> > }
> > </code>
> > 
> > As a work around I am working with RList directly, but I would like
> > to return an S3 object. Any idea is welcome.
> > 
> > Cheers
> > Juan
> > 
> > 
> > 
> > 
> > The University of Edinburgh is a charitable body, registered in
> > Scotland, with registration number SC005336.
> > 

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From doug.simon at oracle.com  Mon Jul 11 12:28:15 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 11 Jul 2016 14:28:15 +0200
Subject: Updating truffle import in graal-core
Message-ID: <5A6D5290-B974-4D05-AD12-31A1E378A606@oracle.com>

I?m planning on updating graal-core with the latest Truffle changes. Please let me know asap if I should hold off on this. I will make the change tomorrow morning (CEST) if I don?t hear any objections. The commits included in the update are listed below.

-Doug

commit 5878a3b8e6e042fe8a8a64d474fef88af89171cb
Merge: ed80f7f 930786b
Author: Doug Simon <doug.simon at oracle.com>
Date:   Mon Jul 11 04:37:08 2016 -0700

    Merge pull request #126 in G/truffle from topic/gate-on-jdk9 to master
    
    * commit '930786b0219577b7e9ac3a22d9efae07f185397a':
      re-enable jdk8 gating
      make SeparateClassloaderTestRunner work on jdk9
      omit javadoc from gate on JDK9
      adapt to change in name of hs-comp snapshot JDK 9 binary
      workaround for Eclipse formatter behaviour being different on jdk8 and jdk9
      add jdk9 to gate

commit 930786b0219577b7e9ac3a22d9efae07f185397a
Author: Doug Simon <doug.simon at oracle.com>
Date:   Mon Jul 11 13:22:39 2016 +0200

    re-enable jdk8 gating

commit ed80f7fe0bb17898a65822feabf84c7b4b3b0e17
Merge: a5e8309 3ca08c7
Author: Benoit Daloze <benoit.d.daloze at oracle.com>
Date:   Mon Jul 11 04:11:55 2016 -0700

    Merge pull request #12 in G/truffle from eregon-dsl-bug to master
    
    * commit '3ca08c7bb8628665580317807776648d5504d6db':
      Add failing test for DSL processor bug with negated guard + @Cached.

commit 3ca08c7bb8628665580317807776648d5504d6db
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Tue Apr 12 16:06:12 2016 +0200

    Add failing test for DSL processor bug with negated guard + @Cached.

commit 83130cc1bac5fc8414d768d193767caf6933a4ea
Author: Jaroslav Tulach <jaroslav.tulach at oracle.com>
Date:   Mon Jul 11 12:10:14 2016 +0200

    make SeparateClassloaderTestRunner work on jdk9

commit 3a676cf26df8eeaa73244bec4f44bcc34df4071b
Author: Doug Simon <doug.simon at oracle.com>
Date:   Mon Jul 11 11:30:08 2016 +0200

    omit javadoc from gate on JDK9

commit 00477bb35686cdb163e50cee6a3f03562f938e44
Author: Doug Simon <doug.simon at oracle.com>
Date:   Mon Jul 11 10:58:37 2016 +0200

    adapt to change in name of hs-comp snapshot JDK 9 binary

commit a5e8309e1ac3376597512192dd94d5e182236230
Merge: 3e3e3d2 95f93a1
Author: Andreas Woess <andreas.woess at oracle.com>
Date:   Fri Jul 8 08:43:30 2016 -0700

    Merge pull request #125 in G/truffle from fix_valuelocation_canstore to master
    
    * commit '95f93a11e9b092f6eb32de7ce6472c71ad6eb766':
      Remove invalid assertion
      Use Objects.equals in ValueLocation.
      Add tests for ConstantLocation
      Fix ValueLocation.canStore

commit 95f93a11e9b092f6eb32de7ce6472c71ad6eb766
Author: Andreas Woess <andreas.woess at oracle.com>
Date:   Fri Jul 8 14:29:36 2016 +0200

    Remove invalid assertion

commit 3e3e3d2c5d2dcfbc9b70f94f1bf1dc7be033b8cc
Merge: 98add2b 11afa09
Author: Daniele Bonetta <daniele.bonetta at oracle.com>
Date:   Thu Jul 7 09:24:57 2016 -0700

    Merge pull request #128 in G/truffle from ~DANIELE.BONETTA_ORACLE.COM/truffle:bugfix/dsl to master
    
    * commit '11afa090040be1350b7602f9fb07cc5ff5e971ae':
      Fix Interop DSL such that it does not generate unused imports. Interop DSL generates default message resolutions for predicate messages (e.g. IS_BOXED) and returns false if not otherwise specified. The default implementation requires an import of RootNode. This fix avoids an unused import if Interop DSL does not need to generate any default message resolution because all predicate messages are implemented using the Resolve annotation.

commit 11afa090040be1350b7602f9fb07cc5ff5e971ae
Author: Daniele Bonetta <daniele.bonetta at oracle.com>
Date:   Thu Jul 7 17:15:49 2016 +0200

    Fix Interop DSL such that it does not generate unused imports.
    Interop DSL generates default message resolutions for predicate messages (e.g. IS_BOXED) and returns false if not otherwise specified. The default implementation requires an import of RootNode. This fix avoids an unused import if Interop DSL does not need to generate any default message resolution because all predicate messages are implemented using the Resolve annotation.

commit 2206daf6e380a2084ab4dce408061685aa3539d2
Author: Doug Simon <doug.simon at oracle.com>
Date:   Wed Jul 6 16:03:10 2016 +0200

    workaround for Eclipse formatter behaviour being different on jdk8 and jdk9

commit fb78172d98b0d356d095d822c3818f95d834851b
Author: Doug Simon <doug.simon at oracle.com>
Date:   Wed Jul 6 15:13:54 2016 +0200

    add jdk9 to gate

commit 98add2bdcd72f3771c2492c99a86886c38bc6f0c
Merge: fcd8db4 5a9dc5d
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Tue Jul 5 12:50:51 2016 -0700

    Merge pull request #98 in G/truffle from ~MICHAEL.VAN.DE.VANTER_ORACLE.COM/truffle:feature/trufffle-profiler-upgrade to master
    
    * commit '5a9dc5d71c1abff093367681d78ed5ec9088df82':
      Profiler:  class Javadoc
      Profiler:  rename TruffleProfilerTest to Profiler test for name consistency
      Profiler: public methods now throw IllegalStateException if profiler has been disposed.
      Profiler:  invert and rename the Instrument and Client API class, now ProfilerInstrument and Profiler respectively, other minor cleanups and fixes.
      TruffleProfiler:  replace property-based test access with a documented, tested, client API.  Allows dynamic changing of parameters specifying what is being collected, for use in interactive contexts.

commit 5a9dc5d71c1abff093367681d78ed5ec9088df82
Merge: 577a606 fcd8db4
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Tue Jul 5 12:05:26 2016 -0700

    Merge branch 'master' into feature/trufffle-profiler-upgrade
    
    * master: (55 commits)
      Stop if there are less shapes than requested top results
      Rename the counter of objects in ShapeProfiler
      Fix ShapeStats#add in ShapeProfiler for primitive locations
      SourceSection:  include a test that now passes
      More detailed description of the LoadSourceListener & co.
      Stefan Marr observed an incompatible change in version 0.15
      TCK:  testRootNode now works around possible loading of prologue code before the text code is run
      Imports fix
      InstrumentationTestLanguage:  fix parser bug
      Debugger:  remove unneeded catch in a test
      TCK:  shouldn't place test assertions in side Truffle event handling code, failure obscures actual failure
      Applying the rename refactoring also to Javadoc comments
      Improving the word order
      Snapshot of the API of upcoming Truffle version 0.15
      A note about Source.isInternal()
      LoadSourceListener is more suitable name for listener for LoadSourceEvent
      ExplodeLoop.LoopExplosionKind is being introduced in version 0.15
      Describing what is new in version 0.15
      Recognize MIME type of all files in the test
      Documenting how to rewrite Source.fromFileName to Source.newBuilder
      ...
    
    # Conflicts:
    #	truffle/com.oracle.truffle.tools.test/src/com/oracle/truffle/tools/TruffleProfilerTest.java

commit 3103e190166160d9e40ac4b2c22dee18c6df9c47
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Mon Jul 4 18:33:08 2016 +0200

    Use Objects.equals in ValueLocation.

commit 1a923e81e0ba9b1f5f16ada63fcfd43de5891675
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Mon Jul 4 17:54:57 2016 +0200

    Add tests for ConstantLocation

commit 65fea1e94d1e7bec6a32fdfbf426ed277b1b5e62
Author: Andreas Woess <andreas.woess at oracle.com>
Date:   Thu Jun 23 15:45:56 2016 +0200

    Fix ValueLocation.canStore

commit fcd8db4cb5ec57b268df4f5b92320f57977d348f
Merge: e9295e8 dd2b5c9
Author: Benoit Daloze <benoit.d.daloze at oracle.com>
Date:   Mon Jul 4 08:13:47 2016 -0700

    Merge pull request #124 in G/truffle from fix_shape_profiler to master
    
    * commit 'dd2b5c90216a03268e5776be658e8a2dadbb6433':
      Stop if there are less shapes than requested top results
      Rename the counter of objects in ShapeProfiler
      Fix ShapeStats#add in ShapeProfiler for primitive locations

commit dd2b5c90216a03268e5776be658e8a2dadbb6433
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Mon Jul 4 16:39:47 2016 +0200

    Stop if there are less shapes than requested top results

commit 1ce6e6119bc0f2fcfc20b62b544b2f580c1cc304
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Mon Jul 4 16:31:40 2016 +0200

    Rename the counter of objects in ShapeProfiler

commit dfd3b9a219a8dfdbbd93533d139e28dbf717ebb3
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Mon Jul 4 16:30:43 2016 +0200

    Fix ShapeStats#add in ShapeProfiler for primitive locations

commit e9295e8888957e1d49c7377b0ee04c5bfdc60021
Merge: 0ebaf5c f827720
Author: Jaroslav Tulach <jaroslav.tulach at oracle.com>
Date:   Sat Jul 2 00:04:16 2016 -0700

    Merge pull request #123 in G/truffle from ~MICHAEL.VAN.DE.VANTER_ORACLE.COM/truffle:bug/empty-source-section to master
    
    Including test that now passes.
    
    * commit 'f827720a2922962c3e869b17b9438a6324cf62a1':
      SourceSection:  include a test that now passes

commit f827720a2922962c3e869b17b9438a6324cf62a1
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Fri Jul 1 18:03:05 2016 -0700

    SourceSection:  include a test that now passes

commit 0ebaf5c96664d4396961e78086f895459a1d8e0f
Merge: 3bd5b92 fa12ae8
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Fri Jul 1 13:44:11 2016 -0700

    Merge pull request #118 in G/truffle from ~MICHAEL.VAN.DE.VANTER_ORACLE.COM/truffle:feature/debug-nesting-test to master
    
    * commit 'fa12ae84e38c345c31029c516437c2ececd5a5a3':
      Debugger:  remove unneeded catch in a test
      Debugger:  add tests for nested debugging contexts.
      Debugger:  extend AbstractDebugTest to support testing of nested executions and and SuspendedEvent.prepareKill()

commit 3bd5b92f8f9ba42d1164f70e0986a76b51801961
Merge: f14c28f 4420b84
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Fri Jul 1 13:43:32 2016 -0700

    Merge pull request #116 in G/truffle from ~MICHAEL.VAN.DE.VANTER_ORACLE.COM/truffle:bug/instrumentation-test-language-parser to master
    
    * commit '4420b845271e83dad0e73e80f2b5d9cf49b7767c':
      Imports fix
      InstrumentationTestLanguage:  fix parser bug
      InstrumentationTestLanguage:  test showing parser bug

commit f14c28f7e2247045b6eeddda08ec3afde57cb713
Merge: fbb6bb3 82a0204
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Fri Jul 1 13:42:55 2016 -0700

    Merge pull request #121 in G/truffle from ~MICHAEL.VAN.DE.VANTER_ORACLE.COM/truffle:bug/tck-root-name-fix to master
    
    * commit '82a0204638354258e4dac77db651f02833806d2c':
      TCK:  testRootNode now works around possible loading of prologue code before the text code is run
      TCK:  shouldn't place test assertions in side Truffle event handling code, failure obscures actual failure

commit 82a0204638354258e4dac77db651f02833806d2c
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Wed Jun 29 17:18:26 2016 -0700

    TCK:  testRootNode now works around possible loading of prologue code before the text code is run

commit 4420b845271e83dad0e73e80f2b5d9cf49b7767c
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Wed Jun 29 16:45:34 2016 -0700

    Imports fix

commit d686124f25b3d582afe1d33e5218a7e0e367c5c6
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Wed Jun 29 16:42:27 2016 -0700

    InstrumentationTestLanguage:  fix parser bug

commit fa12ae84e38c345c31029c516437c2ececd5a5a3
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Wed Jun 29 11:56:36 2016 -0700

    Debugger:  remove unneeded catch in a test

commit 6e6185fd6498d2c8a31798eba1c4ac4e16a92ed2
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Wed Jun 29 11:45:34 2016 -0700

    TCK:  shouldn't place test assertions in side Truffle event handling code, failure obscures actual failure

commit e9033aba64e9ca233b1e420792f0f99c076dc27c
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Tue Jun 28 17:21:09 2016 -0700

    Debugger:  add tests for nested debugging contexts.

commit 613daa9f8c1e70e07390033a733a369b0e127379
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Tue Jun 28 17:20:05 2016 -0700

    Debugger:  extend AbstractDebugTest to support testing of nested executions and and SuspendedEvent.prepareKill()

commit 7432a2f4e91c0b9346e7774bd3d7355ce4cfafa2
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Mon Jun 27 17:05:56 2016 -0700

    InstrumentationTestLanguage:  test showing parser bug

commit 577a60650f685c10f7d909419862715931b68253
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Mon Jun 27 15:54:43 2016 -0700

    Profiler:  class Javadoc

commit 5429d7533552f5dba002964fad555997bbcf6a4a
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Thu Jun 23 17:33:11 2016 -0700

    Profiler:  rename TruffleProfilerTest to Profiler test for name consistency

commit 29f77287a9c7fc917aee41a786cb6d3302d5fac6
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Thu Jun 23 17:31:51 2016 -0700

    Profiler: public methods now throw IllegalStateException if profiler has been disposed.

commit 33d08b6e1fe368b85f1ca2c7a67ec245110dd7db
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Wed Jun 22 18:31:20 2016 -0700

    Profiler:  invert and rename the Instrument and Client API class, now ProfilerInstrument and Profiler respectively, other minor cleanups and fixes.

commit 8c30c59bff2bfc8a2d07461d88c62709582dfb45
Author: Michael Van De Vanter <michael.van.de.vanter at oracle.com>
Date:   Tue Jun 21 15:20:27 2016 -0700

    TruffleProfiler:  replace property-based test access with a documented, tested, client API.  Allows dynamic changing of parameters specifying what is being collected, for use in interactive contexts.


From jaroslav.tulach at oracle.com  Wed Jul 13 17:23:55 2016
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Wed, 13 Jul 2016 19:23:55 +0200
Subject: Heads up: Source incompatible change in Truffle PolyglotEngine API
Message-ID: <3010602.rV1cy3JIUT@pracovni>

Dear Truffle users,
I am preparing long awaited removal of few "throws IOException" statements 
from PolyglotEngine and related classes. See

https://github.com/jtulach/truffle/commit/cd6ebeca83404f05e6302c6f7e8b5cde7a32e441

Alas, the removal isn't source compatible. It may happen you will need to 
remove statements like

try {
  /// call to PolyglotEngine
} catch (IOException ex) {
  ...
}

or 

void x() throws IOException { 
  // call to PolyglotEngine
}

because the javac may complain that the code in question isn't allowed to 
throw such exception and that there is no point in catching it. Rewrite such 
code for example to:

try {
  // call to PolyglotEngine
} catch (Exception ex) {
  ...
}

or remove the "throws IOException" altogether. I'll go through the code I know 
and try to prepare patches, so it compiles.

I am sorry for problems caused by my premature use of IOException.
-jt

PS: In spite of this action I swear I love checked exceptions!



From java at stefan-marr.de  Fri Jul 15 14:52:54 2016
From: java at stefan-marr.de (Stefan Marr)
Date: Fri, 15 Jul 2016 16:52:54 +0200
Subject: CFP: 1st Workshop on Meta-Programming Techniques and Reflection
	(META) with SPLASH 2016
Message-ID: <385376FB-1E72-467F-ABC3-2B7058BE4715@stefan-marr.de>

**Call for Papers**

========================================================================  
1st Workshop on Meta-Programming Techniques and Reflection (META?16)

Co-located with SPLASH 2016
October 30, 2016,  Amsterdam, Netherlands

http://2016.splashcon.org/track/meta2016
Follow us on twitter @MetaAtSPLASH
========================================================================  

The Meta?16 workshop aims to bring together researchers working on metaprogramming and reflection, as well as users building applications, language extensions such as contracts, or software tools. With the changing hardware and software landscape, and increased heterogeneity of systems, metaprogramming becomes an important research topic to handle the associate complexity once more. Contributions to the workshop are welcome on a wide range of topics related to design, implementation, and application of metaprogramming techniques, as well as empirical studies on and typing for such systems and languages.

### Important Dates

08 Aug 2016 - Abstract Submission
15 Aug 2016 - Paper Submission
05 Sep 2016 - Notification
09 Sep 2016 - Demo, position or work-in-progress paper submission
23 Sep 2016 - Demo, position or work-in-progress paper notification
30 Oct 2016 Workshop

### Topics of Interest

The workshop is a venue for all approaches that embrace metaprogramming:
- from static to dynamic techniques
- reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs
- optimization techniques to minimize runtime overhead
- contract systems, or typing of reflective programs reflection and metaobject protocols to enable tooling
- case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools
- empirical evaluation of metaprogramming solutions
- security in reflective systems and capability-based designs
- meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc)
- surveys, conceptualization, and taxonomization of existing approaches

### Types of Submissions and Workshop format

We welcome both technical papers and work-in-progress and position papers from the academic as well as industrial perspective. Position paper should present new ideas and emerging problems and take a perhaps controversial stance on a specific topic and argue the position well. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas.

The workshop papers will be put on the workshop website, if not requested otherwise by the authors, but they are not part of formal proceedings. Papers are to be submitted using the ACM sigplanconf style at 10pt font size. See http://www.sigplan.org/Resources/Author/.

- demos and posters: 1-page abstract
- position and work-in-progress paper: 1-4 pages
- technical paper: up to 8 pages

Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work.

For the submission, please use the submission system at: https://meta16.hotcrp.com/

### Organizing Committee

Shigeru Chiba, University of Tokyo
Elisa Gonzalez Boix, Vrije Universiteit Brussel
Stefan Marr, Johannes Kepler University Linz

### Program Committee

Marcus Denker, INRIA, France
Robert Hirschfeld, HPI, Germany
Hridesh Rajan, Iowa State University, USA
Romain Rouvoy, University Lille 1 and INRIA, France
Eric Tanter, University of Chile, Chile
Tom Van Cutsem, Bell Labs, Belgium
Tijs van der Storm, CWI, Netherlands
Takuo Watanabe, Tokyo Institute of Technology, Japan

From raffaello.giulietti at supsi.ch  Sun Jul 17 18:12:32 2016
From: raffaello.giulietti at supsi.ch (Raffaello Giulietti)
Date: Sun, 17 Jul 2016 18:12:32 +0000
Subject: Interesting talks by Gilles and Chris
Message-ID: <26b4951f-0326-0612-4b38-707113b623f7@supsi.ch>

Hello,

I just happened to watch at two interesting talks, both by members of
the Graal+Truffle project at Oracle Labs. So, for the rest of us, here
are the relevant links.



The first is by Gilles Duboscq about "Speculative optimizations in the
Graal Just-In-Time compiler". Besides an interesting discussion about
some optimizations and how they interplay with deoptimizations, the
takeaway is that Gilles and company managed to reduce the memory
footprint for deoptimization metadata of the Truffle based JavaScript
implementation by around 90%, bringing it on par with that of Java! I
think this is a terrific achievement.

https://www.youtube.com/watch?v=HxBeALYQDUU
https://archive.org/download/vmss16/duboscq.pdf



The second talk is by Chris Seaton about "JRuby+Truffle, Why it?s
important to optimise the tricky parts". Chris gives convincing
arguments that idiomatic abstractions that Ruby programmers (and others
as well, I add) use everyday in real world applications and libraries
shall receive full support from the implementation and that this is
doable on Graal+Truffle with reasonable efforts.

https://www.youtube.com/watch?v=b1NTaVQPt1E
https://archive.org/download/vmss16/seaton.pdf



For other interesting talks at the same event:
http://soft-dev.org/events/vmss16/



Greetings
Raffaello

From Matthias.Grimmer at jku.at  Mon Jul 18 07:29:09 2016
From: Matthias.Grimmer at jku.at (Matthias Grimmer)
Date: Mon, 18 Jul 2016 09:29:09 +0200
Subject: Call for Papers: 1st Workshop on ReUsable and Modular Programming
	Language Ecosystems (RUMPLE'16)
Message-ID: <1B8A62AF-EBCB-4A24-BA6C-22ACA016A344@jku.at>

============================================================================
                        Call for Papers: RUMPLE?16
                                      
                    1st Workshop on ReUsable and Modular
                      Programming Language Ecosystems
                                      
                           Co-located with SPLASH
                   Oct/Nov, 2016, Amsterdam, Netherlands
                                      
                 http://2016.splashcon.org/track/rumple2016
============================================================================

The RUMPLE workshop is a venue for discussing modular approaches to
programming language implementations, extensible virtual machine
architectures, as well as reusable runtime components such as dynamic
compilers, interpreters, or garbage collectors. The main goal of the workshop
is to bring together researchers and practitioners, and facilitate the
sharing of experiences and ideas.

Relevant topics include, but are definitely not limited to, the following:

- Extensible VM design (compiler- or interpreter-based VMs)
- Reusable implementation of runtime components (e.g. interpreters, garbage
  collectors, intermediate representations)
- Static and dynamic compiler techniques for different languages
- Multi-language runtimes and mechanisms for cross-language interoperability
  between different languages
- Tooling support for different languages (e.g. debugging, profiling, etc.)
- Modular language implementations that use existing frameworks and systems
- Case studies of existing language implementations, virtual machines, and
  runtime components (e.g. design choices, tradeoffs, etc.)
- New research ideas on how we want to build languages in the future.


  Workshop Format and Submissions

This workshop welcomes the presentation and discussion of new ideas and
emerging problems that give a chance for interaction and exchange.
We accept presentation proposals in the form of extended abstracts (1-4
pages). Accepted abstracts will be published on the workshop's website before
the workshop date.

Submissions should use the ACM SIGPLAN Conference Format, 10 point font,
using the font family Times New Roman and numeric citation style. All
submissions should be in PDF format.

Please submit abstracts through http://ssw.jku.at/rumple/


  Important Dates

- Exended abstract submission: 1 Aug 2016
- Author notification: 5 Sep 2016
All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC?12:00 hour
- Workshop: 31 Oct 2016


  Program Committee

Walter Binder, University of Lugano
Carl Friedrich Bolz, King's College London
Richard Jones, University of Kent
Stephen Kell, University of Cambridge
Jan Vitek, Northeastern University
Christian Wimmer, Oracle Labs


  Workshop Organizers

Matthias Grimmer, Johannes Kepler University Linz, Austria
Laurence Tratt, King's College London, United Kingdom
Adam Welc, Oracle Labs, United States

For questions or concerns, please mail to matthias.grimmer at jku.at

From michael.c.berg at intel.com  Wed Jul 20 20:05:18 2016
From: michael.c.berg at intel.com (Berg, Michael C)
Date: Wed, 20 Jul 2016 20:05:18 +0000
Subject: code review request for exp and pow additions
Message-ID: <C568518E7B433348B114B6A7122D474756EC937C@FMSMSX102.amr.corp.intel.com>

Subject: code review request for exp and pow intrinsic additions for x86

Folks, the code is available as:

https://github.com/graalvm/graal-core/pull/198
For review.  

This change stages the first installment of intel libm intrinsics (exp, pow). 
For exp the uplift is 4x, the pow the uplift is 2.6x.

Regards,
Michael

From raffaello.giulietti at supsi.ch  Wed Jul 20 21:56:54 2016
From: raffaello.giulietti at supsi.ch (Raffaello Giulietti)
Date: Wed, 20 Jul 2016 21:56:54 +0000
Subject: code review request for exp and pow additions
In-Reply-To: <C568518E7B433348B114B6A7122D474756EC937C@FMSMSX102.amr.corp.intel.com>
References: <C568518E7B433348B114B6A7122D474756EC937C@FMSMSX102.amr.corp.intel.com>
Message-ID: <876b8dbd-c4c1-5447-901d-cf4bf6047df2@supsi.ch>

Hi Michael,

just curious about rounding guarantees of the intrinsics on the x86.



On 2016-07-20 20:05, Berg, Michael C wrote:
> Subject: code review request for exp and pow intrinsic additions for x86
> 
> Folks, the code is available as:
> 
> https://github.com/graalvm/graal-core/pull/198
> For review.  
> 
> This change stages the first installment of intel libm intrinsics (exp, pow). 
> For exp the uplift is 4x, the pow the uplift is 2.6x.
> 
> Regards,
> Michael
> 


From michael.c.berg at intel.com  Wed Jul 20 23:41:16 2016
From: michael.c.berg at intel.com (Berg, Michael C)
Date: Wed, 20 Jul 2016 23:41:16 +0000
Subject: code review request for exp and pow additions
In-Reply-To: <876b8dbd-c4c1-5447-901d-cf4bf6047df2@supsi.ch>
References: <C568518E7B433348B114B6A7122D474756EC937C@FMSMSX102.amr.corp.intel.com>
	<876b8dbd-c4c1-5447-901d-cf4bf6047df2@supsi.ch>
Message-ID: <C568518E7B433348B114B6A7122D474756EC946D@FMSMSX102.amr.corp.intel.com>

Raffaello:

There is a header section above each intrinsic that goes into detail about expected behavior.  For the brevity of this email thread, I would advise reading there.
The short answer is that each is a mathematical expansion that is equated to x87 answers for the intrinsics that map there (log, log10, sin, cos, tan) as well as the strict math result which includes exp and pow.

Testing: 

For all we compare against strict math results, and with our tests we are not seeing divergence at this time.  We have extensive testing especially for sin and cos for large host of corner cases for which we pass.  Graal also has testing for each of these math functions in the unit tests.  Basically we are providing the same results that JDK9 does when these intrinsics are utilized in either location.

Regards,
Michael

-----Original Message-----
From: graal-dev [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Raffaello Giulietti
Sent: Wednesday, July 20, 2016 2:57 PM
To: graal-dev at openjdk.java.net
Subject: Re: code review request for exp and pow additions

Hi Michael,

just curious about rounding guarantees of the intrinsics on the x86.



On 2016-07-20 20:05, Berg, Michael C wrote:
> Subject: code review request for exp and pow intrinsic additions for x86
> 
> Folks, the code is available as:
> 
> https://github.com/graalvm/graal-core/pull/198
> For review.  
> 
> This change stages the first installment of intel libm intrinsics (exp, pow). 
> For exp the uplift is 4x, the pow the uplift is 2.6x.
> 
> Regards,
> Michael
> 


From thomas.wuerthinger at oracle.com  Thu Jul 21 14:34:21 2016
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Thu, 21 Jul 2016 16:34:21 +0200
Subject: Virtual Machine Meetup 2016 Program
Message-ID: <9B62C1CE-D13C-4CC5-9C0C-A883414E3541@oracle.com>

The program of the 3rd Virtual Machine Meetup 2016 in Lugano (Switzerland) is now online available at http://vmmeetup.github.io/2016/ <http://vmmeetup.github.io/2016/>. Topics include the Shenandoah GC, the new Scala compiler Dotty, the Graal JIT compiler, execution of LLVM-based languages on the JVM, hardware acceleration techniques, and more.

The event is on the 1st and 2nd of September. Registration is free of charge and open until 27th of July.

Regards, thomas

From thomas.wuerthinger at oracle.com  Thu Jul 21 15:43:28 2016
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Thu, 21 Jul 2016 17:43:28 +0200
Subject: code review request for exp and pow additions
In-Reply-To: <C568518E7B433348B114B6A7122D474756EC937C@FMSMSX102.amr.corp.intel.com>
References: <C568518E7B433348B114B6A7122D474756EC937C@FMSMSX102.amr.corp.intel.com>
Message-ID: <983B0A9F-D2BC-4F73-979A-FBDDC36860FB@oracle.com>

Thanks for the contribution!

Tom or Roland, can you take a look at integrating this change?

Thanks, thomas

> On 20 Jul 2016, at 22:05, Berg, Michael C <michael.c.berg at intel.com> wrote:
> 
> Subject: code review request for exp and pow intrinsic additions for x86
> 
> Folks, the code is available as:
> 
> https://github.com/graalvm/graal-core/pull/198
> For review.  
> 
> This change stages the first installment of intel libm intrinsics (exp, pow). 
> For exp the uplift is 4x, the pow the uplift is 2.6x.
> 
> Regards,
> Michael


From tom.rodriguez at oracle.com  Thu Jul 21 17:55:43 2016
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Thu, 21 Jul 2016 10:55:43 -0700
Subject: code review request for exp and pow additions
In-Reply-To: <983B0A9F-D2BC-4F73-979A-FBDDC36860FB@oracle.com>
References: <C568518E7B433348B114B6A7122D474756EC937C@FMSMSX102.amr.corp.intel.com>
	<983B0A9F-D2BC-4F73-979A-FBDDC36860FB@oracle.com>
Message-ID: <64BC2EC9-35BD-48F4-B107-70DED34EE031@oracle.com>

Yes I?m looking at it now.

tom

> On Jul 21, 2016, at 8:43 AM, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> 
> Thanks for the contribution!
> 
> Tom or Roland, can you take a look at integrating this change?
> 
> Thanks, thomas
> 
>> On 20 Jul 2016, at 22:05, Berg, Michael C <michael.c.berg at intel.com> wrote:
>> 
>> Subject: code review request for exp and pow intrinsic additions for x86
>> 
>> Folks, the code is available as:
>> 
>> https://github.com/graalvm/graal-core/pull/198
>> For review.  
>> 
>> This change stages the first installment of intel libm intrinsics (exp, pow). 
>> For exp the uplift is 4x, the pow the uplift is 2.6x.
>> 
>> Regards,
>> Michael
> 


From cthalinger at twitter.com  Thu Jul 21 18:24:57 2016
From: cthalinger at twitter.com (Christian Thalinger)
Date: Thu, 21 Jul 2016 08:24:57 -1000
Subject: Fwd: [graalvm/mx] Support exploded JDK. (#118)
References: <graalvm/mx/pull/118/c234336981@github.com>
Message-ID: <A7CC553C-156B-42C0-8552-E8FFC331C882@twitter.com>

I believe this is an error :-)  Can you guys fix that?

> Begin forwarded message:
> 
> From: graalvm bot <notifications at github.com>
> Subject: Re: [graalvm/mx] Support exploded JDK. (#118)
> Date: July 21, 2016 at 8:12:17 AM HST
> To: graalvm/mx <mx at noreply.github.com>
> Cc: christhalinger <cthalinger at twitter.com>, Author <author at noreply.github.com>
> Reply-To: graalvm/mx <reply+01055735b6b097269ed959cb3d17e13773c925cbc3b3cb8f92cf0000000113a8d28192a169ce09f26f0e at reply.github.com>
> 
> It appears that user Chris Thalinger with email address cthalinger -(at)- twitter -(dot)- com has not signed the Oracle Contributor Agreement <http://www.oracle.com/technetwork/community/oca-486395.html>.
> If you believe this is an error, please contact graal-dev at openjdk.java.net <mailto:graal-dev at openjdk.java.net>.
> 
> ?
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <https://github.com/graalvm/mx/pull/118#issuecomment-234336981>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQVXNQSMuCaRp37adMlm5c9IVJzJSsE5ks5qX7aBgaJpZM4JSEWA>.
> 


From thomas.wuerthinger at oracle.com  Fri Jul 22 09:22:11 2016
From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger)
Date: Fri, 22 Jul 2016 11:22:11 +0200
Subject: [graalvm/mx] Support exploded JDK. (#118)
In-Reply-To: <A7CC553C-156B-42C0-8552-E8FFC331C882@twitter.com>
References: <graalvm/mx/pull/118/c234336981@github.com>
	<A7CC553C-156B-42C0-8552-E8FFC331C882@twitter.com>
Message-ID: <5287DF00-ACA7-41D5-B079-0E68EE039710@oracle.com>

We will fix this. Twitter is also OCA signatory. - thomas

> On 21 Jul 2016, at 20:24, Christian Thalinger <cthalinger at twitter.com> wrote:
> 
> I believe this is an error :-)  Can you guys fix that?
> 
>> Begin forwarded message:
>> 
>> From: graalvm bot <notifications at github.com>
>> Subject: Re: [graalvm/mx] Support exploded JDK. (#118)
>> Date: July 21, 2016 at 8:12:17 AM HST
>> To: graalvm/mx <mx at noreply.github.com>
>> Cc: christhalinger <cthalinger at twitter.com>, Author <author at noreply.github.com>
>> Reply-To: graalvm/mx <reply+01055735b6b097269ed959cb3d17e13773c925cbc3b3cb8f92cf0000000113a8d28192a169ce09f26f0e at reply.github.com>
>> 
>> It appears that user Chris Thalinger with email address cthalinger -(at)- twitter -(dot)- com has not signed the Oracle Contributor Agreement <http://www.oracle.com/technetwork/community/oca-486395.html>.
>> If you believe this is an error, please contact graal-dev at openjdk.java.net <mailto:graal-dev at openjdk.java.net>.
>> 
>> ?
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub <https://github.com/graalvm/mx/pull/118#issuecomment-234336981>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQVXNQSMuCaRp37adMlm5c9IVJzJSsE5ks5qX7aBgaJpZM4JSEWA>.
>> 
> 


From cthalinger at twitter.com  Fri Jul 22 16:50:42 2016
From: cthalinger at twitter.com (Christian Thalinger)
Date: Fri, 22 Jul 2016 06:50:42 -1000
Subject: [graalvm/mx] Support exploded JDK. (#118)
In-Reply-To: <5287DF00-ACA7-41D5-B079-0E68EE039710@oracle.com>
References: <graalvm/mx/pull/118/c234336981@github.com>
	<A7CC553C-156B-42C0-8552-E8FFC331C882@twitter.com>
	<5287DF00-ACA7-41D5-B079-0E68EE039710@oracle.com>
Message-ID: <D75D3406-1A94-4E84-8A78-0B927D76E100@twitter.com>

Thanks.

> On Jul 21, 2016, at 11:22 PM, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> 
> We will fix this. Twitter is also OCA signatory. - thomas
> 
>> On 21 Jul 2016, at 20:24, Christian Thalinger <cthalinger at twitter.com> wrote:
>> 
>> I believe this is an error :-)  Can you guys fix that?
>> 
>>> Begin forwarded message:
>>> 
>>> From: graalvm bot <notifications at github.com>
>>> Subject: Re: [graalvm/mx] Support exploded JDK. (#118)
>>> Date: July 21, 2016 at 8:12:17 AM HST
>>> To: graalvm/mx <mx at noreply.github.com>
>>> Cc: christhalinger <cthalinger at twitter.com>, Author <author at noreply.github.com>
>>> Reply-To: graalvm/mx <reply+01055735b6b097269ed959cb3d17e13773c925cbc3b3cb8f92cf0000000113a8d28192a169ce09f26f0e at reply.github.com>
>>> 
>>> It appears that user Chris Thalinger with email address cthalinger -(at)- twitter -(dot)- com has not signed the Oracle Contributor Agreement <http://www.oracle.com/technetwork/community/oca-486395.html>.
>>> If you believe this is an error, please contact graal-dev at openjdk.java.net <mailto:graal-dev at openjdk.java.net>.
>>> 
>>> ?
>>> You are receiving this because you authored the thread.
>>> Reply to this email directly, view it on GitHub <https://github.com/graalvm/mx/pull/118#issuecomment-234336981>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQVXNQSMuCaRp37adMlm5c9IVJzJSsE5ks5qX7aBgaJpZM4JSEWA>.
>>> 
>> 
> 


From gerard at gerardkrol.nl  Sun Jul 24 08:12:33 2016
From: gerard at gerardkrol.nl (Gerard Krol)
Date: Sun, 24 Jul 2016 10:12:33 +0200
Subject: Open Source C/C++ Truffle languages available?
Message-ID: <CAFzGNhKuf88CAhxAqAn4Xk_5bW-5mXKXCxO0cY_kDtyApCJ2ew@mail.gmail.com>

Hi,

I've recently learned about Tuffle/Graal. It seems great technology.

I'm interested in running C++ code on the JVM, without resorting to the
(admittedly clever) Sulong hack. I've seen some presentations and read some
papers about a C implementation, but that one doesn't seem to be open
source. The same goes for the C extensions for JRuby. Is that correct?

If so, what are the reasons for not open sourcing it? Any plans to do so in
the future?

Regards,

Gerard

From chris.seaton at oracle.com  Sun Jul 24 13:19:45 2016
From: chris.seaton at oracle.com (Chris Seaton)
Date: Sun, 24 Jul 2016 14:19:45 +0100
Subject: Open Source C/C++ Truffle languages available?
In-Reply-To: <CAFzGNhKuf88CAhxAqAn4Xk_5bW-5mXKXCxO0cY_kDtyApCJ2ew@mail.gmail.com>
References: <CAFzGNhKuf88CAhxAqAn4Xk_5bW-5mXKXCxO0cY_kDtyApCJ2ew@mail.gmail.com>
Message-ID: <4FEFE529-C757-4AD3-885C-2B8B820C9FBB@oracle.com>

Hello Gerard,

The old C implementation was called TruffleC. It interpreted the C language AST. Sulong interprets the LLVM IR instead. That?s not really a huge difference in practice. LLVM IR is a bit like a linearised version of the AST and doesn?t include much lowering or optimisation. TruffleC uses the same clever hacks as Sulong.

JRuby's C extensions (which are still at an early stage) used to use TruffleC, but they now use Sulong.

TruffleC isn?t open source, and there aren?t any plans that I?m aware of to open source it. Sulong is open source already. If you were happy with the TruffleC approach there?s not any reason that I know of that would mean Sulong wouldn?t also be appropriate, so I see TruffleC as deprecated by Sulong which is why there isn?t a great demand to open source it.

Chris

> On 24 Jul 2016, at 09:12, Gerard Krol <gerard at gerardkrol.nl> wrote:
> 
> Hi,
> 
> I've recently learned about Tuffle/Graal. It seems great technology.
> 
> I'm interested in running C++ code on the JVM, without resorting to the
> (admittedly clever) Sulong hack. I've seen some presentations and read some
> papers about a C implementation, but that one doesn't seem to be open
> source. The same goes for the C extensions for JRuby. Is that correct?
> 
> If so, what are the reasons for not open sourcing it? Any plans to do so in
> the future?
> 
> Regards,
> 
> Gerard


From gerard at gerardkrol.nl  Sun Jul 24 14:53:22 2016
From: gerard at gerardkrol.nl (Gerard Krol)
Date: Sun, 24 Jul 2016 16:53:22 +0200
Subject: Open Source C/C++ Truffle languages available?
In-Reply-To: <4FEFE529-C757-4AD3-885C-2B8B820C9FBB@oracle.com>
References: <CAFzGNhKuf88CAhxAqAn4Xk_5bW-5mXKXCxO0cY_kDtyApCJ2ew@mail.gmail.com>
	<4FEFE529-C757-4AD3-885C-2B8B820C9FBB@oracle.com>
Message-ID: <CAFzGNhLYhLDyk0nmoW1xzReos95gOe-R1QDLLnAPDkcZWX5s8w@mail.gmail.com>

Hello Chris,

Thanks for your quick response. I'm interested in building a C++ like
language using Truffle, that would support a "sensible" subset of C++. It
would use garbage collection and provide memory safety though, as well as
other things that in my opinion are missing from C++. The language is
called "Cover" (for now).

I'm basing Cover on SimpleLanguage, and am currently using the Eclipse CDT
C++ parser. Currently it is in the "hello world + loops" phase. If you want
to follow along take a look at https://github.com/gerard-/cover .

Regards,

Gerard


On Sun, Jul 24, 2016 at 3:19 PM, Chris Seaton <chris.seaton at oracle.com>
wrote:

> Hello Gerard,
>
> The old C implementation was called TruffleC. It interpreted the C
> language AST. Sulong interprets the LLVM IR instead. That?s not really a
> huge difference in practice. LLVM IR is a bit like a linearised version of
> the AST and doesn?t include much lowering or optimisation. TruffleC uses
> the same clever hacks as Sulong.
>
> JRuby's C extensions (which are still at an early stage) used to use
> TruffleC, but they now use Sulong.
>
> TruffleC isn?t open source, and there aren?t any plans that I?m aware of
> to open source it. Sulong is open source already. If you were happy with
> the TruffleC approach there?s not any reason that I know of that would mean
> Sulong wouldn?t also be appropriate, so I see TruffleC as deprecated by
> Sulong which is why there isn?t a great demand to open source it.
>
> Chris
>
> > On 24 Jul 2016, at 09:12, Gerard Krol <gerard at gerardkrol.nl> wrote:
> >
> > Hi,
> >
> > I've recently learned about Tuffle/Graal. It seems great technology.
> >
> > I'm interested in running C++ code on the JVM, without resorting to the
> > (admittedly clever) Sulong hack. I've seen some presentations and read
> some
> > papers about a C implementation, but that one doesn't seem to be open
> > source. The same goes for the C extensions for JRuby. Is that correct?
> >
> > If so, what are the reasons for not open sourcing it? Any plans to do so
> in
> > the future?
> >
> > Regards,
> >
> > Gerard
>
>

From chris.seaton at oracle.com  Sun Jul 24 15:07:40 2016
From: chris.seaton at oracle.com (Chris Seaton)
Date: Sun, 24 Jul 2016 16:07:40 +0100
Subject: Open Source C/C++ Truffle languages available?
In-Reply-To: <CAFzGNhLYhLDyk0nmoW1xzReos95gOe-R1QDLLnAPDkcZWX5s8w@mail.gmail.com>
References: <CAFzGNhKuf88CAhxAqAn4Xk_5bW-5mXKXCxO0cY_kDtyApCJ2ew@mail.gmail.com>
	<4FEFE529-C757-4AD3-885C-2B8B820C9FBB@oracle.com>
	<CAFzGNhLYhLDyk0nmoW1xzReos95gOe-R1QDLLnAPDkcZWX5s8w@mail.gmail.com>
Message-ID: <EB126D4A-44E9-4E9D-A442-7DDD5977D337@oracle.com>

That sounds like a great project!

I think everything that would have been useful to you from TruffleC will have been re-implemented in Sulong. For example how to use our high performance native function interface, how to mix managed/native memory, and so on.

TruffleC did have some interesting work to support ASTs that included constructs like ?goto?. We can explain how that works to you if you need that later on.

Chris

> On 24 Jul 2016, at 15:53, Gerard Krol <gerard at gerardkrol.nl> wrote:
> 
> Hello Chris,
> 
> Thanks for your quick response. I'm interested in building a C++ like
> language using Truffle, that would support a "sensible" subset of C++. It
> would use garbage collection and provide memory safety though, as well as
> other things that in my opinion are missing from C++. The language is
> called "Cover" (for now).
> 
> I'm basing Cover on SimpleLanguage, and am currently using the Eclipse CDT
> C++ parser. Currently it is in the "hello world + loops" phase. If you want
> to follow along take a look at https://github.com/gerard-/cover .
> 
> Regards,
> 
> Gerard
> 
> 
> On Sun, Jul 24, 2016 at 3:19 PM, Chris Seaton <chris.seaton at oracle.com>
> wrote:
> 
>> Hello Gerard,
>> 
>> The old C implementation was called TruffleC. It interpreted the C
>> language AST. Sulong interprets the LLVM IR instead. That?s not really a
>> huge difference in practice. LLVM IR is a bit like a linearised version of
>> the AST and doesn?t include much lowering or optimisation. TruffleC uses
>> the same clever hacks as Sulong.
>> 
>> JRuby's C extensions (which are still at an early stage) used to use
>> TruffleC, but they now use Sulong.
>> 
>> TruffleC isn?t open source, and there aren?t any plans that I?m aware of
>> to open source it. Sulong is open source already. If you were happy with
>> the TruffleC approach there?s not any reason that I know of that would mean
>> Sulong wouldn?t also be appropriate, so I see TruffleC as deprecated by
>> Sulong which is why there isn?t a great demand to open source it.
>> 
>> Chris
>> 
>>> On 24 Jul 2016, at 09:12, Gerard Krol <gerard at gerardkrol.nl> wrote:
>>> 
>>> Hi,
>>> 
>>> I've recently learned about Tuffle/Graal. It seems great technology.
>>> 
>>> I'm interested in running C++ code on the JVM, without resorting to the
>>> (admittedly clever) Sulong hack. I've seen some presentations and read
>> some
>>> papers about a C implementation, but that one doesn't seem to be open
>>> source. The same goes for the C extensions for JRuby. Is that correct?
>>> 
>>> If so, what are the reasons for not open sourcing it? Any plans to do so
>> in
>>> the future?
>>> 
>>> Regards,
>>> 
>>> Gerard
>> 
>> 


From sid.kshatriya at gmail.com  Wed Jul 27 03:47:34 2016
From: sid.kshatriya at gmail.com (Sidharth Kshatriya)
Date: Wed, 27 Jul 2016 09:17:34 +0530
Subject: How to dump AST nodes of a small program (larger program works)?
Message-ID: <CAHZjNtZmF1MNvYeGkuK_QHss+MZA24GRZZXTwU9YGZnCtvqaGQ@mail.gmail.com>

Hi,

I am playing around with simplelanguage. To that end, I have a jvmci
compiler, graal-core, truffle, mx etc. all setup as explained on github.

Something like:

./sl -disassemble -dump tests/SumCall.sl

works properly and I can see the AST/Compilation passes in igv. However,
something like

./sl -disassemble -dump tests/HelloWorld.sl

does not show anything in igv. The program simply prints the result and
exists.

Is this because this program is being purely run in the AST interpreter?
Its a trivial program, I know, but I want to see the AST.

I'm on Truffle API 0.15 / jvmci 0.19-dev.

Thanks,

Sidharth

From gerard at gerardkrol.nl  Wed Jul 27 12:28:14 2016
From: gerard at gerardkrol.nl (Gerard Krol)
Date: Wed, 27 Jul 2016 14:28:14 +0200
Subject: Node specialization for a statically typed language?
Message-ID: <CAFzGNhJuJbL8WaCNOgMVHahScVykxXo=eL=5thUMuC2EkrE-mw@mail.gmail.com>

Hi,

With Cover[1] I'm implementing C/C++, which is statically typed. Currently
I'm using a single Add node, like SimpleLanguage does, with specializations
for long and double. Performance is fine, but I'm wondering if this is the
optimal way. I find I need to add quite a lot of guards to steer Truffle
towards the correct specialization. There is some info about specialization
in the Truffle FAQ, but it seems to be geared towards dynamic languages.

Can't I just emit AddLong and AddDouble nodes? I think it would make the
code a lot clearer, and save me from debugging code that picks the wrong
specialization. If the parameters to the node are not correct during parse
time I can just add a cast node in between.

Regards,

Gerard

[1] https://github.com/gerard-/cover

From chris.seaton at oracle.com  Wed Jul 27 12:34:51 2016
From: chris.seaton at oracle.com (Chris Seaton)
Date: Wed, 27 Jul 2016 13:34:51 +0100
Subject: Node specialization for a statically typed language?
In-Reply-To: <CAFzGNhJuJbL8WaCNOgMVHahScVykxXo=eL=5thUMuC2EkrE-mw@mail.gmail.com>
References: <CAFzGNhJuJbL8WaCNOgMVHahScVykxXo=eL=5thUMuC2EkrE-mw@mail.gmail.com>
Message-ID: <60000C75-50A0-439C-B163-BB4A8CF249ED@oracle.com>

Yes you can just use AddLong and AddDouble nodes directly. There?s no point to specialisation if you don?t need it. You?ll probably find you do want specialisation for other things - particularly C function pointer calls and C++ virtual calls. There?s an opportunity to beat native compiled C++ there because you can specialise for the concrete classes actually seen at a call site.

Chris

> On 27 Jul 2016, at 13:28, Gerard Krol <gerard at gerardkrol.nl> wrote:
> 
> Hi,
> 
> With Cover[1] I'm implementing C/C++, which is statically typed. Currently
> I'm using a single Add node, like SimpleLanguage does, with specializations
> for long and double. Performance is fine, but I'm wondering if this is the
> optimal way. I find I need to add quite a lot of guards to steer Truffle
> towards the correct specialization. There is some info about specialization
> in the Truffle FAQ, but it seems to be geared towards dynamic languages.
> 
> Can't I just emit AddLong and AddDouble nodes? I think it would make the
> code a lot clearer, and save me from debugging code that picks the wrong
> specialization. If the parameters to the node are not correct during parse
> time I can just add a cast node in between.
> 
> Regards,
> 
> Gerard
> 
> [1] https://github.com/gerard-/cover


From java at stefan-marr.de  Wed Jul 27 12:40:57 2016
From: java at stefan-marr.de (Stefan Marr)
Date: Wed, 27 Jul 2016 14:40:57 +0200
Subject: Node specialization for a statically typed language?
In-Reply-To: <CAFzGNhJuJbL8WaCNOgMVHahScVykxXo=eL=5thUMuC2EkrE-mw@mail.gmail.com>
References: <CAFzGNhJuJbL8WaCNOgMVHahScVykxXo=eL=5thUMuC2EkrE-mw@mail.gmail.com>
Message-ID: <FA918435-666E-45EE-9334-1DCB19A238DA@stefan-marr.de>

Hi Gerard:

> On 27 Jul 2016, at 14:28, Gerard Krol <gerard at gerardkrol.nl> wrote:
> 
> With Cover[1] I'm implementing C/C++, which is statically typed. Currently
> I'm using a single Add node, like SimpleLanguage does, with specializations
> for long and double. Performance is fine, but I'm wondering if this is the
> optimal way.

Using separate typed add nodes would be beneficial for interpreter speed (i.e. running without Graal).
So, it can be preferable.


> Can't I just emit AddLong and AddDouble nodes? I think it would make the
> code a lot clearer, and save me from debugging code that picks the wrong
> specialization. If the parameters to the node are not correct during parse
> time I can just add a cast node in between.

I guess the details depend on your languages, but yes, separate nodes can work nicely.

Note however, that you might still want to do some specialization based on the Add semantics of your language.
Add comes in some languages with very specific overflow semantics that can be expensive to handle. So, there it is useful to speculate that adds don?t actually overflow.

Best regards
Stefan

-- 
Stefan Marr
Johannes Kepler Universit?t Linz
http://stefan-marr.de/research/




From gerard at gerardkrol.nl  Wed Jul 27 12:50:31 2016
From: gerard at gerardkrol.nl (Gerard Krol)
Date: Wed, 27 Jul 2016 14:50:31 +0200
Subject: Node specialization for a statically typed language?
In-Reply-To: <60000C75-50A0-439C-B163-BB4A8CF249ED@oracle.com>
References: <CAFzGNhJuJbL8WaCNOgMVHahScVykxXo=eL=5thUMuC2EkrE-mw@mail.gmail.com>
	<60000C75-50A0-439C-B163-BB4A8CF249ED@oracle.com>
Message-ID: <CAFzGNh+hC-C=esUYS6prwWTi64VXRVtK4gKb1r9FVNS0OM219w@mail.gmail.com>

Thanks Chris and Stefan, for your responses. Amazing to get two good
answers within a few minutes of sending a mail.

Regards,

Gerard

On Wed, Jul 27, 2016 at 2:34 PM, Chris Seaton <chris.seaton at oracle.com>
wrote:

> Yes you can just use AddLong and AddDouble nodes directly. There?s no
> point to specialisation if you don?t need it. You?ll probably find you do
> want specialisation for other things - particularly C function pointer
> calls and C++ virtual calls. There?s an opportunity to beat native compiled
> C++ there because you can specialise for the concrete classes actually seen
> at a call site.
>
> Chris
>
> > On 27 Jul 2016, at 13:28, Gerard Krol <gerard at gerardkrol.nl> wrote:
> >
> > Hi,
> >
> > With Cover[1] I'm implementing C/C++, which is statically typed.
> Currently
> > I'm using a single Add node, like SimpleLanguage does, with
> specializations
> > for long and double. Performance is fine, but I'm wondering if this is
> the
> > optimal way. I find I need to add quite a lot of guards to steer Truffle
> > towards the correct specialization. There is some info about
> specialization
> > in the Truffle FAQ, but it seems to be geared towards dynamic languages.
> >
> > Can't I just emit AddLong and AddDouble nodes? I think it would make the
> > code a lot clearer, and save me from debugging code that picks the wrong
> > specialization. If the parameters to the node are not correct during
> parse
> > time I can just add a cast node in between.
> >
> > Regards,
> >
> > Gerard
> >
> > [1] https://github.com/gerard-/cover
>
>

From gerard at gerardkrol.nl  Wed Jul 27 14:35:09 2016
From: gerard at gerardkrol.nl (Gerard Krol)
Date: Wed, 27 Jul 2016 16:35:09 +0200
Subject: Implementing lexical scope for local variables
Message-ID: <CAFzGNh+KN=9UVEKMPfsmmBq3cqBDPhaEt0NP-1V36X6+79xfvg@mail.gmail.com>

Hello,

I'm currently implementing lexical scope for local variables. My first try
was to just create a new FrameDescriptor for each block, so I could get
different FrameSlots with the same name. That turned out not to work, as
these frameslots appear to be an index into the frame, and actually refer
to the same stored value.

I now created a workaround where use a single FrameDescriptor. I just
rename the variables inside the block if they have the same name as one in
the outer scope, but I'm not sure that's such a good solution. Perhaps it
would be better to just create a new frame,

Any advice?

Regards,

Gerard

From java at stefan-marr.de  Wed Jul 27 14:46:47 2016
From: java at stefan-marr.de (Stefan Marr)
Date: Wed, 27 Jul 2016 16:46:47 +0200
Subject: Implementing lexical scope for local variables
In-Reply-To: <CAFzGNh+KN=9UVEKMPfsmmBq3cqBDPhaEt0NP-1V36X6+79xfvg@mail.gmail.com>
References: <CAFzGNh+KN=9UVEKMPfsmmBq3cqBDPhaEt0NP-1V36X6+79xfvg@mail.gmail.com>
Message-ID: <AF796282-F9D3-484F-B693-42DDA2717A07@stefan-marr.de>

Hi Gerard:

> On 27 Jul 2016, at 16:35, Gerard Krol <gerard at gerardkrol.nl> wrote:
> 
> I now created a workaround where use a single FrameDescriptor. I just
> rename the variables inside the block if they have the same name as one in
> the outer scope, but I'm not sure that's such a good solution. Perhaps it
> would be better to just create a new frame,

I?d assume that a single frame descriptor per method is the best way to go.
Otherwise, you?d need multiple truffle methods (root nodes) for a single conceptual method. This is structurally a little harder to handle (you need proper non-local variable access, potentially traversing truffle frames).

Variable names can be objects, if I recall correctly, so perhaps, you don?t need to use strings, which might give you also a little more info during debugging.

Generally, I?d avoid manually creating truffle frames, especially if that is not based on any performance issues you actually see on programs/benchmarks.
You might wonder about lifeness of values, for object slots, you might want to set them to null explicitly at the end of a scope, but this is also an optimization I would not worry about before getting things running on Graal.

Best regards
Stefan


-- 
Stefan Marr
Johannes Kepler Universit?t Linz
http://stefan-marr.de/research/




From doug.simon at oracle.com  Wed Jul 27 16:26:51 2016
From: doug.simon at oracle.com (Doug Simon)
Date: Wed, 27 Jul 2016 18:26:51 +0200
Subject: Updating truffle import in graal-core
Message-ID: <3FBD9A7A-40BD-48F0-B067-11371978BDE9@oracle.com>

I?m planning on updating graal-core with the latest Truffle changes. I need this as part of a change to switch from deploying Graal as a monolithic module on JDK9 to having the Graal module import (or `require`) a Truffle module.

Please let me know in the next 48 hours if I should hold off on this. The commits included in the update are listed below.

-Doug

commit 534a0391a33938b5d20b362c3f4988e90672bf0c
Merge: 7d9b6ee a000153
Author: Doug Simon <doug.simon at oracle.com>
Date:   Wed Jul 27 09:12:35 2016 -0700

    Merge pull request #154 in G/truffle from topic/non-monolithic-modules to master
    
    * commit 'a00015392117ccf90b9c1a9d8e9df1210989851d':
      define TRUFFLE_API as a Java module

commit a00015392117ccf90b9c1a9d8e9df1210989851d
Author: Doug Simon <doug.simon at oracle.com>
Date:   Tue Jul 26 14:16:56 2016 +0200

    define TRUFFLE_API as a Java module

commit 7d9b6ee982bfdfb37321870f7a81f77b2db9f064
Merge: 086bf88 9cae722
Author: Benoit Daloze <benoit.d.daloze at oracle.com>
Date:   Wed Jul 27 07:00:45 2016 -0700

    Merge pull request #152 in G/truffle from omdsl-build to master
    
    * commit '9cae722489f00beb66f823c82f32a760da555e7f':
      Allow to declare a build(*args) method instead of create- in the OM DSL

commit 086bf88308850af9930b3d80da4cee5bcdec7088
Merge: 0f666d1 91fc60b
Author: Jaroslav Tulach <jaroslav.tulach at oracle.com>
Date:   Wed Jul 27 01:58:32 2016 -0700

    Merge pull request #151 in G/truffle from ~JAROSLAV.TULACH_ORACLE.COM/truffle:NoMessageDigest to master
    
    * commit '91fc60b97b1dd110d5b331811a36b12f277eb49d':
      Don't assign value of a method parameter
      Replace the generic MessageDigest algorith with a home made one that doesn't require the whole cryptographic architecture and plugins.

commit 91fc60b97b1dd110d5b331811a36b12f277eb49d
Author: Jaroslav Tulach <jaroslav.tulach at oracle.com>
Date:   Wed Jul 27 10:25:49 2016 +0200

    Don't assign value of a method parameter

commit 9cae722489f00beb66f823c82f32a760da555e7f
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Tue Jul 26 18:52:27 2016 +0200

    Allow to declare a build(*args) method instead of create- in the OM DSL
    
    * Useful to pack arguments when caching the factory and
      using DynamicObjectFactory.newInstance(*args).

commit 8cc44b31ec7f0474a0182b79eb24568a8e859141
Author: Jaroslav Tulach <jaroslav.tulach at oracle.com>
Date:   Tue Jul 26 17:50:36 2016 +0200

    Replace the generic MessageDigest algorith with a home made one that doesn't require the whole cryptographic architecture and plugins.

commit 0f666d1a0c4eabc0d44d1a2ad75cebd3ea6dbadb
Merge: a034859 465a121
Author: Benoit Daloze <benoit.d.daloze at oracle.com>
Date:   Tue Jul 26 05:08:05 2016 -0700

    Merge pull request #150 in G/truffle from omdsl-incr-compilation to master
    
    * commit '465a1212869dbbfc0e1ec0108971299dd46b767d':
      Allow generated names for super layouts in OM DSL
      Compare types using Type.isSameType() in the OM DSL
      Fix compilation issues in the OM-DSL when some layouts are already generated
      Move a couple layouts in different files to test the OM-DSL processor better
      Fix typo in LayoutParser error reporting
      Reuse helpers in LayoutModel

commit 465a1212869dbbfc0e1ec0108971299dd46b767d
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Tue Jul 26 13:06:21 2016 +0200

    Allow generated names for super layouts in OM DSL

commit f24aac168662179469a1b06f21d4a4b9baca66d8
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Tue Jul 26 12:03:50 2016 +0200

    Compare types using Type.isSameType() in the OM DSL

commit 860c9fe35b6714a7a628662b6991ae68b669a66f
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Tue Jul 26 11:07:59 2016 +0200

    Fix compilation issues in the OM-DSL when some layouts are already generated
    
    * Just assume the name is right, an error will be appear
      in the generated file anyway if it is not matching.

commit 6df1c8c121b42662f747af75d524ff7cdbc6e00d
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Tue Jul 26 11:06:45 2016 +0200

    Move a couple layouts in different files to test the OM-DSL processor better

commit 83c226ac0e6c1ce46570bc560cf4f57818820a41
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Tue Jul 26 11:03:48 2016 +0200

    Fix typo in LayoutParser error reporting

commit d52cc3cb407cd56c55dc83abe43156030f08fb97
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Tue Jul 26 10:38:40 2016 +0200

    Reuse helpers in LayoutModel

commit a034859d6aa327f028c33f11473abe1cec27c2e9
Merge: fe927b7 eee7930
Author: Matthias Grimmer <matthias.g.grimmer at oracle.com>
Date:   Mon Jul 25 05:31:55 2016 -0700

    Merge pull request #147 in G/truffle from ~MATTHIAS.G.GRIMMER_ORACLE.COM/truffle:interop-dsl to master
    
    * commit 'eee7930437e699536ba63540b0dcf15c2f55f67f':
      Add JavaDoc to classes that are generated by interop DSL. This JavaDoc contains information about the class which was used to generate the new class. Also, this JavaDoc contains information about the receiver type that uses this class.

commit eee7930437e699536ba63540b0dcf15c2f55f67f
Author: Matthias Grimmer <grimmer at ssw.jku.at>
Date:   Fri Jul 22 13:07:18 2016 +0200

    Add JavaDoc to classes that are generated by interop DSL.
    This JavaDoc contains information about the class which was used to generate the new class.
    Also, this JavaDoc contains information about the receiver type that uses this class.

commit fe927b755f3eb6053c08413624530b46c6e4c8c4
Merge: 2eefb8e 3858178
Author: Benoit Daloze <benoit.d.daloze at oracle.com>
Date:   Sat Jul 23 08:43:57 2016 -0700

    Merge pull request #148 in G/truffle from om-factory-args-assert to master
    
    * commit '3858178ba882a8972d17b1fa5ea79dc1149c6882':
      Assert that the number of values provided to a DynamicObjectFactory matches the given ones

commit 3858178ba882a8972d17b1fa5ea79dc1149c6882
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Sat Jul 23 17:36:15 2016 +0200

    Assert that the number of values provided to a DynamicObjectFactory matches the given ones

commit 2eefb8ef4ced1ddb93ed59671c34b90e150dae4a
Merge: 623cd2b 87b2a86
Author: Benoit Daloze <benoit.d.daloze at oracle.com>
Date:   Wed Jul 20 05:36:13 2016 -0700

    Merge pull request #144 in G/truffle from om-fix-equals to master
    
    * commit '87b2a864aa7ca543f84956d22811dc92b7e22eb5':
      Implement PrimitiveLocationDecorator.hashCode()
      Add tests for location equals and delete
      Fix missing equals in location decorators
      Add more tests for Locations and implicit casts

commit 87b2a864aa7ca543f84956d22811dc92b7e22eb5
Author: Andreas Woess <andreas.woess at oracle.com>
Date:   Mon Jul 18 19:58:38 2016 +0200

    Implement PrimitiveLocationDecorator.hashCode()

commit 623cd2b2fe0c13f7eeae06a5fed966cf3c5ebe07
Merge: 993fb45 efc7310
Author: Christian Humer <christian.humer at oracle.com>
Date:   Mon Jul 18 10:52:00 2016 -0700

    Merge pull request #145 in G/truffle from ~CHRISTIAN.HUMER_ORACLE.COM/truffle:minor_fixes to master
    
    * commit 'efc7310c40c6bb68bc8a12cb4b3a439ac78f74e1':
      Fix @TypeCast and @TypeCheck javadoc.
      Make @NodeInfo inherited by subclassees.

commit da0685338fd8713cfed2df445a64e5c8c12d7ad6
Author: Andreas Woess <andreas.woess at oracle.com>
Date:   Mon Jul 18 17:53:34 2016 +0200

    Add tests for location equals and delete

commit f1d01ee8a27c083b52042ab604e9a41d735e1413
Author: Andreas Woess <andreas.woess at oracle.com>
Date:   Mon Jul 18 17:29:30 2016 +0200

    Fix missing equals in location decorators

commit efc7310c40c6bb68bc8a12cb4b3a439ac78f74e1
Author: Christian Humer <christian.humer at oracle.com>
Date:   Mon Jul 18 15:56:05 2016 +0200

    Fix @TypeCast and @TypeCheck javadoc.

commit 5089a017651e26771827f0e8a02388a6fde6d7bd
Author: Christian Humer <christian.humer at oracle.com>
Date:   Mon Jul 18 14:51:12 2016 +0200

    Make @NodeInfo inherited by subclassees.

commit 32be260e2ff921bdf2a9c466118fbb50a7ca5e6d
Author: Benoit Daloze <eregontp at gmail.com>
Date:   Wed Jul 13 16:01:35 2016 +0200

    Add more tests for Locations and implicit casts
    
    * Avoid depending on location classes.


From christian.humer at gmail.com  Wed Jul 27 21:00:09 2016
From: christian.humer at gmail.com (Christian Humer)
Date: Wed, 27 Jul 2016 21:00:09 +0000
Subject: How to dump AST nodes of a small program (larger program works)?
In-Reply-To: <CAHZjNtZmF1MNvYeGkuK_QHss+MZA24GRZZXTwU9YGZnCtvqaGQ@mail.gmail.com>
References: <CAHZjNtZmF1MNvYeGkuK_QHss+MZA24GRZZXTwU9YGZnCtvqaGQ@mail.gmail.com>
Message-ID: <em115642ab-7385-47e2-ac4d-6b56beb43cdf@grashalm-work>

Hi Sidharth,

As you have guessed correctly, the HelloWorld.sl program is too simple 
to cause any compilations. That's why you don't see any ASTs and graphs 
dumped to IGV.

You can choose modify HelloWorld.sl and add a loop similar to SumCall.sl 
so the hello world function gets hot enough to be compiled and dumped to 
IGV.
Besides that forcing a dump of the AST to IGV before compilation is not 
as easy as it probably should be. I cannot offer a simpler solution than 
modifying the SL program atm.

If you just want to see the AST. There is an easy way to print the AST 
to the console:
For that, modify SimpleLanguage and use the NodeUtil#printCompactTree 
utility to print the AST at a desired point in time. Please keep in mind 
that the resulting AST looks very different depending on if you print it 
before or after the first execution, as the AST specializes. If you want 
to print the uninitialized tree you might want to use the dumping 
utility in SLNodeFactory#finishFunction. If you want to print the AST 
after each execution, consider modifying 
SLDispatchNode#doDirect/doIndirect.

Hope this helps,

Cheers,
Christian


On 27.07.2016 05:47:34, "Sidharth Kshatriya" <sid.kshatriya at gmail.com> 
wrote:

>Hi,
>
>I am playing around with simplelanguage. To that end, I have a jvmci
>compiler, graal-core, truffle, mx etc. all setup as explained on 
>github.
>
>Something like:
>
>./sl -disassemble -dump tests/SumCall.sl
>
>works properly and I can see the AST/Compilation passes in igv. 
>However,
>something like
>
>./sl -disassemble -dump tests/HelloWorld.sl
>
>does not show anything in igv. The program simply prints the result and
>exists.
>
>Is this because this program is being purely run in the AST 
>interpreter?
>Its a trivial program, I know, but I want to see the AST.
>
>I'm on Truffle API 0.15 / jvmci 0.19-dev.
>
>Thanks,
>
>Sidharth


From michael.c.berg at intel.com  Thu Jul 28 21:26:17 2016
From: michael.c.berg at intel.com (Berg, Michael C)
Date: Thu, 28 Jul 2016 21:26:17 +0000
Subject: code review request for 3 address AVX additions
Message-ID: <C568518E7B433348B114B6A7122D474756ED3F62@FMSMSX102.amr.corp.intel.com>

Subject: Code review request for adding 3 address forms of binary operations so that we get better allocation and improved schedule ability.
                 All other kinds of SSE ops are auto propagated to AVX with no difference in usage model as our IR inputs a single source of data.

Folks, the code is available as:

https://github.com/graalvm/graal-core/pull/199 
For review.  

This change causes uplift in scimark.lu.large (8%) and scimark.lu.small (16%)

Regards,
Michael

From juan.fumero at ed.ac.uk  Fri Jul 29 10:00:20 2016
From: juan.fumero at ed.ac.uk (Juan Fumero)
Date: Fri, 29 Jul 2016 11:00:20 +0100
Subject: Nodes removal from the IR
Message-ID: <1469786420.6563.13.camel@ed.ac.uk>

Hi all,?
? I am trying to remove some nodes from the IR that I do not need for
the GPU execution.?

For instance, to remove some of the FixedGuard I do the following:

<code>
if (node instanceof FixedGuardNode) {
? ?node.replaceAtUsages(null);
? ?graph.removeFixed((FixedWithNextNode));
}
? ? ? ??
new CanonicalizerPhase().apply(graph, new PhaseContext(providers));
new DeadCodeEliminationPhase().apply(graph);
</code>

This works fine. However, when I try to remove other kind of nodes,
like UnsafeLoadNode, I get the following error:

[thread:1] scope: main
? [thread:1] scope: main.CleanPhase
????[thread:1] scope: main.CleanPhase.InterceptException
????Exception occurred in scope: main.CleanPhase.InterceptException
????Context obj com.oracle.graal.graph.VerificationError: cannot delete
node 74|UnsafeLoad because of predecessor: 72|LoadField#locals
????	at node: 74|UnsafeLoad
????Context obj com.oracle.truffle.r.library.gpu.phases.CleanPhase at 32dd
cca
internal error: com.oracle.truffle.r.runtime.RInternalError:
com.oracle.graal.graph.VerificationError: cannot delete node
74|UnsafeLoad because of predecessor: 72|LoadField#locals
	at node: 74|UnsafeLoad (see fastr_errors.log)


Because there is a dependency with LoadFieldNode. My question is, how
could I get rid of these kind of nodes? I am trying also to remove its
dependencies but I get the same error. I also tried to removed with
graph.removeFixed(node) but I get the error as well.?


Many thanks
Juan


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From sid.kshatriya at gmail.com  Sat Jul 30 11:38:05 2016
From: sid.kshatriya at gmail.com (Sidharth Kshatriya)
Date: Sat, 30 Jul 2016 17:08:05 +0530
Subject: How can I call sulong from simplelanguage?
Message-ID: <CAHZjNtY=Xoeg=BVJS8ZPG8LbuN1LnbBFA6NY4aRvhJ4UrNo4Tg@mail.gmail.com>

I want to be able to use the polyglot feature of the Truffle API to be able
to call sulong from, say, simple language.

How would I go about doing this?

I have additionally filed a ticket on the sulong project at github
https://github.com/graalvm/sulong/issues/350

I was not sure about the best way to approach this question -- whether to
file a ticket or write an email (as the answer will be useful to other
users of truffle/graal) so please forgive the duplication!

Thanks,

Sidharth

From sid.kshatriya at gmail.com  Sat Jul 30 12:48:33 2016
From: sid.kshatriya at gmail.com (Sidharth Kshatriya)
Date: Sat, 30 Jul 2016 18:18:33 +0530
Subject: SubstrateVM Questions
Message-ID: <CAHZjNtaBpSfWTw7kNYB-t-kEgwPS=mgraf8hX0HchBPoETztbA@mail.gmail.com>

Graal/Truffle with Sulong seems to be a really compelling platform to build
a programming language! Uniquely, there are also a large number of papers
that go into detail on how things work. Its well documented too!

There is one point of concern and that is the warm up time of any
programming language JIT built on truffle/graal. Many dynamic scripting
languages need to start up quickly and do their job. So while long running
scripts will do the job well I'm concerned about the merits of making a
dynamic language port using graal/truffle with the long warmup.

I learnt about SubstrateVM in which you AOT compile some code which fixes
startup time issues. Is that something that will be available to external
implementers? Or will this just be something for scripting engines
"blessed" by Oracle?

Also this SubstrateVM sounds like its going to have an embedded hotspot VM
(if I can imagine correctly). Does that have implications for any external
party wanting to distribute their scripting engine executable?

Any information will be extremely welcome!

Cheers,

Sidharth

From gerard at gerardkrol.nl  Sun Jul 31 09:45:43 2016
From: gerard at gerardkrol.nl (Gerard Krol)
Date: Sun, 31 Jul 2016 11:45:43 +0200
Subject: Profiling a Truffle language
Message-ID: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>

Hi,

The benchmark "Fannkuch" runs correctly using Cover[1], but it is about 10x
as slow as I'd like it to be (and much slower than "Mandelbrot"). I've
taken a look at the disassembly and there are a lot of calls to java
functions left. It's a bit hard to see with all the jumps ;)

The graph viewer is very interesting, but so many nodes are generated that
I can't really figure out what's going on there either. I'm assuming that
it's not too much of a problem if some calls won't get inlined, as long as
those are not in the slow path.

What I'd like to have is a simple profiler (preferably one using sampling),
that will point me to the actual slow statements in the source program. Is
something like that available or will I have to write something myself? In
the last case, I suppose I should be using the the Truffle Instrumentation
API[2]?

Regards,

Gerard

[1] https://github.com/gerard-/cover
[2] https://wiki.openjdk.java.net/display/Graal/Instrumentation+API

From java at stefan-marr.de  Sun Jul 31 10:13:47 2016
From: java at stefan-marr.de (Stefan Marr)
Date: Sun, 31 Jul 2016 12:13:47 +0200
Subject: Profiling a Truffle language
In-Reply-To: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>
References: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>
Message-ID: <85FEFCD5-7A22-47CE-AA72-747978CF1E31@stefan-marr.de>

Hi Gerard:


> On 31 Jul 2016, at 11:45, Gerard Krol <gerard at gerardkrol.nl> wrote:
> 
> What I'd like to have is a simple profiler (preferably one using sampling),
> that will point me to the actual slow statements in the source program. Is
> something like that available or will I have to write something myself? In
> the last case, I suppose I should be using the the Truffle Instrumentation
> API[2]?

There is a profiler already in the instrumentation framework.
I am not entirely sure, but I think the class is now named Profiler.
Things seem to have changed.

I am using it in SOMns: https://github.com/smarr/SOMns/blob/master/src/som/VM.java#L329
And I wrote some related notes up here: http://stefan-marr.de/2016/04/adding-debugging-support-to-a-truffle-language/

For the profiler, you?ll need to tag some node in each method as Root (RootTag: https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.api.instrumentation/src/com/oracle/truffle/api/instrumentation/StandardTags.java#L87) Or perhaps easier to find in the SimpleLanguage: https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLStatementNode.java#L99

Hope that gets you started.

Best regards
Stefan




-- 
Stefan Marr
Johannes Kepler Universit?t Linz
http://stefan-marr.de/research/




From chris.seaton at oracle.com  Sun Jul 31 11:58:25 2016
From: chris.seaton at oracle.com (Chris Seaton)
Date: Sun, 31 Jul 2016 12:58:25 +0100
Subject: Profiling a Truffle language
In-Reply-To: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>
References: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>
Message-ID: <2D6AFD7F-6F8A-42ED-897F-4AA97421556A@oracle.com>


> On 31 Jul 2016, at 10:45, Gerard Krol <gerard at gerardkrol.nl> wrote:
> 
> Hi,
> 
> The benchmark "Fannkuch" runs correctly using Cover[1], but it is about 10x
> as slow as I'd like it to be (and much slower than "Mandelbrot"). I've
> taken a look at the disassembly and there are a lot of calls to java
> functions left. It's a bit hard to see with all the jumps ;)

In a benchmark like fannkuch I would not expect to have any Java calls left in the graph. For example, we have none left when I run it using Ruby. Fannkuch is about reading and writing arrays and we should be able to do all of that without a call.

I would recommend looking at each of these Java calls and working out how to eliminate them through specialisation, guarding and caching using the normal Truffle techniques. You could give us some examples of calls that you aren?t sure how to remove and we can help you figure it out.

> The graph viewer is very interesting, but so many nodes are generated that
> I can't really figure out what's going on there either. I'm assuming that
> it's not too much of a problem if some calls won't get inlined, as long as
> those are not in the slow path.

It can be hard to read these graphs. When I see something I?m interested in from a big graph I usually try to simplify and work with micro benchmarks to isolate it, but that?s not always easy.

> What I'd like to have is a simple profiler (preferably one using sampling),
> that will point me to the actual slow statements in the source program. Is
> something like that available or will I have to write something myself? In
> the last case, I suppose I should be using the the Truffle Instrumentation
> API[2]?
> 
> Regards,
> 
> Gerard
> 
> [1] https://github.com/gerard-/cover
> [2] https://wiki.openjdk.java.net/display/Graal/Instrumentation+API


From gerard at gerardkrol.nl  Sun Jul 31 19:05:04 2016
From: gerard at gerardkrol.nl (Gerard Krol)
Date: Sun, 31 Jul 2016 21:05:04 +0200
Subject: Profiling a Truffle language
In-Reply-To: <85FEFCD5-7A22-47CE-AA72-747978CF1E31@stefan-marr.de>
References: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>
	<85FEFCD5-7A22-47CE-AA72-747978CF1E31@stefan-marr.de>
Message-ID: <CAFzGNhJPq8vzRE0byt1k73C3N0pfbEz1wFADhOR3r3Nrz7Duxg@mail.gmail.com>

Thanks, that was very helpful. It was quite hard to get it working, but I
managed. For me it's still called TruffleProfiler (version 0.15 of
Truffle). Weirdly enough it was not picking up the class from the
truffle-debug jar through the @Registration annotation, so I had to copy
the class over (just adding a derived class with the annotation worked as
well).

Chris, the slow part does seem to be the array copy part, not sure why as
Cover is fully typed so all nodes have just a single specialization. I'm
off investigating!

Regards,

Gerard

On Sun, Jul 31, 2016 at 12:13 PM, Stefan Marr <java at stefan-marr.de> wrote:

> Hi Gerard:
>
>
> > On 31 Jul 2016, at 11:45, Gerard Krol <gerard at gerardkrol.nl> wrote:
> >
> > What I'd like to have is a simple profiler (preferably one using
> sampling),
> > that will point me to the actual slow statements in the source program.
> Is
> > something like that available or will I have to write something myself?
> In
> > the last case, I suppose I should be using the the Truffle
> Instrumentation
> > API[2]?
>
> There is a profiler already in the instrumentation framework.
> I am not entirely sure, but I think the class is now named Profiler.
> Things seem to have changed.
>
> I am using it in SOMns:
> https://github.com/smarr/SOMns/blob/master/src/som/VM.java#L329
> And I wrote some related notes up here:
> http://stefan-marr.de/2016/04/adding-debugging-support-to-a-truffle-language/
>
> For the profiler, you?ll need to tag some node in each method as Root
> (RootTag:
> https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.api.instrumentation/src/com/oracle/truffle/api/instrumentation/StandardTags.java#L87)
> Or perhaps easier to find in the SimpleLanguage:
> https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLStatementNode.java#L99
>
> Hope that gets you started.
>
> Best regards
> Stefan
>
>
>
>
> --
> Stefan Marr
> Johannes Kepler Universit?t Linz
> http://stefan-marr.de/research/
>
>
>
>

From christian.humer at gmail.com  Sun Jul 31 19:15:01 2016
From: christian.humer at gmail.com (Christian Humer)
Date: Sun, 31 Jul 2016 19:15:01 +0000
Subject: Profiling a Truffle language
In-Reply-To: <CAFzGNhJPq8vzRE0byt1k73C3N0pfbEz1wFADhOR3r3Nrz7Duxg@mail.gmail.com>
References: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>
	<85FEFCD5-7A22-47CE-AA72-747978CF1E31@stefan-marr.de>
	<CAFzGNhJPq8vzRE0byt1k73C3N0pfbEz1wFADhOR3r3Nrz7Duxg@mail.gmail.com>
Message-ID: <em9a473e14-6f4a-4446-8c55-05c512b3751a@grashalm-work>

Hi Gerard,

On 31.07.2016 21:05:04, "Gerard Krol" <gerard at gerardkrol.nl> wrote:

>Thanks, that was very helpful. It was quite hard to get it working, but 
>I
>managed. For me it's still called TruffleProfiler (version 0.15 of
>Truffle). Weirdly enough it was not picking up the class from the
>truffle-debug jar through the @Registration annotation, so I had to 
>copy
>the class over (just adding a derived class with the annotation worked 
>as
>well).
>
Sorry to hear that. Did you put the truffle-debug.jar on the normal or 
boot classpath? Could you maybe copy in your java command line that you 
were using, so I can potentially reproduce it?

Please also note that this version of the TruffleProfiler is based on 
instrumentation and is quite heavy. Therefore its results might not be 
very reliable.
A more lightweight version based on sampling is coming soonish (1-3 
weeks) to the Truffle tip.

Cheers,

Christian


>
>Chris, the slow part does seem to be the array copy part, not sure why 
>as
>Cover is fully typed so all nodes have just a single specialization. 
>I'm
>off investigating!
>
>Regards,
>
>Gerard
>
>On Sun, Jul 31, 2016 at 12:13 PM, Stefan Marr <java at stefan-marr.de> 
>wrote:
>
>>  Hi Gerard:
>>
>>
>>  > On 31 Jul 2016, at 11:45, Gerard Krol <gerard at gerardkrol.nl> wrote:
>>  >
>>  > What I'd like to have is a simple profiler (preferably one using
>>  sampling),
>>  > that will point me to the actual slow statements in the source 
>>program.
>>  Is
>>  > something like that available or will I have to write something 
>>myself?
>>  In
>>  > the last case, I suppose I should be using the the Truffle
>>  Instrumentation
>>  > API[2]?
>>
>>  There is a profiler already in the instrumentation framework.
>>  I am not entirely sure, but I think the class is now named Profiler.
>>  Things seem to have changed.
>>
>>  I am using it in SOMns:
>>  https://github.com/smarr/SOMns/blob/master/src/som/VM.java#L329
>>  And I wrote some related notes up here:
>>  
>>http://stefan-marr.de/2016/04/adding-debugging-support-to-a-truffle-language/
>>
>>  For the profiler, you?ll need to tag some node in each method as Root
>>  (RootTag:
>>  
>>https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.api.instrumentation/src/com/oracle/truffle/api/instrumentation/StandardTags.java#L87)
>>  Or perhaps easier to find in the SimpleLanguage:
>>  
>>https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/SLStatementNode.java#L99
>>
>>  Hope that gets you started.
>>
>>  Best regards
>>  Stefan
>>
>>
>>
>>
>>  --
>>  Stefan Marr
>>  Johannes Kepler Universit?t Linz
>>  http://stefan-marr.de/research/
>>
>>
>>
>>


From gerard at gerardkrol.nl  Sun Jul 31 20:21:36 2016
From: gerard at gerardkrol.nl (Gerard Krol)
Date: Sun, 31 Jul 2016 22:21:36 +0200
Subject: Profiling a Truffle language
In-Reply-To: <em9a473e14-6f4a-4446-8c55-05c512b3751a@grashalm-work>
References: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>
	<85FEFCD5-7A22-47CE-AA72-747978CF1E31@stefan-marr.de>
	<CAFzGNhJPq8vzRE0byt1k73C3N0pfbEz1wFADhOR3r3Nrz7Duxg@mail.gmail.com>
	<em9a473e14-6f4a-4446-8c55-05c512b3751a@grashalm-work>
Message-ID: <CAFzGNhKgX6NMFMVt_wdVghuaZZ2jbJqNBq07jh9SEJ=BhpggzQ@mail.gmail.com>

Hi Christian,

On Sun, Jul 31, 2016 at 9:15 PM, Christian Humer <christian.humer at gmail.com>
wrote:

> On 31.07.2016 21:05:04, "Gerard Krol" <gerard at gerardkrol.nl> wrote:
>
> Thanks, that was very helpful. It was quite hard to get it working, but I
>> managed. For me it's still called TruffleProfiler (version 0.15 of
>> Truffle). Weirdly enough it was not picking up the class from the
>> truffle-debug jar through the @Registration annotation, so I had to copy
>> the class over (just adding a derived class with the annotation worked as
>> well).
>>
>> Sorry to hear that. Did you put the truffle-debug.jar on the normal or
> boot classpath? Could you maybe copy in your java command line that you
> were using, so I can potentially reproduce it?
>

I added it to truffle-debug to my pom.xml, and I'm currently using
the maven-shade-plugin to automatically include my dependencies into the
generated jar. That may be the wrong way to go about it, I'm not that
experienced with the classpath.


> Please also note that this version of the TruffleProfiler is based on
> instrumentation and is quite heavy. Therefore its results might not be very
> reliable.
> A more lightweight version based on sampling is coming soonish (1-3 weeks)
> to the Truffle tip.
>

That would be great, though I'm not looking forward to building Truffle
from source ;)

Regards,

Gerard

From christian.humer at gmail.com  Sun Jul 31 20:29:28 2016
From: christian.humer at gmail.com (Christian Humer)
Date: Sun, 31 Jul 2016 20:29:28 +0000
Subject: Profiling a Truffle language
In-Reply-To: <CAFzGNhKgX6NMFMVt_wdVghuaZZ2jbJqNBq07jh9SEJ=BhpggzQ@mail.gmail.com>
References: <CAFzGNhLSM_ONyo5P4fioR_uGAzVrx023mDnAEOJUBJ7kCGsVdQ@mail.gmail.com>
	<85FEFCD5-7A22-47CE-AA72-747978CF1E31@stefan-marr.de>
	<CAFzGNhJPq8vzRE0byt1k73C3N0pfbEz1wFADhOR3r3Nrz7Duxg@mail.gmail.com>
	<em9a473e14-6f4a-4446-8c55-05c512b3751a@grashalm-work>
	<CAFzGNhKgX6NMFMVt_wdVghuaZZ2jbJqNBq07jh9SEJ=BhpggzQ@mail.gmail.com>
Message-ID: <em681b58e5-96ce-4208-b4c7-d32e214ec8ad@grashalm-work>

Hi Gerard,


>I added it to truffle-debug to my pom.xml, and I'm currently using
>the maven-shade-plugin to automatically include my dependencies into 
>the
>generated jar. That may be the wrong way to go about it, I'm not that
>experienced with the classpath.
If you experienced the problem when using the maven-shade-plugin 
already, its very likely the cause of the problems.
When merging jar files, additional work needs to be done to make sure 
our service loader discovers the profiler on the classpath.


>
>That would be great, though I'm not looking forward to building Truffle
>from source ;)
Truffle is just Java sources, so building just Truffle is super-easy, no 
reason to be afraid ;-).
As usual we are going to release it as part of the next release, on 
maven central and OTN.
We release Truffle at least once every month.

Cheers,
Christian