From jbvernee at xs4all.nl  Mon Dec  3 12:26:06 2018
From: jbvernee at xs4all.nl (Jorn Vernee)
Date: Mon, 03 Dec 2018 13:26:06 +0100
Subject: Setting up for working on Graal sources in OpenJDK repo
Message-ID: <8da884e63e07f3d671add20f71a421bd@xs4all.nl>

Hi,

I was wondering what the right way is to generate intellij (or other 
IDE) configs for the Graal sources in OpenJDK?

Specifically I'm working on the module `jdk.internal.vm.compiler`. I've 
tried `bin/.idea.sh jdk.internal.vm.compiler` but this generates a 
project that has a bunch of missing dependencies (I've only worked with 
java.base before so I'm not sure how that is supposed to work tbh).

There's also an mx.graal suite in that module's directory, but when 
running `mx ideinit` this just creates a project for the actual suite 
files, and not for the Graal sources itself it seems.

What's the expected/recommended workflow for working on Graal sources in 
an OpenJDK repo?

Thanks,
Jorn Vernee

From doug.simon at oracle.com  Mon Dec  3 12:54:50 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 3 Dec 2018 13:54:50 +0100
Subject: Setting up for working on Graal sources in OpenJDK repo
In-Reply-To: <8da884e63e07f3d671add20f71a421bd@xs4all.nl>
References: <8da884e63e07f3d671add20f71a421bd@xs4all.nl>
Message-ID: <2A2108FF-62E2-4DE0-B294-AB0A50FD1CE9@oracle.com>

Hi Jorn,

> On 3 Dec 2018, at 13:26, Jorn Vernee <jbvernee at xs4all.nl> wrote:
> 
> Hi,
> 
> I was wondering what the right way is to generate intellij (or other IDE) configs for the Graal sources in OpenJDK?
> 
> Specifically I'm working on the module `jdk.internal.vm.compiler`. I've tried `bin/.idea.sh jdk.internal.vm.compiler` but this generates a project that has a bunch of missing dependencies (I've only worked with java.base before so I'm not sure how that is supposed to work tbh).
> 
> There's also an mx.graal suite in that module's directory, but when running `mx ideinit` this just creates a project for the actual suite files, and not for the Graal sources itself it seems.
> 
> What's the expected/recommended workflow for working on Graal sources in an OpenJDK repo?

I do not know about OpenJDK support for IDE development but it wouldn?t surprise me that doesn?t work with the Graal sources given their non-standard layout. I?ve cc?ed the hotspot compiler list in case someone there has some tips.

Not sure if it helps, but you can develop GitHub Graal sources against an OpenJDK build by setting JAVA_HOME to the latter and following the instructions at https://github.com/oracle/graal/tree/master/compiler#ide-configuration <https://github.com/oracle/graal/tree/master/compiler#ide-configuration>

-Doug

From jbvernee at xs4all.nl  Mon Dec  3 15:27:47 2018
From: jbvernee at xs4all.nl (Jorn Vernee)
Date: Mon, 03 Dec 2018 16:27:47 +0100
Subject: Setting up for working on Graal sources in OpenJDK repo
In-Reply-To: <2A2108FF-62E2-4DE0-B294-AB0A50FD1CE9@oracle.com>
References: <8da884e63e07f3d671add20f71a421bd@xs4all.nl>
 <2A2108FF-62E2-4DE0-B294-AB0A50FD1CE9@oracle.com>
Message-ID: <20388a55786e0e4875468413f991ed13@xs4all.nl>

Thanks Doug,

> Not sure if it helps, but you can develop GitHub Graal sources against
> an OpenJDK build by setting JAVA_HOME to the latter and following the
> instructions at
> https://github.com/oracle/graal/tree/master/compiler#ide-configuration

This isn't a complete picture for me, since (AFACT) it doesn't allow me 
to create a jdk image with both the Graal changes and the repo specific 
stuff. I need to use the OpenJDK build system since it adds a bunch of 
steps for the specific branch I'm working on.

Actually, it's good that you mention Github Graal; I looked and noticed 
the graal/compiler suite has a command called `updategraalinopenjdk` 
with the description: "updates the Graal sources in OpenJDK". The help 
message isn't very useful, but looking at the sources for it [1], it has 
a 'jdkrepo' argument. So I think I can dev on github Graal, and then use 
this command to push the updated sources into the OpenJDK repo I'm 
working on.

FWIW it did need patching to ignore `?` files from hg status (it's 
checking for uncommitted changes).

```
diff --git a/compiler/mx.compiler/mx_updategraalinopenjdk.py 
b/compiler/mx.compiler/mx_updategraalinopenjdk.py
index e58121c45f2..07281979270 100644
--- a/compiler/mx.compiler/mx_updategraalinopenjdk.py
+++ b/compiler/mx.compiler/mx_updategraalinopenjdk.py
@@ -126,7 +126,11 @@ def updategraalinopenjdk(args):
          m_src_dir = join('src', m.name)
          mx.log('Checking ' + m_src_dir)
          out = run_output(['hg', 'status', m_src_dir], cwd=jdkrepo)
-        if out:
+        status = []
+        for file in out.split('\n'):
+            if file and not file.startswith('?'):
+                status.append(file)
+        if status:
              mx.abort(jdkrepo + ' is not "hg clean":' + '\n' + 
out[:min(200, len(out))] + '...')

      for dirpath, _, filenames in os.walk(join(jdkrepo, 'make')):
```

The other problem is that my local copy of the Github Graal repo seems 
to be using CRLF line endings, so this is generating a lot of spurious 
diffs from the copy. I'm not sure what to do about that.

Jorn

[1] : 
https://github.com/oracle/graal/blob/master/compiler/mx.compiler/mx_updategraalinopenjdk.py#L67

Doug Simon schreef op 2018-12-03 13:54:
> Hi Jorn,
> 
>> On 3 Dec 2018, at 13:26, Jorn Vernee <jbvernee at xs4all.nl> wrote:
>> 
>> Hi,
>> 
>> I was wondering what the right way is to generate intellij (or other
>> IDE) configs for the Graal sources in OpenJDK?
>> 
>> Specifically I'm working on the module `jdk.internal.vm.compiler`.
>> I've tried `bin/.idea.sh jdk.internal.vm.compiler` but this
>> generates a project that has a bunch of missing dependencies (I've
>> only worked with java.base before so I'm not sure how that is
>> supposed to work tbh).
>> 
>> There's also an mx.graal suite in that module's directory, but when
>> running `mx ideinit` this just creates a project for the actual
>> suite files, and not for the Graal sources itself it seems.
>> 
>> What's the expected/recommended workflow for working on Graal
>> sources in an OpenJDK repo?
> 
> I do not know about OpenJDK support for IDE development but it
> wouldn?t surprise me that doesn?t work with the Graal sources
> given their non-standard layout. I?ve cc?ed the hotspot compiler
> list in case someone there has some tips.
> 
> Not sure if it helps, but you can develop GitHub Graal sources against
> an OpenJDK build by setting JAVA_HOME to the latter and following the
> instructions at
> https://github.com/oracle/graal/tree/master/compiler#ide-configuration
> 
> -Doug

From dean.long at oracle.com  Mon Dec  3 19:53:36 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Mon, 3 Dec 2018 11:53:36 -0800
Subject: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should
 not suspend the thread when the top frame executes JVMCI code
In-Reply-To: <CAF9BGByrQCH4hTF98T4DHgxSB8GMHTkP2SjFtFCUCo13j3OO5g@mail.gmail.com>
References: <4E0EFD3E-F725-4469-BA20-7532D78BA479@oracle.com>
 <CAF9BGByrQCH4hTF98T4DHgxSB8GMHTkP2SjFtFCUCo13j3OO5g@mail.gmail.com>
Message-ID: <a818647f-2a67-592b-21dd-b989a66c6a07@oracle.com>

On 11/30/18 7:46 PM, JC Beyler wrote:
> Questions because I'm not familiar with JVMCI consequences so not 
> really comments on the webrev but so that I know:
> ? - Is it normaly that you can suspend when you are in a JVMCI frame?

Yes, because it's just Java code, and we allow all Java code to be 
suspended, even Graal and JVMCI code.

> will/is there not a better way that we could detect that we are in a 
> JVMCI frame?

We could check the threads's _adjusting_comp_level flag for this 
particular case, if we decided that we don't want to be able to debug 
JVMCI Java code.

> Is it always safe to suspend a JVMCI frame?

That's a good question.? If it was grabbing any locks, then suspending 
it could cause problems for other threads calling into JVMCI.

Another solution would be to do adjusting_comp_level() in a separate 
thread.? So I think there are at least 3 possible solutions:

1) Allow JVMCI adjusting_comp_level call to be suspended/debugged
2) Don't allow it to be suspended/debugged,
 ??? a) by running in a separate thread, or
 ??? b) don't suspend when _adjusting_comp_level flag is set

