From tom.rodriguez at oracle.com  Tue Jun  4 19:18:03 2019
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Tue, 4 Jun 2019 12:18:03 -0700
Subject: Graal generated assembly much larger than C2
In-Reply-To: <997558440.1058157.1558986359910@email.ionos.com>
References: <1164656357.1022332.1558909283616@email.ionos.com>
 <866599BC-D573-4624-8943-89B81FDD0FB9@oracle.com>
 <997558440.1058157.1558986359910@email.ionos.com>
Message-ID: <20b56c6f-0925-c812-ac39-6dd957c3b7dd@oracle.com>

I think what you're seeing is the variable cost of the G1 barrier, 
triggered by the fact that the Graal compiler runs in the same Java heap 
as your test case.  The G1 post barrier has a couple tests that allow it 
to skip the barrier, namely if both objects are in the same region or if 
the object being stored into is in the new generation.  These are very 
cheap tests.  However if those fail then it will issue a STORE_LOAD 
memory barrier and check whether the card is dirty.  This is much slower 
and seems to be what occurs here with Graal.  This is likely because the 
benchmark state is allocated once and no allocation is performed after 
that by the benchmark.  Graal performs a lot of compilation and probably 
pushes that object out of the new gen.

If you run with -XX:+UseParallelGC you'll see that Graal and C2 are 
largely the same since the standard card mark is constant cost.  You 
should watch out for the GC selection since if you compare 8 and 9+ 
you're also comparing different barriers.  Using libgraal will also make 
Graal behave more like C2 since it's no longer using the Java heap but 
we don't have an officially supported build of libgraal for jdk13 yet.

You could probably mitigate this by using the Setup and Level 
annotations to recreate the benchmark state on each iteration.  Anyway 
doing micro level measurements of Object stores with G1 is going to be 
very sensitive to actual object placement.

tom