We could introduce a concept of "system Java" code, which, just like 
Unix kernel code that is not debuggable without a kernel debugger, would 
not normally be debuggable without setting a special flag.

CCing graal-dev alias.

dl

From serguei.spitsyn at oracle.com  Tue Dec  4 06:32:03 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 3 Dec 2018 22:32:03 -0800
Subject: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should
 not suspend the thread when the top frame executes JVMCI code
In-Reply-To: <1a500fc6-9918-2b19-a0fe-bc299e58a015@oracle.com>
References: <4E0EFD3E-F725-4469-BA20-7532D78BA479@oracle.com>
 <CAF9BGByrQCH4hTF98T4DHgxSB8GMHTkP2SjFtFCUCo13j3OO5g@mail.gmail.com>
 <a818647f-2a67-592b-21dd-b989a66c6a07@oracle.com>
 <1a500fc6-9918-2b19-a0fe-bc299e58a015@oracle.com>
Message-ID: <d6111c65-6337-47bb-7b6e-bfc984287564@oracle.com>

Hi David and Dean,

One option is to add a command line option (disabled by default)
to enable debugging/profiling of the Graal compiler.
This will help to avoid all these Graal related issues,
simplify the development and stabilize the tests.
Not sure the Graal developer will like this proposal though. :)
Also, it is not very clear what level of complexity we add with this.
For instance, we will have to identify all spots where new checks have 
to be added.


Thanks,
Serguei


On 12/3/18 20:45, David Holmes wrote:
> On 4/12/2018 5:53 am, dean.long at oracle.com wrote:
>> On 11/30/18 7:46 PM, JC Beyler wrote:
>>> Questions because I'm not familiar with JVMCI consequences so not 
>>> really comments on the webrev but so that I know:
>>> ? - Is it normaly that you can suspend when you are in a JVMCI frame?
>>
>> Yes, because it's just Java code, and we allow all Java code to be 
>> suspended, even Graal and JVMCI code.
>
> A choice which can be argued for and against. On the one hand it is 
> nice to be able to try to debug JVMCI code, and on the other this 
> injects execution of Java code into places which to date could not 
> execute Java code and so can "shift" debugging actions from the 
> application/test code, to the JVMCI code. Arguably the 
> application/test code may need to have been more specific about its 
> intent (ie verifying that the debuggee is suspended in the expected 
> frame) and has just "been lucky" but nevertheless the use of JVMCI may 
> disrupt existing code using these facilities.
>
>>> will/is there not a better way that we could detect that we are in a 
>>> JVMCI frame?
>>
>> We could check the threads's _adjusting_comp_level flag for this 
>> particular case, if we decided that we don't want to be able to debug 
>> JVMCI Java code.
>>
>>> Is it always safe to suspend a JVMCI frame?
>>
>> That's a good question.? If it was grabbing any locks, then 
>> suspending it could cause problems for other threads calling into JVMCI.
>>
>> Another solution would be to do adjusting_comp_level() in a separate 
>> thread.? So I think there are at least 3 possible solutions:
>>
>> 1) Allow JVMCI adjusting_comp_level call to be suspended/debugged
>> 2) Don't allow it to be suspended/debugged,
>> ???? a) by running in a separate thread, or
>> ???? b) don't suspend when _adjusting_comp_level flag is set
>>
>> We could introduce a concept of "system Java" code, which, just like 
>> Unix kernel code that is not debuggable without a kernel debugger, 
>> would not normally be debuggable without setting a special flag.
>
> That may be something to consider in the future (albeit something that 
> should IMHO have been considered well in the past!) but I think it's 
> out of scope for this particular issue if we want to address this in 
> 12. There's certainly a need, again IMHO, for a broader discussion as 
> to how VM services written in Java should interact with other platform 
> services intended for use with application and library code. I don't 
> know if JVMCI/Graal explicitly hide themselves from agents and 
> retransformation/redefinition/ClassFileLoadHook, or even basic things 
> like event generation (where JVMCI may now generate many more events 
> than previously encountered).
>
>> CCing graal-dev alias.
>
> As a non-subscriber my reply will get held for moderation.
>
> Cheers,
> David
> -----
>
>> dl


From serguei.spitsyn at oracle.com  Tue Dec  4 07:45:31 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 3 Dec 2018 23:45:31 -0800
Subject: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should
 not suspend the thread when the top frame executes JVMCI code
In-Reply-To: <25e1102b-cce0-206d-b4bd-c11d72a6d4d9@oracle.com>
References: <4E0EFD3E-F725-4469-BA20-7532D78BA479@oracle.com>
 <CAF9BGByrQCH4hTF98T4DHgxSB8GMHTkP2SjFtFCUCo13j3OO5g@mail.gmail.com>
 <a818647f-2a67-592b-21dd-b989a66c6a07@oracle.com>
 <1a500fc6-9918-2b19-a0fe-bc299e58a015@oracle.com>
 <d6111c65-6337-47bb-7b6e-bfc984287564@oracle.com>
 <25e1102b-cce0-206d-b4bd-c11d72a6d4d9@oracle.com>
Message-ID: <4d7e4c67-6a88-f0c5-a3b7-51901826f7bd@oracle.com>

Agreed on both statements below.

Thanks,
Serguei