Carl M wrote on 5/27/19 12:45 PM:
> Hi Thomas,
> 
> I retried using 13-ea+22 (previously 11.0.2)   and found that while the generated code is smaller, a lot of the Flags I passed don't seem to work anymore.  The bytecode is not interleaved in the generated assembly any more (I don't know which flag sets this) and the -XX:PrintAssemblyOptions=intel flag no longer seems to work.  I also tried this on a non-Graal benchmark run, and it had the same problem.  Perhaps something wrong in 13?
> 
> The code that was produced was a little smaller (364 -> 346 bytes).  The generated (un-annotated assembly) is here:
> https://gist.github.com/carl-mastrangelo/7f1def204ae5d6e76268cc42b8c1af45
> 
> I haven't tried limiting the benchmark to just setOpaque, since I can't see the bytecode interleaved (to confirm it's doing what I think it is).
> 
> 
>> On May 27, 2019 at 9:09 AM Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
>>
>>
>> Hi Carl,
>>
>> Can you further reduce this test case to one VarHandle#setOpaque call?
>>
>> It is likely that there is a wrong intrinsification of either VarHandle#setOpaque, VarHandle#setRelease, or VarHandle#storeStoreFence. Not much to do for the compiler overall here as the code only consists of special case intrinsics.
>>
>> Also, does this also run on the latest JDK13 EA? The version of the compiler in JDK11 is not the latest one.
>>
>>
>> * thomas
>>
>>
>>> On 27 May 2019, at 00:21, Carl M <java at rkive.org> wrote:
>>>
>>> Hi,
>>>
>>> I am new to trying out Graal, and found that it was much slower for
>>> a trivial benchmark I wrote. I was surprised that it was about 40%
>>> slower, so I dumped the assembly and found it was much larger for
>>> the Graal version. I collected a dump of the assembly, but I am not
>>> much of a compiler person so I don't know what to do with it.
>>>
>>> Is this the right list to see if there is something wrong?
>>>
>>>
>>> Assembly of each compiler (and JVM flags):
>>> https://gist.github.com/carl-mastrangelo/5fe2f1f744c05ca20242cad9b5f7fb26
>>>
>>>
>>> Source code inner loop:
>>> https://github.com/carl-mastrangelo/perfmark/blob/b266d9494054b5a2d09bc62f7b234d693e2d5173/java9/src/main/java/io/perfmark/java9/VarHandleMarkHolder.java#L129

From dean.long at oracle.com  Fri Jun  7 02:33:15 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Thu, 6 Jun 2019 19:33:15 -0700
Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use
 Dependencies::find_unique_concrete_method() for non-virtual methods
Message-ID: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8223050
http://cr.openjdk.java.net/~dlong/8223050/webrev/

Avoid generating unnecessary dependencies for methods that can be 
statically bound.? While working on this I discovered that Graal's 
HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match that 
of the VM, because it was missing a check for <init>.

dl

From vladimir.kozlov at oracle.com  Fri Jun  7 02:41:28 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 6 Jun 2019 19:41:28 -0700
Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use
 Dependencies::find_unique_concrete_method() for non-virtual methods
In-Reply-To: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
References: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
Message-ID: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com>

Seems reasonable to me but Graal experts should review it.

Thanks,
Vladimir

PS: please, run more graal tiers - I added comment in bug report.

On 6/6/19 7:33 PM, dean.long at oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8223050
> http://cr.openjdk.java.net/~dlong/8223050/webrev/
> 
> Avoid generating unnecessary dependencies for methods that can be statically bound.? While working on this I discovered 
> that Graal's HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match that of the VM, because it was missing a 
> check for <init>.
> 
> dl

From dean.long at oracle.com  Fri Jun  7 03:05:34 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Thu, 6 Jun 2019 20:05:34 -0700
Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use
 Dependencies::find_unique_concrete_method() for non-virtual methods
In-Reply-To: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com>
References: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
 <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com>
Message-ID: <3e57b88d-a72c-8e86-62af-0b03dab4bd55@oracle.com>

Thanks Vladimir.

dl

On 6/6/19 7:41 PM, Vladimir Kozlov wrote:
> Seems reasonable to me but Graal experts should review it.
>
> Thanks,
> Vladimir
>
> PS: please, run more graal tiers - I added comment in bug report.
>
> On 6/6/19 7:33 PM, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8223050
>> http://cr.openjdk.java.net/~dlong/8223050/webrev/
>>
>> Avoid generating unnecessary dependencies for methods that can be 
>> statically bound.? While working on this I discovered that Graal's 
>> HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match 
>> that of the VM, because it was missing a check for <init>.
>>
>> dl


From doug.simon at oracle.com  Fri Jun  7 08:13:56 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Fri, 7 Jun 2019 10:13:56 +0200
Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use
 Dependencies::find_unique_concrete_method() for non-virtual methods
In-Reply-To: <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com>
References: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
 <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com>
Message-ID: <ABD67EC6-95BC-4004-97CC-5FF80A80C9CB@oracle.com>

Change looks good to me.

-Doug

> On 7 Jun 2019, at 04:41, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Seems reasonable to me but Graal experts should review it.
> 
> Thanks,
> Vladimir
> 
> PS: please, run more graal tiers - I added comment in bug report.
> 
> On 6/6/19 7:33 PM, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8223050
>> http://cr.openjdk.java.net/~dlong/8223050/webrev/
>> Avoid generating unnecessary dependencies for methods that can be statically bound.  While working on this I discovered that Graal's HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match that of the VM, because it was missing a check for <init>.
>> dl


From dean.long at oracle.com  Fri Jun  7 22:12:00 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Fri, 7 Jun 2019 15:12:00 -0700
Subject: RFR(S) 8223050: JVMCI: findUniqueConcreteMethod() should not use
 Dependencies::find_unique_concrete_method() for non-virtual methods
In-Reply-To: <ABD67EC6-95BC-4004-97CC-5FF80A80C9CB@oracle.com>
References: <d48c1317-6807-8ed8-8c48-31ddd8fded32@oracle.com>
 <82a8e180-3b7f-de1a-aa64-4aba2ab7dcaa@oracle.com>
 <ABD67EC6-95BC-4004-97CC-5FF80A80C9CB@oracle.com>
Message-ID: <4b6031ea-82fc-b3f9-be93-afea5d743c4b@oracle.com>

Thanks Doug!

dl

On 6/7/19 1:13 AM, Doug Simon wrote:
> Change looks good to me.
>
> -Doug
>
>> On 7 Jun 2019, at 04:41, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> Seems reasonable to me but Graal experts should review it.
>>
>> Thanks,
>> Vladimir
>>
>> PS: please, run more graal tiers - I added comment in bug report.
>>
>> On 6/6/19 7:33 PM, dean.long at oracle.com wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8223050
>>> http://cr.openjdk.java.net/~dlong/8223050/webrev/
>>> Avoid generating unnecessary dependencies for methods that can be statically bound.  While working on this I discovered that Graal's HotSpotResolvedJavaMethodImpl.canBeStaticallyBound() doesn't match that of the VM, because it was missing a check for <init>.
>>> dl


From jesper.wilhelmsson at oracle.com  Sat Jun  8 00:58:17 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Sat, 8 Jun 2019 02:58:17 +0200
Subject: RFR: JDK-8223807 - Update Graal
Message-ID: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com>

Hi,

Please review the patch to integrate recent Graal changes into OpenJDK.
Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433

JBS duplicates fixed by this integration:
https://bugs.openjdk.java.net/browse/JDK-8223924

Bug: https://bugs.openjdk.java.net/browse/JDK-8223807
Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/

This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.

Thanks,
/Jesper


From vladimir.kozlov at oracle.com  Mon Jun 10 15:49:50 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 10 Jun 2019 08:49:50 -0700
Subject: RFR: JDK-8223807 - Update Graal
In-Reply-To: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com>
References: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com>
Message-ID: <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com>

There are a lot of crashes in compiler/aot and gc/stress/gcbasher tests. We need to resolve them.

It seems you don't need to apply `overwritten` changes - Update changes has them.

Thanks,
Vladimir

On 6/7/19 5:58 PM, jesper.wilhelmsson at oracle.com wrote:
> Hi,
> 
> Please review the patch to integrate recent Graal changes into OpenJDK.
> Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433
> 
> JBS duplicates fixed by this integration:
> https://bugs.openjdk.java.net/browse/JDK-8223924
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223807
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/
> 
> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
> 
> Thanks,
> /Jesper
> 

From vladimir.kozlov at oracle.com  Mon Jun 10 16:05:29 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 10 Jun 2019 09:05:29 -0700
Subject: RFR: JDK-8223807 - Update Graal
In-Reply-To: <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com>
References: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com>
 <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com>
Message-ID: <67f36d91-1936-2937-756f-ae75f8bf03ae@oracle.com>

These changes incorrectly reversed part of 8209626 changes in jaotc/MetadataBuilder.java file causing these AOT failures.

Vladimir

On 6/10/19 8:49 AM, Vladimir Kozlov wrote:
> There are a lot of crashes in compiler/aot and gc/stress/gcbasher tests. We need to resolve them.
> 
> It seems you don't need to apply `overwritten` changes - Update changes has them.
> 
> Thanks,
> Vladimir
> 
> On 6/7/19 5:58 PM, jesper.wilhelmsson at oracle.com wrote:
>> Hi,
>>
>> Please review the patch to integrate recent Graal changes into OpenJDK.
>> Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433
>>
>> JBS duplicates fixed by this integration:
>> https://bugs.openjdk.java.net/browse/JDK-8223924
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223807
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/
>>
>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
>>
>> Thanks,
>> /Jesper
>>

From jesper.wilhelmsson at oracle.com  Tue Jun 11 02:45:14 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 11 Jun 2019 04:45:14 +0200
Subject: RFR: JDK-8223807 - Update Graal
In-Reply-To: <67f36d91-1936-2937-756f-ae75f8bf03ae@oracle.com>
References: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com>
 <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com>
 <67f36d91-1936-2937-756f-ae75f8bf03ae@oracle.com>
Message-ID: <10CB23D8-7D4F-40C5-AD54-B2E8E3E71C52@oracle.com>

Hi,

I re-applied the patch for JDK-8209626 and restarted the testing.
/Jesper

> On 10 Jun 2019, at 18:05, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> These changes incorrectly reversed part of 8209626 changes in jaotc/MetadataBuilder.java file causing these AOT failures.
> 
> Vladimir
> 
> On 6/10/19 8:49 AM, Vladimir Kozlov wrote:
>> There are a lot of crashes in compiler/aot and gc/stress/gcbasher tests. We need to resolve them.
>> It seems you don't need to apply `overwritten` changes - Update changes has them.
>> Thanks,
>> Vladimir
>> On 6/7/19 5:58 PM, jesper.wilhelmsson at oracle.com wrote:
>>> Hi,
>>> 
>>> Please review the patch to integrate recent Graal changes into OpenJDK.
>>> Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433
>>> 
>>> JBS duplicates fixed by this integration:
>>> https://bugs.openjdk.java.net/browse/JDK-8223924
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223807
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/
>>> 
>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
>>> 
>>> Thanks,
>>> /Jesper
>>> 


From coppa at di.uniroma1.it  Sat Jun 15 16:55:59 2019
From: coppa at di.uniroma1.it (Emilio Coppa)
Date: Sat, 15 Jun 2019 18:55:59 +0200
Subject: MPLR 2019 - Second Call for Papers
Message-ID: <CAAqUNscvazM49h7dK6yuwVFjVqihyvPKHmVkJN21aoOCCFU1bQ@mail.gmail.com>

(Apologies if you receive multiple copies of this CFP)

=============================================
                                  MPLR 2019

 16th International Conference on Managed Programming
                        Languages & Runtimes

                    Co-located with SPLASH 2019
                  Athens, Greece, Oct 20-25, 2019

             https://conf.researchr.org/home/mplr-2019
=============================================

The 16th International Conference on Managed Programming Languages &
Runtimes (MPLR, formerly ManLang) is a premier forum for presenting
and discussing novel results in all aspects of managed programming
languages and runtime systems, which serve as building blocks for some
of the most important computing systems around, ranging from
small-scale (embedded and real-time systems) to large-scale
(cloud-computing and big-data platforms) and anything in between
(mobile, IoT, and wearable applications).

This year, MPLR is co-located with SPLASH 2019 and sponsored by ACM.
For more information, check out the conference website:
https://conf.researchr.org/home/mplr-2019

# Topics

Topics of interest include but are not limited to:
 * Languages and Compilers
    - Managed languages (e.g., Java, Scala, JavaScript, Python, Ruby,
C#, F#, Clojure, Groovy, Kotlin, R, Smalltalk, Racket, Rust, Go, etc.)
    - Domain-specific languages
    - Language design
    - Compilers and interpreters
    - Type systems and program logics
    - Language interoperability
    - Parallelism, distribution, and concurrency
 * Virtual Machines
    - Managed runtime systems (e.g., JVM, Dalvik VM, Android Runtime
(ART), LLVM, .NET CLR, RPython, etc.)
    - VM design and optimization
    - VMs for mobile and embedded devices
    - VMs for real-time applications
    - Memory management
    - Hardware/software co-design
 * Techniques, Tools, and Applications
    - Static and dynamic program analysis
    - Testing and debugging
    - Refactoring
    - Program understanding
    - Program synthesis
    - Security and privacy
    - Performance analysis and monitoring
    - Compiler and program verification

# Submission Categories

MPLR accepts four types of submissions:

 1. Regular research papers, which describe novel contributions
involving managed language platforms (up to 12 pages excluding
bibliography and appendix). Research papers will be evaluated based on
their relevance, novelty, technical rigor, and contribution to the
state-of-the-art.

 2. Work-in-progress research papers, which describe promising new
ideas but yet have less maturity than full papers (up to 6 pages
excluding bibliography and appendix). When evaluating work-in-progress
papers, more emphasis will be placed on novelty and the potential of
the new ideas than on technical rigor and experimental results.

 3. Industry and tool papers, which present technical challenges and
solutions for managed language platforms in the context of deployed
applications and systems (up to 6 pages excluding bibliography and
appendix). Industry and tool papers will be evaluated on their
relevance, usefulness, and results. Suitability for demonstration and
availability will also be considered for tool papers.

 4. Posters, which can be accompanied by a one-page abstract and will
be evaluated on similar criteria as Work-in-progress papers. Posters
can accompany any submission as a way to provide additional
demonstration and discussion opportunities.

MPLR 2019 submissions must conform to the ACM Policy on Prior
Publication and Simultaneous Submissions and to the SIGPLAN
Republication Policy.

# Important Dates and Organization

Submission Deadline:     ***Jul 8, 2019***
Author Notification:              Aug 24, 2019
Camera Ready:                   Sep 12, 2019
Conference Dates:              Oct 20-25, 2019

General Chair: Tony Hosking, Australian National University / Data61, Australia
Program Chair: Irene Finocchi, Sapienza University of Rome, Italy

Program Committee:
 * Edd Barrett, King's College London, United Kingdom
 * Steve Blackburn, Australian National University, Australia
 * Lubomir Bulej, Charles University, Czech Republic
 * Shigeru Chiba, University of Tokyo, Japan
 * Daniele Cono D'Elia, Sapienza University of Rome, Italy
 * Ana Lucia de Moura, Pontifical Catholic University of Rio de Janeiro, Brazil
 * Erik Ernst, Google, Denmark
 * Matthew Hertz, University at Buffalo, United States
 * Vivek Kumar, Indraprastha Institute of Information Technology, Delhi
 * Doug Lea, State University of New York (SUNY) Oswego, United States
 * Magnus Madsen, Aarhus University, Denmark
 * Hidehiko Masuhara, Tokyo Institute of Technology, Japan
 * Ana Milanova, Rensselaer Polytechnic Institute, United States
 * Matthew Parkinson, Microsoft Research, United Kingdom
 * Gregor Richards, University of Waterloo, Canada
 * Manuel Rigger, ETH Zurich, Switzerland
 * Andrea Rosa, University of Lugano, Switzerland
 * Guido Salvaneschi, TU Darmstadt, Germany
 * Lukas Stadler, Oracle Labs, Austria
 * Ben L. Titzer, Google, Germany

From dean.long at oracle.com  Tue Jun 18 17:52:06 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Tue, 18 Jun 2019 10:52:06 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
Message-ID: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8225369
http://cr.openjdk.java.net/~dlong/8225369/webrev/

This test triggers a race, which can result in different resolved values 
of the MethodHandle constant.? The VM chooses a winner and stores that 
value in the constant pool cache, however Graal is not checking the 
cache.? The trivial fix is to use the proper API that goes through the 
cache.

dl

From vladimir.kozlov at oracle.com  Tue Jun 18 18:01:49 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 18 Jun 2019 11:01:49 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
In-Reply-To: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
Message-ID: <1e976016-9592-065b-5c03-2be382013d00@oracle.com>

Looks good.

Thanks,
Vladimir

On 6/18/19 10:52 AM, dean.long at oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8225369
> http://cr.openjdk.java.net/~dlong/8225369/webrev/
> 
> This test triggers a race, which can result in different resolved values of the MethodHandle constant.? The VM chooses a 
> winner and stores that value in the constant pool cache, however Graal is not checking the cache.? The trivial fix is to 
> use the proper API that goes through the cache.
> 
> dl

From dean.long at oracle.com  Tue Jun 18 18:03:12 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Tue, 18 Jun 2019 11:03:12 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
In-Reply-To: <1e976016-9592-065b-5c03-2be382013d00@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <1e976016-9592-065b-5c03-2be382013d00@oracle.com>
Message-ID: <4c63c0ab-1b83-11c2-3c14-8614e7c27b43@oracle.com>

Thanks Vladimir.

dl

On 6/18/19 11:01 AM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 6/18/19 10:52 AM, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8225369
>> http://cr.openjdk.java.net/~dlong/8225369/webrev/
>>
>> This test triggers a race, which can result in different resolved 
>> values of the MethodHandle constant.? The VM chooses a winner and 
>> stores that value in the constant pool cache, however Graal is not 
>> checking the cache.? The trivial fix is to use the proper API that 
>> goes through the cache.
>>
>> dl


From jesper.wilhelmsson at oracle.com  Wed Jun 19 23:58:24 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 20 Jun 2019 01:58:24 +0200
Subject: RFR: JDK-8223807 - Update Graal
In-Reply-To: <10CB23D8-7D4F-40C5-AD54-B2E8E3E71C52@oracle.com>
References: <604DC580-A1DD-416C-8477-61894757F55A@oracle.com>
 <2adacc9e-ed0e-ffd7-86bd-7d0c617ddc95@oracle.com>
 <67f36d91-1936-2937-756f-ae75f8bf03ae@oracle.com>
 <10CB23D8-7D4F-40C5-AD54-B2E8E3E71C52@oracle.com>
Message-ID: <9B10D185-8D4B-484B-92A2-D7B8F5F2326F@oracle.com>

Due to the delay in getting this snapshot pushed, and the fact that we see test failures with this snapshot that has been fixed / is being fixed in Graal, this integration is withdrawn. We will start a new integration with a more recent graal snapshot as soon as the known issues are resolved.
/Jesper

> On 11 Jun 2019, at 04:45, jesper.wilhelmsson at oracle.com wrote:
> 
> Hi,
> 
> I re-applied the patch for JDK-8209626 and restarted the testing.
> /Jesper
> 
>> On 10 Jun 2019, at 18:05, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>> These changes incorrectly reversed part of 8209626 changes in jaotc/MetadataBuilder.java file causing these AOT failures.
>> 
>> Vladimir
>> 
>> On 6/10/19 8:49 AM, Vladimir Kozlov wrote:
>>> There are a lot of crashes in compiler/aot and gc/stress/gcbasher tests. We need to resolve them.
>>> It seems you don't need to apply `overwritten` changes - Update changes has them.
>>> Thanks,
>>> Vladimir
>>> On 6/7/19 5:58 PM, jesper.wilhelmsson at oracle.com wrote:
>>>> Hi,
>>>> 
>>>> Please review the patch to integrate recent Graal changes into OpenJDK.
>>>> Graal tip to integrate: e0e099390465ad1414ee1da26a5f5723e5274433
>>>> 
>>>> JBS duplicates fixed by this integration:
>>>> https://bugs.openjdk.java.net/browse/JDK-8223924
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223807
>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8223807/webrev.00/
>>>> 
>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
>>>> 
>>>> Thanks,
>>>> /Jesper
>>>> 
> 


From tom.rodriguez at oracle.com  Fri Jun 21 16:42:34 2019
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 21 Jun 2019 09:42:34 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
In-Reply-To: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
Message-ID: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>

Doesn't that make resolveConstantInPool completely unused?  It should 
probably be deleted and the javadoc updated for 
resolvePossiblyCachedConstantInPool.

tom

dean.long at oracle.com wrote on 6/18/19 10:52 AM:
> https://bugs.openjdk.java.net/browse/JDK-8225369
> http://cr.openjdk.java.net/~dlong/8225369/webrev/
> 
> This test triggers a race, which can result in different resolved values 
> of the MethodHandle constant.? The VM chooses a winner and stores that 
> value in the constant pool cache, however Graal is not checking the 
> cache.? The trivial fix is to use the proper API that goes through the 
> cache.
> 
> dl

From dean.long at oracle.com  Fri Jun 21 19:48:25 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Fri, 21 Jun 2019 12:48:25 -0700
Subject: RFR (S) 8222446:
 assert(C->env()->system_dictionary_modification_counter_changed()) failed:
 Must invalidate if TypeFuncs differ
In-Reply-To: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com>
References: <703b29a2-71a6-27d7-99e3-d54216332c33@oracle.com>
Message-ID: <fac0ad2e-28a3-4817-cf1d-88a6fa84d990@oracle.com>

For the most part, this looks good.? I only have a couple concerns:

1) The distinction in both validate_compile_task_dependencies functions 
between "dependencies failed" and "dependencies invalid" is even more 
fuzzy after this change.? I suggest filing an RFE to remove this 
distinction.

2) In Parse::do_exits(), we don't know that concurrent class loading 
didn't cause the problem.? We should be optimistic and allow the retry:
C->record_failure(C2Compiler::retry_class_loading_during_parsing());
rather than more drastic
 ??? C->record_method_not_compilable