On 12/3/18 23:32, David Holmes wrote:
> On 4/12/2018 4:32 pm, serguei.spitsyn at oracle.com wrote:
>> Hi David and Dean,
>>
>> One option is to add a command line option (disabled by default)
>> to enable debugging/profiling of the Graal compiler.
>> This will help to avoid all these Graal related issues,
>> simplify the development and stabilize the tests.
>
> It would simply tests, which could just disable it. But things would 
> still need to work correctly if enabled - we can't have the current 
> problems of trying to do an early return, or popframe, from the wrong 
> frame.
>
>> Not sure the Graal developer will like this proposal though. :)
>> Also, it is not very clear what level of complexity we add with this.
>> For instance, we will have to identify all spots where new checks 
>> have to be added.
>
> Yes identifying exactly where you needed to check for this is 
> non-trivial I think.
>
> And this all needs a broader discussion before choosing this kind of 
> approach.
>
> Cheers,
> David
>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 12/3/18 20:45, David Holmes wrote:
>>> On 4/12/2018 5:53 am, dean.long at oracle.com wrote:
>>>> On 11/30/18 7:46 PM, JC Beyler wrote:
>>>>> Questions because I'm not familiar with JVMCI consequences so not 
>>>>> really comments on the webrev but so that I know:
>>>>> ? - Is it normaly that you can suspend when you are in a JVMCI frame?
>>>>
>>>> Yes, because it's just Java code, and we allow all Java code to be 
>>>> suspended, even Graal and JVMCI code.
>>>
>>> A choice which can be argued for and against. On the one hand it is 
>>> nice to be able to try to debug JVMCI code, and on the other this 
>>> injects execution of Java code into places which to date could not 
>>> execute Java code and so can "shift" debugging actions from the 
>>> application/test code, to the JVMCI code. Arguably the 
>>> application/test code may need to have been more specific about its 
>>> intent (ie verifying that the debuggee is suspended in the expected 
>>> frame) and has just "been lucky" but nevertheless the use of JVMCI 
>>> may disrupt existing code using these facilities.
>>>
>>>>> will/is there not a better way that we could detect that we are in 
>>>>> a JVMCI frame?
>>>>
>>>> We could check the threads's _adjusting_comp_level flag for this 
>>>> particular case, if we decided that we don't want to be able to 
>>>> debug JVMCI Java code.
>>>>
>>>>> Is it always safe to suspend a JVMCI frame?
>>>>
>>>> That's a good question.? If it was grabbing any locks, then 
>>>> suspending it could cause problems for other threads calling into 
>>>> JVMCI.
>>>>
>>>> Another solution would be to do adjusting_comp_level() in a 
>>>> separate thread.? So I think there are at least 3 possible solutions:
>>>>
>>>> 1) Allow JVMCI adjusting_comp_level call to be suspended/debugged
>>>> 2) Don't allow it to be suspended/debugged,
>>>> ???? a) by running in a separate thread, or
>>>> ???? b) don't suspend when _adjusting_comp_level flag is set
>>>>
>>>> We could introduce a concept of "system Java" code, which, just 
>>>> like Unix kernel code that is not debuggable without a kernel 
>>>> debugger, would not normally be debuggable without setting a 
>>>> special flag.
>>>
>>> That may be something to consider in the future (albeit something 
>>> that should IMHO have been considered well in the past!) but I think 
>>> it's out of scope for this particular issue if we want to address 
>>> this in 12. There's certainly a need, again IMHO, for a broader 
>>> discussion as to how VM services written in Java should interact 
>>> with other platform services intended for use with application and 
>>> library code. I don't know if JVMCI/Graal explicitly hide themselves 
>>> from agents and retransformation/redefinition/ClassFileLoadHook, or 
>>> even basic things like event generation (where JVMCI may now 
>>> generate many more events than previously encountered).
>>>
>>>> CCing graal-dev alias.
>>>
>>> As a non-subscriber my reply will get held for moderation.
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>> dl
>>


From dean.long at oracle.com  Fri Dec  7 19:47:06 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Fri, 7 Dec 2018 11:47:06 -0800
Subject: RFR(XXL) 8214023: Update Graal
Message-ID: <77f27da6-c106-cbe0-bf68-39f45b2a07fb@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8214023

Automatic merge:

 ? http://cr.openjdk.java.net/~dlong/8214023/webrev/

Manual patch:

 ? http://cr.openjdk.java.net/~dlong/8214023/patch/

See the JDK-8214023 link for the list of changes.

The webrev is unfortunately very large, because of this change:

 ??? [GR-12727] Fix duplicated copyright years in compiler and sdk suites.

It also corrected the copyright year for files where the year wasn't
updated after a change.

dl

From vladimir.kozlov at oracle.com  Fri Dec  7 20:20:30 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 7 Dec 2018 12:20:30 -0800
Subject: RFR(XXL) 8214023: Update Graal
In-Reply-To: <77f27da6-c106-cbe0-bf68-39f45b2a07fb@oracle.com>
References: <77f27da6-c106-cbe0-bf68-39f45b2a07fb@oracle.com>
Message-ID: <d05d53fb-4723-5d0e-7fb4-87dc5bd03b3d@oracle.com>

Looks good.

Stamped ;)

In additional to copyright year changes which affected AOT code too there was 2 other big 
refactoring as I see:

[GR-11619] Remove TraceRA.
moved test-only classes to test project

Thanks,
Vladimir