This is actually what the code did in an earlier revision.

dl

On 6/20/19 10:28 AM, coleen.phillimore at oracle.com wrote:
> Summary: Remove SystemDictionary::modification_counter optimization
>
> See bug for more details.? To avoid the assert in the bug report, it's 
> necessary to also increase the modification counter for class 
> unloading, which needs special code for concurrent class unloading. 
> The global counter is used to verify that validate_dependencies() gets 
> the same answer based on the subklass hierarchy, but provides a quick 
> exit in production mode.? Removing it may allow more nmethods to be 
> created that don't depend on the classes that may be loaded while the 
> Method is being compiled. Performance testing was done on this with no 
> change in performance.? Also investigated the breakpoint setting code 
> which incremented the modification counter. Dependent compilations are 
> invalidated using evol_method dependencies, so updating the system 
> dictionary modification counter isn't unnecessary.
>
> Tested with hs-tier1-8 testing, and CTW, and local jvmti/jdi/jdwp test 
> runs with -Xcomp.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8222446.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8222446
>
> Thanks,
> Coleen


From dean.long at oracle.com  Fri Jun 21 20:09:48 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Fri, 21 Jun 2019 13:09:48 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
In-Reply-To: <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
Message-ID: <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>

On 6/21/19 9:42 AM, Tom Rodriguez wrote:
> Doesn't that make resolveConstantInPool completely unused?