On 12/7/18 11:47 AM, dean.long at oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8214023
> 
> Automatic merge:
> 
>  ? http://cr.openjdk.java.net/~dlong/8214023/webrev/
> 
> Manual patch:
> 
>  ? http://cr.openjdk.java.net/~dlong/8214023/patch/
> 
> See the JDK-8214023 link for the list of changes.
> 
> The webrev is unfortunately very large, because of this change:
> 
>  ??? [GR-12727] Fix duplicated copyright years in compiler and sdk suites.
> 
> It also corrected the copyright year for files where the year wasn't
> updated after a change.
> 
> dl

From jean-philippe.halimi at intel.com  Fri Dec  7 22:25:58 2018
From: jean-philippe.halimi at intel.com (Halimi, Jean-Philippe)
Date: Fri, 7 Dec 2018 22:25:58 +0000
Subject: JVMCI and Tiered compilation
Message-ID: <E55B315EE3E2AA479F9915DAEECA24234522AC2C@ORSMSX116.amr.corp.intel.com>

Dear all,

I am currently looking into performance numbers with Graal as a JVMCI/JIT compiler. I see very high interpreter usage with Graal. I have experimented enabling and disabling the tiered compilation knob to see the impact on performance.

However, I am a bit confused on how JVMCI compilers is supposed to be used in the tiered compilation policy, since we technically have only one compiler to use. Typically, Hotspot methods have 5 levels in its tiered mode:

 *   0 - interpreter (CompLevel_none)
  *   1 - pure C1 (CompLevel_simple)
  *   2 - C1 with invocation and backedge counting (CompLevel_limited_profile)
  *   3 - C1 with full profiling (CompLevel_full_profile)
  *   4 - C2 (CompLevel_full_optimization)

When using JVMCI, are we compiling from state 1 to 4 with the JVMCI compiler?

Thanks
-Jp

From vladimir.kozlov at oracle.com  Fri Dec  7 22:37:54 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 7 Dec 2018 14:37:54 -0800
Subject: JVMCI and Tiered compilation
In-Reply-To: <E55B315EE3E2AA479F9915DAEECA24234522AC2C@ORSMSX116.amr.corp.intel.com>
References: <E55B315EE3E2AA479F9915DAEECA24234522AC2C@ORSMSX116.amr.corp.intel.com>
Message-ID: <27b4195c-2c6d-9ac8-9027-f3e6f9f14815@oracle.com>

Hi Jp,

Graal is only replacing C2 at tier4. C1 is still present.

You need to use Tiered compilation with Graal so that C1 will compile Graal code (which is Java code 
and executed in Intepreter if it is not JIT compiled) otherwise Graal have to compile itself which 
is very slow.

It is known issue and we together with Oracle Labs are working on libgraal project to precompile 
Graal into native code as separate shared library loaded by Hotspot.

Regards,
Vladimir

On 12/7/18 2:25 PM, Halimi, Jean-Philippe wrote:
> Dear all,
> 
> I am currently looking into performance numbers with Graal as a JVMCI/JIT compiler. I see very high interpreter usage with Graal. I have experimented enabling and disabling the tiered compilation knob to see the impact on performance.
> 
> However, I am a bit confused on how JVMCI compilers is supposed to be used in the tiered compilation policy, since we technically have only one compiler to use. Typically, Hotspot methods have 5 levels in its tiered mode:
> 
>   *   0 - interpreter (CompLevel_none)
>    *   1 - pure C1 (CompLevel_simple)
>    *   2 - C1 with invocation and backedge counting (CompLevel_limited_profile)
>    *   3 - C1 with full profiling (CompLevel_full_profile)
>    *   4 - C2 (CompLevel_full_optimization)
> 
> When using JVMCI, are we compiling from state 1 to 4 with the JVMCI compiler?
> 
> Thanks
> -Jp
> 

From usrinivasan at twitter.com  Sat Dec  8 00:51:59 2018
From: usrinivasan at twitter.com (Uma Srinivasan)
Date: Fri, 7 Dec 2018 16:51:59 -0800
Subject: Soliciting submissions for Graal workshop at CGO 2019
In-Reply-To: <CAN5XQfvejwqC1ed2dPA406Z8vwzUW1DWx_GJzemVLrL94pieFA@mail.gmail.com>
References: <CAN5XQfvejwqC1ed2dPA406Z8vwzUW1DWx_GJzemVLrL94pieFA@mail.gmail.com>
Message-ID: <CAN5XQfug0v=mBY8MaC2y+zS-taT8RnGCWgcSDfEGhnPB-eKJ7Q@mail.gmail.com>

Gentle reminder, submissions deadline is next week (Dec. 15th), but no
worries!

The format for submissions is somewhat semi-formal i.e. a 2/3 page extended
abstract or a few slides to describe the proposal for the presentation.

If you are working on a submission and would like to get an extension,
please do make a request.

Regards,
Uma
https://easychair.org/cfp/graalcgo2019

On Wed, Nov 28, 2018 at 5:20 PM Uma Srinivasan <usrinivasan at twitter.com>
wrote:

>
> Hello All,
>
> Along with announcing the first Graal workshop to be held at CGO 2019, we
> are soliciting proposals for presentations from this community. Details
> of the submission process are provided here:
> https://easychair.org/cfp/graalcgo2019
>
> Please let me know if you have any questions.
>
> Regards,
> Uma Srinivasan
>
> JVM Engineer @ Twitter
>

From dean.long at oracle.com  Sat Dec  8 09:06:14 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Sat, 8 Dec 2018 01:06:14 -0800
Subject: RFR(XXL) 8214023: Update Graal
In-Reply-To: <d05d53fb-4723-5d0e-7fb4-87dc5bd03b3d@oracle.com>
References: <77f27da6-c106-cbe0-bf68-39f45b2a07fb@oracle.com>
 <d05d53fb-4723-5d0e-7fb4-87dc5bd03b3d@oracle.com>
Message-ID: <40faca71-82ec-64c0-6c5b-ed088101f2f0@oracle.com>

Thanks Vladimir.

dl

On 12/7/18 12:20 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Stamped ;)
>
> In additional to copyright year changes which affected AOT code too 
> there was 2 other big refactoring as I see:
>
> [GR-11619] Remove TraceRA.
> moved test-only classes to test project
>
> Thanks,
> Vladimir
>
> On 12/7/18 11:47 AM, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8214023
>>
>> Automatic merge:
>>
>> ?? http://cr.openjdk.java.net/~dlong/8214023/webrev/
>>
>> Manual patch:
>>
>> ?? http://cr.openjdk.java.net/~dlong/8214023/patch/
>>
>> See the JDK-8214023 link for the list of changes.
>>
>> The webrev is unfortunately very large, because of this change:
>>
>> ???? [GR-12727] Fix duplicated copyright years in compiler and sdk 
>> suites.
>>
>> It also corrected the copyright year for files where the year wasn't
>> updated after a change.
>>
>> dl


From edd at theunixzoo.co.uk  Wed Dec 12 10:13:08 2018
From: edd at theunixzoo.co.uk (Edd Barrett)
Date: Wed, 12 Dec 2018 10:13:08 +0000
Subject: Call for Abstracts: Modern Language Runtimes, Ecosystems, and VMs
 (MoreVMs) 2019
Message-ID: <20181212101308.GC72382@arrakis.home>

============================================================================
                  Call for Extended Abstracts: MoreVMs'19

                              3rd Workshop on
                  Modern Language Runtimes, and Ecosystems

                      Co-located with <Programming>'19
                    April 1st or 2nd, 2019, Genova, Italy

        https://2019.programming-conference.org/track/MoreVMs-2019
============================================================================

Following two previous successful editions, the MoreVMs'19 workshop aims to
bring together industrial and academic programmers to discuss the design,
implementation, and usage of modern languages and runtimes. This includes
aspects such as reuse of language runtimes, modular implementation, language
design and compilation strategies. By bringing together both researchers and
practitioners, the workshop aims to enable a diverse discussion on how
languages and runtimes are currently being utilized, and where they need to
improve further.

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

 - Extensible VM design (compiler- or interpreter-based VMs)
 - Reusable components (e.g. interpreters, garbage collectors, ...)
 - Static and dynamic compilation techniques
 - Techniques for targeting high-level languages such as JavaScript
 - Interoperability between languages
 - Tooling support (e.g. debugging, profiling, etc.)
 - Programming language development environments
 - Case studies of existing language implementation approaches
 - Language implementation challenges and trade-offs
 - Surveys and usage reports to understand usage in the wild
 - Ideas for more predictable performance
 - Ideas for how VMs could take advantage of new hardware features
 - Ideas for how we should build languages in the future

Workshop Format and Submissions
-------------------------------

We welcome presentation proposals in the form of extended abstracts (1 to 2
pages long) discussing experiences, work-in-progress, as well as future
visions, from either an academic or industrial perspective.

The extended abstracts, and if the speakers wish, their slides, will be
published on the workshop's web site. Alternatively, the abstracts can be
published as part of the companion of <Programming>'19 in the ACM DL.
Publication in the ACM DL is conditional on the acceptance by the program
committee.

Please note that MoreVMs'19 is organized as an academic workshop, and as such,
speakers will be required to register for the workshop.

Author Instructions
-------------------

Submissions should use the ACM Conference 'acmart' Format with the 'sigconf'
option and with a font size of 9 point and the font family Libertine/Biolinum.
All submissions should be in PDF format. If you use LaTeX or Word, please use
the provided ACM acmart templates. Otherwise, please follow the ACM author
instructions.

If you are formatting your paper using Word, you may wish to use the provided
Word template that supports this font size. Please include page numbers in your
submission for review using the LaTeX command '\settopmatter{printfolios=true}'
(see examples in template).

Please also ensure that your submission is legible when printed on a black and
white printer. In particular, please check that colors remain distinct and font
sizes are legible.