Yes, except for a jtreg test, which can be removed.

> It should probably be deleted and the javadoc updated for 
> resolvePossiblyCachedConstantInPool.

OK.

dl

>
> tom
>
> dean.long at oracle.com wrote on 6/18/19 10:52 AM:
>> https://bugs.openjdk.java.net/browse/JDK-8225369
>> http://cr.openjdk.java.net/~dlong/8225369/webrev/
>>
>> This test triggers a race, which can result in different resolved 
>> values of the MethodHandle constant.? The VM chooses a winner and 
>> stores that value in the constant pool cache, however Graal is not 
>> checking the cache.? The trivial fix is to use the proper API that 
>> goes through the cache.
>>
>> dl


From dean.long at oracle.com  Fri Jun 21 20:14:07 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Fri, 21 Jun 2019 13:14:07 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
In-Reply-To: <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
Message-ID: <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>

If we only have one API, renaming resolvePossiblyCachedConstantInPool to 
resolveConstantInPool would make it more consistent with other resolve 
methods.? What do you think?

dl

On 6/21/19 1:09 PM, dean.long at oracle.com wrote:
> On 6/21/19 9:42 AM, Tom Rodriguez wrote:
>> Doesn't that make resolveConstantInPool completely unused?
>
> Yes, except for a jtreg test, which can be removed.
>
>> It should probably be deleted and the javadoc updated for 
>> resolvePossiblyCachedConstantInPool.
>
> OK.
>
> dl
>
>>
>> tom
>>
>> dean.long at oracle.com wrote on 6/18/19 10:52 AM:
>>> https://bugs.openjdk.java.net/browse/JDK-8225369
>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/
>>>
>>> This test triggers a race, which can result in different resolved 
>>> values of the MethodHandle constant.? The VM chooses a winner and 
>>> stores that value in the constant pool cache, however Graal is not 
>>> checking the cache.? The trivial fix is to use the proper API that 
>>> goes through the cache.
>>>
>>> dl
>


From tom.rodriguez at oracle.com  Fri Jun 21 20:35:55 2019
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 21 Jun 2019 13:35:55 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
In-Reply-To: <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
Message-ID: <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>



dean.long at oracle.com wrote on 6/21/19 1:14 PM:
> If we only have one API, renaming resolvePossiblyCachedConstantInPool to 
> resolveConstantInPool would make it more consistent with other resolve 
> methods.? What do you think?

I assume the naming is to provide a clue to the API use in ConstantPool. 
  It does seem like it's really only about constants and not general 
constant pool resolution right?

tom

> 
> dl
> 
> On 6/21/19 1:09 PM, dean.long at oracle.com wrote:
>> On 6/21/19 9:42 AM, Tom Rodriguez wrote:
>>> Doesn't that make resolveConstantInPool completely unused?
>>
>> Yes, except for a jtreg test, which can be removed.
>>
>>> It should probably be deleted and the javadoc updated for 
>>> resolvePossiblyCachedConstantInPool.
>>
>> OK.
>>
>> dl
>>
>>>
>>> tom
>>>
>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM:
>>>> https://bugs.openjdk.java.net/browse/JDK-8225369
>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/
>>>>
>>>> This test triggers a race, which can result in different resolved 
>>>> values of the MethodHandle constant.? The VM chooses a winner and 
>>>> stores that value in the constant pool cache, however Graal is not 
>>>> checking the cache.? The trivial fix is to use the proper API that 
>>>> goes through the cache.
>>>>
>>>> dl
>>
> 

From dean.long at oracle.com  Fri Jun 21 21:59:45 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Fri, 21 Jun 2019 14:59:45 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
In-Reply-To: <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
Message-ID: <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>

On 6/21/19 1:35 PM, Tom Rodriguez wrote:
>
>
> dean.long at oracle.com wrote on 6/21/19 1:14 PM:
>> If we only have one API, renaming resolvePossiblyCachedConstantInPool 
>> to resolveConstantInPool would make it more consistent with other 
>> resolve methods.? What do you think?
>
> I assume the naming is to provide a clue to the API use in 
> ConstantPool. ?It does seem like it's really only about constants and 
> not general constant pool resolution right?
>
Yes, it's about those types of constants that are Objects.? The 
resolution could involve calling into Java, but we should only do that 
once.? That's why the cache is important.? Going through the cache 
should be the default, and every other lookup and resolve method should 
be going through the cache, so the PossiblyCached part seems confusing 
and redundant now.

dl
> tom
>
>>
>> dl
>>
>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote:
>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote:
>>>> Doesn't that make resolveConstantInPool completely unused?
>>>
>>> Yes, except for a jtreg test, which can be removed.
>>>
>>>> It should probably be deleted and the javadoc updated for 
>>>> resolvePossiblyCachedConstantInPool.
>>>
>>> OK.
>>>
>>> dl
>>>
>>>>
>>>> tom
>>>>
>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369
>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/
>>>>>
>>>>> This test triggers a race, which can result in different resolved 
>>>>> values of the MethodHandle constant.? The VM chooses a winner and 
>>>>> stores that value in the constant pool cache, however Graal is not 
>>>>> checking the cache.? The trivial fix is to use the proper API that 
>>>>> goes through the cache.
>>>>>
>>>>> dl
>>>
>>