Submission Site: https://easychair.org/conferences/?conf=morevms19

Important Dates
---------------

Extended abstract submissions:  2019-01-11
Author notification:            2019-02-10
Camera Ready:                   2019-02-22
Workshop:                       2019-04-01 or 2019-04-02

All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour.

Program Committee
-----------------

Nicolas B. Pierron, Mozilla, France
Walter Binder, University of Lugano, Switzerland
Eduard-Mihai Burtescu, Lyken Software Solutions
Vyacheslav Egorov, Google, Denmark
Tony Hosking, Australian National University / Data61, Australia
Christoph Kirsch, University of Salzburg, Austria
Lun Liu, University of California at Los Angeles, USA
Fabio Niephaus, Hasso Plattner Institute, Germany
Lu?s Pina, George Mason University, USA
Manuel Rigger, Johannes Kepler University Linz, Austria
Jennifer B. Sartor, Ghent University, Belgium
Andy Wingo, Igalia, S.L., France

Organizers
----------

Edd Barrett, King's College London, UK
Stefan Marr, University of Kent, UK
Adam Welc, Uber Technologies, USA

From usrinivasan at twitter.com  Fri Dec 14 17:57:02 2018
From: usrinivasan at twitter.com (Uma Srinivasan)
Date: Fri, 14 Dec 2018 09:57:02 -0800
Subject: Last call for submissions: Graal workshop at CGO 2019
In-Reply-To: <CAN5XQfug0v=mBY8MaC2y+zS-taT8RnGCWgcSDfEGhnPB-eKJ7Q@mail.gmail.com>
References: <CAN5XQfvejwqC1ed2dPA406Z8vwzUW1DWx_GJzemVLrL94pieFA@mail.gmail.com>
 <CAN5XQfug0v=mBY8MaC2y+zS-taT8RnGCWgcSDfEGhnPB-eKJ7Q@mail.gmail.com>
Message-ID: <CAN5XQfuP6C_Rt+JBozRs3PXfabQWyUZMO4JmLiDLCqv1Ehinhw@mail.gmail.com>

Reminder: presentation proposals submissions deadline is this weekend.

https://easychair.org/cfp/graalcgo2019

On Fri, Dec 7, 2018 at 4:51 PM Uma Srinivasan <usrinivasan at twitter.com>
wrote:

> Gentle reminder, submissions deadline is next week (Dec. 15th), but no
> worries!
>
> The format for submissions is somewhat semi-formal i.e. a 2/3 page
> extended abstract or a few slides to describe the proposal for the
> presentation.
>
> If you are working on a submission and would like to get an extension,
> please do make a request.
>
> Regards,
> Uma
> https://easychair.org/cfp/graalcgo2019
>
> On Wed, Nov 28, 2018 at 5:20 PM Uma Srinivasan <usrinivasan at twitter.com>
> wrote:
>
>>
>> Hello All,
>>
>> Along with announcing the first Graal workshop to be held at CGO 2019,
>> we are soliciting proposals for presentations from this community.
>> Details of the submission process are provided here:
>> https://easychair.org/cfp/graalcgo2019
>>
>> Please let me know if you have any questions.
>>
>> Regards,
>> Uma Srinivasan
>>
>> JVM Engineer @ Twitter
>>
>

From marc at petit-huguenin.org  Mon Dec 17 16:17:34 2018
From: marc at petit-huguenin.org (Marc Petit-Huguenin)
Date: Mon, 17 Dec 2018 08:17:34 -0800
Subject: Instruments
Message-ID: <058bd7e8-3593-fb09-a3c4-161c8d50b265@petit-huguenin.org>

Hi,

I am trying to implement a simple Instrument.  That instrument contains an abstract class as a service that I want to use in my language launcher by using engine.getInstruments().get("myinstrument").lookup(MyClass.class), and in my language implementation using env.lookup(env.getInstruments().get("myinstrument"), MyClass.class).

The path for the instrument implementation is added to the truffle.class.path.append property, as is the path for the language implementation, and I can retrieve a MyClass instance in the language implementation.  But I cannot retrieve an instance in the launcher (i.e. it returns null), probably because of a different class loader.  I tried with -XX:-UseJVMCIClassLoader, that did not help.

What am I doing wrong?

Thanks.

-- 
Marc Petit-Huguenin
Email: marc at petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug


From Martin.Entlicher at oracle.com  Mon Dec 17 16:52:00 2018
From: Martin.Entlicher at oracle.com (Martin Entlicher)
Date: Mon, 17 Dec 2018 17:52:00 +0100
Subject: Instruments
In-Reply-To: <058bd7e8-3593-fb09-a3c4-161c8d50b265@petit-huguenin.org>
References: <058bd7e8-3593-fb09-a3c4-161c8d50b265@petit-huguenin.org>
Message-ID: <d1bd65b6-2bbc-5c88-e85d-9fc940d43c9c@oracle.com>

Hi Marc,