From tom.rodriguez at oracle.com  Fri Jun 21 23:39:38 2019
From: tom.rodriguez at oracle.com (Tom Rodriguez)
Date: Fri, 21 Jun 2019 16:39:38 -0700
Subject: [13] RFR(XXS) 8225369: [AOT]
 vm/classfmt/cpl/cplres001/cplres00101m004/cplres00101m004.html fails
In-Reply-To: <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
References: <b5c13a69-0ff0-0c27-e873-2039cb67171c@oracle.com>
 <326fa1bb-5c13-31a8-22b1-003b00173aa9@oracle.com>
 <94761d6a-0225-3b3e-d212-37cb8f13f979@oracle.com>
 <c88f4b8c-870f-b5ce-83e7-8bc391c1846e@oracle.com>
 <0176d473-73e8-00e5-2f24-6ede85c1a938@oracle.com>
 <f1aab753-fa7c-d021-7464-332dc065ead6@oracle.com>
Message-ID: <3247043f-0995-6d0d-96a7-495566bcb136@oracle.com>



dean.long at oracle.com wrote on 6/21/19 2:59 PM:
> On 6/21/19 1:35 PM, Tom Rodriguez wrote:
>>
>>
>> dean.long at oracle.com wrote on 6/21/19 1:14 PM:
>>> If we only have one API, renaming resolvePossiblyCachedConstantInPool 
>>> to resolveConstantInPool would make it more consistent with other 
>>> resolve methods.? What do you think?
>>
>> I assume the naming is to provide a clue to the API use in 
>> ConstantPool. ?It does seem like it's really only about constants and 
>> not general constant pool resolution right?
>>
> Yes, it's about those types of constants that are Objects.? The 
> resolution could involve calling into Java, but we should only do that 
> once.? That's why the cache is important.? Going through the cache 
> should be the default, and every other lookup and resolve method should 
> be going through the cache, so the PossiblyCached part seems confusing 
> and redundant now.

Is this something that's changed in 13+?  It would be nice to maintain 
JVMCI source consistency between 8 and 13 where possible.  Anyway, I 
don't feel strongly either way about the name.  It's pure internals anyway.

tom

> 
> dl
>> tom
>>
>>>
>>> dl
>>>
>>> On 6/21/19 1:09 PM, dean.long at oracle.com wrote:
>>>> On 6/21/19 9:42 AM, Tom Rodriguez wrote:
>>>>> Doesn't that make resolveConstantInPool completely unused?
>>>>
>>>> Yes, except for a jtreg test, which can be removed.
>>>>
>>>>> It should probably be deleted and the javadoc updated for 
>>>>> resolvePossiblyCachedConstantInPool.
>>>>
>>>> OK.
>>>>
>>>> dl
>>>>
>>>>>
>>>>> tom
>>>>>
>>>>> dean.long at oracle.com wrote on 6/18/19 10:52 AM:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225369
>>>>>> http://cr.openjdk.java.net/~dlong/8225369/webrev/
>>>>>>
>>>>>> This test triggers a race, which can result in different resolved 
>>>>>> values of the MethodHandle constant.? The VM chooses a winner and 
>>>>>> stores that value in the constant pool cache, however Graal is not 
>>>>>> checking the cache.? The trivial fix is to use the proper API that 
>>>>>> goes through the cache.
>>>>>>
>>>>>> dl
>>>>
>>>
> 

From doug.simon at oracle.com  Tue Jun 25 06:28:06 2019
From: doug.simon at oracle.com (Doug Simon)
Date: Tue, 25 Jun 2019 08:28:06 +0200
Subject: JVMCI 20-b04 released
Message-ID: <C112EEAB-F456-4FF1-82F4-BBE6E2DE8D19@oracle.com>

Changes since jvmci-20-b03 include:

? GR-16316: Exit the VM if there's an exception initializing JVMCI when compiling a method.
? GR-16369: Added HotSpotObjectConstantScope to control foreign object lifetimes.
? GR-16327: Deoptimization needs to be aware of box caching.
? GR-16485: Add workaround for JavaScript usage in the SA.
? GR-16577: Add support for cleanly exiting VM from libgraal.
? GR-15859: Ensure G1 always sees weak oops read in native JVMCI code as live.
? GR-16607: Add getArrayType to handle anonymous types.
? GR-16462: Ensure libzip.a on Darwin contains zlib object files.

The binaries are available at:

https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-20-b04

-Doug




From jesper.wilhelmsson at oracle.com  Tue Jun 25 19:51:49 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 25 Jun 2019 21:51:49 +0200
Subject: RFR: JDK-8225497 - Update Graal
Message-ID: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>

Hi,

Please review the patch to integrate recent Graal changes into OpenJDK.
Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff

JBS duplicates fixed by this integration:
https://bugs.openjdk.java.net/browse/JDK-8223924
https://bugs.openjdk.java.net/browse/JDK-8221514
https://bugs.openjdk.java.net/browse/JDK-8221577
https://bugs.openjdk.java.net/browse/JDK-8224254

Bug: https://bugs.openjdk.java.net/browse/JDK-8225497
Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/

This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.

Thanks,
/Jesper

From vladimir.kozlov at oracle.com  Tue Jun 25 19:57:39 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 25 Jun 2019 12:57:39 -0700
Subject: RFR: JDK-8225497 - Update Graal
In-Reply-To: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
Message-ID: <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>

Hi Jesper

Webrev link is broken.

Vladimir

On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote:
> Hi,
> 
> Please review the patch to integrate recent Graal changes into OpenJDK.
> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff
> 
> JBS duplicates fixed by this integration:
> https://bugs.openjdk.java.net/browse/JDK-8223924
> https://bugs.openjdk.java.net/browse/JDK-8221514
> https://bugs.openjdk.java.net/browse/JDK-8221577
> https://bugs.openjdk.java.net/browse/JDK-8224254
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/
> 
> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
> 
> Thanks,
> /Jesper
> 

From jesper.wilhelmsson at oracle.com  Tue Jun 25 21:21:33 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 25 Jun 2019 23:21:33 +0200
Subject: RFR: JDK-8225497 - Update Graal
In-Reply-To: <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
Message-ID: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>

Oops. Fixed.
/Jesper

> On 25 Jun 2019, at 21:57, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Hi Jesper
> 
> Webrev link is broken.
> 
> Vladimir
> 
> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote:
>> Hi,
>> Please review the patch to integrate recent Graal changes into OpenJDK.
>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff
>> JBS duplicates fixed by this integration:
>> https://bugs.openjdk.java.net/browse/JDK-8223924
>> https://bugs.openjdk.java.net/browse/JDK-8221514
>> https://bugs.openjdk.java.net/browse/JDK-8221577
>> https://bugs.openjdk.java.net/browse/JDK-8224254
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/
>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
>> Thanks,
>> /Jesper


From vladimir.kozlov at oracle.com  Tue Jun 25 23:15:00 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 25 Jun 2019 16:15:00 -0700
Subject: RFR: JDK-8225497 - Update Graal
In-Reply-To: <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
 <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
Message-ID: <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>

In general changes looks good.

But changes are and the testing are done with jdk/jdk as base. We need this 'Update Graal' in JDK 13.

I looked on testing results and they look good so far (still running). I linked existing bugs for some failures. And 
other failures seem were present before.

I checked overwritten-diffs.txt and you don't need to apply it. Changes in this 'Update Graal' includes them. And again, 
for JDK 13 it could be different.

Thanks,
Vladimir

On 6/25/19 2:21 PM, jesper.wilhelmsson at oracle.com wrote:
> Oops. Fixed.
> /Jesper
> 
>> On 25 Jun 2019, at 21:57, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> Hi Jesper
>>
>> Webrev link is broken.
>>
>> Vladimir
>>
>> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote:
>>> Hi,
>>> Please review the patch to integrate recent Graal changes into OpenJDK.
>>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff
>>> JBS duplicates fixed by this integration:
>>> https://bugs.openjdk.java.net/browse/JDK-8223924
>>> https://bugs.openjdk.java.net/browse/JDK-8221514
>>> https://bugs.openjdk.java.net/browse/JDK-8221577
>>> https://bugs.openjdk.java.net/browse/JDK-8224254
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/
>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
>>> Thanks,
>>> /Jesper
> 

From jesper.wilhelmsson at oracle.com  Wed Jun 26 01:46:01 2019
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 26 Jun 2019 03:46:01 +0200
Subject: RFR: JDK-8225497 - Update Graal
In-Reply-To: <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
 <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
 <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>
Message-ID: <AFA7180F-017F-4340-A513-189CBB443D19@oracle.com>

This is a webrev based on JDK 13: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/ <http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/>
I have restarted the testing with this merge.
/Jesper

> On 26 Jun 2019, at 01:15, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> In general changes looks good.
> 
> But changes are and the testing are done with jdk/jdk as base. We need this 'Update Graal' in JDK 13.
> 
> I looked on testing results and they look good so far (still running). I linked existing bugs for some failures. And other failures seem were present before.
> 
> I checked overwritten-diffs.txt and you don't need to apply it. Changes in this 'Update Graal' includes them. And again, for JDK 13 it could be different.
> 
> Thanks,
> Vladimir
> 
> On 6/25/19 2:21 PM, jesper.wilhelmsson at oracle.com wrote:
>> Oops. Fixed.
>> /Jesper
>>> On 25 Jun 2019, at 21:57, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> Hi Jesper
>>> 
>>> Webrev link is broken.
>>> 
>>> Vladimir
>>> 
>>> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote:
>>>> Hi,
>>>> Please review the patch to integrate recent Graal changes into OpenJDK.
>>>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff
>>>> JBS duplicates fixed by this integration:
>>>> https://bugs.openjdk.java.net/browse/JDK-8223924
>>>> https://bugs.openjdk.java.net/browse/JDK-8221514
>>>> https://bugs.openjdk.java.net/browse/JDK-8221577
>>>> https://bugs.openjdk.java.net/browse/JDK-8224254
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497
>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/
>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
>>>> Thanks,
>>>> /Jesper


From vladimir.kozlov at oracle.com  Wed Jun 26 16:33:40 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 26 Jun 2019 09:33:40 -0700
Subject: RFR: JDK-8225497 - Update Graal
In-Reply-To: <AFA7180F-017F-4340-A513-189CBB443D19@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
 <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
 <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>
 <AFA7180F-017F-4340-A513-189CBB443D19@oracle.com>
Message-ID: <74b8ac64-32b4-ff4c-3708-97432697680d@oracle.com>

Looks good.

I looked on testing results. We still hit gcbasher failures but it is not new and we will work on it.
Other failures I known timeout or other known bugs.

I think we can push this into jdk 13.

Thanks,
Vladimir

On 6/25/19 6:46 PM, jesper.wilhelmsson at oracle.com wrote:
> This is a webrev based on JDK 13: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/ <http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/>
> I have restarted the testing with this merge.
> /Jesper
> 
>> On 26 Jun 2019, at 01:15, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> In general changes looks good.
>>
>> But changes are and the testing are done with jdk/jdk as base. We need this 'Update Graal' in JDK 13.
>>
>> I looked on testing results and they look good so far (still running). I linked existing bugs for some failures. And other failures seem were present before.
>>
>> I checked overwritten-diffs.txt and you don't need to apply it. Changes in this 'Update Graal' includes them. And again, for JDK 13 it could be different.
>>
>> Thanks,
>> Vladimir
>>
>> On 6/25/19 2:21 PM, jesper.wilhelmsson at oracle.com wrote:
>>> Oops. Fixed.
>>> /Jesper
>>>> On 25 Jun 2019, at 21:57, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>
>>>> Hi Jesper
>>>>
>>>> Webrev link is broken.
>>>>
>>>> Vladimir
>>>>
>>>> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote:
>>>>> Hi,
>>>>> Please review the patch to integrate recent Graal changes into OpenJDK.
>>>>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff
>>>>> JBS duplicates fixed by this integration:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8223924
>>>>> https://bugs.openjdk.java.net/browse/JDK-8221514
>>>>> https://bugs.openjdk.java.net/browse/JDK-8221577
>>>>> https://bugs.openjdk.java.net/browse/JDK-8224254
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497
>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/
>>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
>>>>> Thanks,
>>>>> /Jesper
> 

From vladimir.kozlov at oracle.com  Wed Jun 26 19:13:39 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 26 Jun 2019 12:13:39 -0700
Subject: RFR: JDK-8225497 - Update Graal
In-Reply-To: <74b8ac64-32b4-ff4c-3708-97432697680d@oracle.com>
References: <EA80FB27-38FF-420D-82B5-2B40159F40BC@oracle.com>
 <ae90b388-ec39-8032-183a-c022094cc8b9@oracle.com>
 <225C06B6-9143-4A19-9421-F34DCEC361C8@oracle.com>
 <e431d7ac-6f70-8dcd-bc2d-0fb346fd44f7@oracle.com>
 <AFA7180F-017F-4340-A513-189CBB443D19@oracle.com>
 <74b8ac64-32b4-ff4c-3708-97432697680d@oracle.com>
Message-ID: <8472328F-CFC3-4CD8-A1F4-84CA20FCE080@oracle.com>

After discussing with Mikael I was convinced to not push this Graal update into JDK 13 - too many changes not related to listed bugs it fixed.

This should go only into current JDK.

Thanks
Vladimir

> On Jun 26, 2019, at 9:33 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Looks good.
> 
> I looked on testing results. We still hit gcbasher failures but it is not new and we will work on it.
> Other failures I known timeout or other known bugs.
> 
> I think we can push this into jdk 13.
> 
> Thanks,
> Vladimir
> 
>> On 6/25/19 6:46 PM, jesper.wilhelmsson at oracle.com wrote:
>> This is a webrev based on JDK 13: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/ <http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.01/>
>> I have restarted the testing with this merge.
>> /Jesper
>>> On 26 Jun 2019, at 01:15, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> In general changes looks good.
>>> 
>>> But changes are and the testing are done with jdk/jdk as base. We need this 'Update Graal' in JDK 13.
>>> 
>>> I looked on testing results and they look good so far (still running). I linked existing bugs for some failures. And other failures seem were present before.
>>> 
>>> I checked overwritten-diffs.txt and you don't need to apply it. Changes in this 'Update Graal' includes them. And again, for JDK 13 it could be different.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>>> On 6/25/19 2:21 PM, jesper.wilhelmsson at oracle.com wrote:
>>>> Oops. Fixed.
>>>> /Jesper
>>>>> On 25 Jun 2019, at 21:57, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>> 
>>>>> Hi Jesper
>>>>> 
>>>>> Webrev link is broken.
>>>>> 
>>>>> Vladimir
>>>>> 
>>>>>> On 6/25/19 12:51 PM, jesper.wilhelmsson at oracle.com wrote:
>>>>>> Hi,
>>>>>> Please review the patch to integrate recent Graal changes into OpenJDK.
>>>>>> Graal tip to integrate: ea9d5c4b76a4ba95f80945970ad8489db52344ff
>>>>>> JBS duplicates fixed by this integration:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223924
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8221514
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8221577
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8224254
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225497
>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8225497/webrev.00/
>>>>>> This integration did overwrite changes already in place in OpenJDK. The diff has been attached to the umbrella bug.
>>>>>> Thanks,
>>>>>> /Jesper


From dean.long at oracle.com  Thu Jun 27 23:49:09 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Thu, 27 Jun 2019 16:49:09 -0700
Subject: [13] RFR(XXS) 8226533: JVMCI: findUniqueConcreteMethod should handle
 statically bindable methods directly
Message-ID: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8226533
http://cr.openjdk.java.net/~dlong/8226533/webrev/

This fixes a problem that shows up with -XX:+BootstrapJVMCI after 
JDK-8223050.? Thanks Doug for the patch.

dl

From vladimir.kozlov at oracle.com  Fri Jun 28 00:23:44 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 27 Jun 2019 17:23:44 -0700
Subject: [13] RFR(XXS) 8226533: JVMCI: findUniqueConcreteMethod should
 handle statically bindable methods directly
In-Reply-To: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>
References: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>
Message-ID: <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com>

Looks good.

Thanks
Vladimir

> On Jun 27, 2019, at 4:49 PM, dean.long at oracle.com wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8226533
> http://cr.openjdk.java.net/~dlong/8226533/webrev/
> 
> This fixes a problem that shows up with -XX:+BootstrapJVMCI after JDK-8223050.  Thanks Doug for the patch.
> 
> dl


From dean.long at oracle.com  Fri Jun 28 00:52:26 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Thu, 27 Jun 2019 17:52:26 -0700
Subject: [13] RFR(XXS) 8226533: JVMCI: findUniqueConcreteMethod should
 handle statically bindable methods directly
In-Reply-To: <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com>
References: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>
 <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com>
Message-ID: <0c9c376b-7cea-66dc-e13d-302f02167c01@oracle.com>

Thanks Vladimir.

dl

On 6/27/19 5:23 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks
> Vladimir
>
>> On Jun 27, 2019, at 4:49 PM, dean.long at oracle.com wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8226533
>> http://cr.openjdk.java.net/~dlong/8226533/webrev/
>>
>> This fixes a problem that shows up with -XX:+BootstrapJVMCI after JDK-8223050.  Thanks Doug for the patch.
>>
>> dl


From dean.long at oracle.com  Fri Jun 28 18:13:09 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Fri, 28 Jun 2019 11:13:09 -0700
Subject: [13] RFR(XXS) 8226533: JVMCI: findUniqueConcreteMethod should
 handle statically bindable methods directly
In-Reply-To: <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com>
References: <d685e948-1e6e-0fe5-f027-5535653c6b05@oracle.com>
 <85F9BD8E-31A1-456F-A168-3958D2E093EC@oracle.com>
Message-ID: <a53d19d4-0712-8ad1-1c41-0600816da19c@oracle.com>

Since Doug Simon is the contributor, I'll list myself as the second 
reviewer and push this.

dl

On 6/27/19 5:23 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks
> Vladimir
>
>> On Jun 27, 2019, at 4:49 PM, dean.long at oracle.com wrote:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8226533
>> http://cr.openjdk.java.net/~dlong/8226533/webrev/
>>
>> This fixes a problem that shows up with -XX:+BootstrapJVMCI after JDK-8223050.  Thanks Doug for the patch.
>>
>> dl