the language and instrument implementation should be on the 
truffle.class.path.append, but the "MyClass", which needs to be 
accessible from the launcher, needs to be on an ordinary class path, I 
believe.

Martin


On 17. 12. 18 17:17, Marc Petit-Huguenin wrote:
> Hi,
>
> I am trying to implement a simple Instrument.  That instrument contains an abstract class as a service that I want to use in my language launcher by using engine.getInstruments().get("myinstrument").lookup(MyClass.class), and in my language implementation using env.lookup(env.getInstruments().get("myinstrument"), MyClass.class).
>
> The path for the instrument implementation is added to the truffle.class.path.append property, as is the path for the language implementation, and I can retrieve a MyClass instance in the language implementation.  But I cannot retrieve an instance in the launcher (i.e. it returns null), probably because of a different class loader.  I tried with -XX:-UseJVMCIClassLoader, that did not help.
>
> What am I doing wrong?
>
> Thanks.
>


From christian.humer at gmail.com  Thu Dec 20 18:47:31 2018
From: christian.humer at gmail.com (Christian Humer)
Date: Thu, 20 Dec 2018 19:47:31 +0100
Subject: Instruments
In-Reply-To: <058bd7e8-3593-fb09-a3c4-161c8d50b265@petit-huguenin.org>
References: <058bd7e8-3593-fb09-a3c4-161c8d50b265@petit-huguenin.org>
Message-ID: <CAK_HDSe2TOsriun1KWFGMNbBzGb5H7q1PAWc3-=xtr9CAoE6cQ@mail.gmail.com>

Hi Marc,

Did you declare the service class in the @Registration annotation of the
instrument? That is necessary to allow the lookup.

- Christian Humer

Marc Petit-Huguenin <marc at petit-huguenin.org> schrieb am Mo., 17. Dez.
2018, 17:48:

> Hi,
>
> I am trying to implement a simple Instrument.  That instrument contains an
> abstract class as a service that I want to use in my language launcher by
> using engine.getInstruments().get("myinstrument").lookup(MyClass.class),
> and in my language implementation using
> env.lookup(env.getInstruments().get("myinstrument"), MyClass.class).
>
> The path for the instrument implementation is added to the
> truffle.class.path.append property, as is the path for the language
> implementation, and I can retrieve a MyClass instance in the language
> implementation.  But I cannot retrieve an instance in the launcher (i.e. it
> returns null), probably because of a different class loader.  I tried with
> -XX:-UseJVMCIClassLoader, that did not help.
>
> What am I doing wrong?
>
> Thanks.
>
> --
> Marc Petit-Huguenin
> Email: marc at petit-huguenin.org
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>
>

From marc at petit-huguenin.org  Thu Dec 20 21:11:34 2018
From: marc at petit-huguenin.org (Marc Petit-Huguenin)
Date: Thu, 20 Dec 2018 13:11:34 -0800
Subject: Instruments
In-Reply-To: <CAK_HDSe2TOsriun1KWFGMNbBzGb5H7q1PAWc3-=xtr9CAoE6cQ@mail.gmail.com>
References: <058bd7e8-3593-fb09-a3c4-161c8d50b265@petit-huguenin.org>
 <CAK_HDSe2TOsriun1KWFGMNbBzGb5H7q1PAWc3-=xtr9CAoE6cQ@mail.gmail.com>
Message-ID: <e28ac99b-65e5-2bdb-e5fd-038305930c43@petit-huguenin.org>

Hi Christian,

I did that.  Note that Martin Entlicher already sent my a couple of solutions that work fine.

Thanks.

On 12/20/18 10:47 AM, Christian Humer wrote:
> Hi Marc,
> 
> Did you declare the service class in the @Registration annotation of the
> instrument? That is necessary to allow the lookup.
> 
> - Christian Humer
> 
> Marc Petit-Huguenin <marc at petit-huguenin.org> schrieb am Mo., 17. Dez.
> 2018, 17:48:
> 
>> Hi,
>>
>> I am trying to implement a simple Instrument.  That instrument contains an
>> abstract class as a service that I want to use in my language launcher by
>> using engine.getInstruments().get("myinstrument").lookup(MyClass.class),
>> and in my language implementation using
>> env.lookup(env.getInstruments().get("myinstrument"), MyClass.class).
>>
>> The path for the instrument implementation is added to the
>> truffle.class.path.append property, as is the path for the language
>> implementation, and I can retrieve a MyClass instance in the language
>> implementation.  But I cannot retrieve an instance in the launcher (i.e. it
>> returns null), probably because of a different class loader.  I tried with
>> -XX:-UseJVMCIClassLoader, that did not help.
>>
>> What am I doing wrong?
>>
>> Thanks.
>>
>> --
>> Marc Petit-Huguenin
>> Email: marc at petit-huguenin.org
>> Blog: https://marc.petit-huguenin.org
>> Profile: https://www.linkedin.com/in/petithug
>>
>>
> 


-- 
Marc Petit-Huguenin
Email: marc at petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug