From Yang.Zhang at arm.com  Mon Sep  2 03:45:00 2019
From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China))
Date: Mon, 2 Sep 2019 03:45:00 +0000
Subject: [vector] generic operand infrastructure support.
In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB8B7BA31@FMSMSX125.amr.corp.intel.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A046865@BGSMSX106.gar.corp.intel.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB8B7BA31@FMSMSX125.amr.corp.intel.com>
Message-ID: <VE1PR08MB46567F15C97881E43CFB0AEB8EBE0@VE1PR08MB4656.eurprd08.prod.outlook.com>

Hi Jatin, Sandhya

This patch is very generic. All the projects which are using vector instructions in backend can benefit from it. To reduce manual merge works in the future, proposing this patch to jdk/jdk master would be better. 

I test this patch in our internal ci test framework. In x86 platform, build fails. The post-selection pass is missed. The error log is as follows:
src/hotspot/share/opto/compile.cpp:2945: undefined reference to `Matcher::do_post_selection_processing(Compile*, Node*)'
Besides that, there are also some trailing spaces and blank lines.

Regards
Yang

-----Original Message-----
From: panama-dev <panama-dev-bounces at openjdk.java.net> On Behalf Of Viswanathan, Sandhya
Sent: Saturday, August 31, 2019 6:08 AM
To: Bhateja, Jatin <jatin.bhateja at intel.com>; panama-dev at openjdk.java.net
Subject: RE: [vector] generic operand infrastructure support.

Hi Jatin,

The patch looks good to me.

Best Regards,
Sandhya


From: Bhateja, Jatin
Sent: Friday, August 30, 2019 5:07 AM
To: panama-dev at openjdk.java.net
Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
Subject: [vector] generic operand infrastructure support.

Hi All,

We have been working over reducing the AD file and libjvm.so size by reducing the number of vector instruction patterns whose operands differ meagerly in vector lengths.
As of now we have several vector operand for X86 target like vecS , vecD, vecX , vecY, vecZ and their legacy variants. This patch adds an infrastructure to support generic operands[1]  and a post-selection pass to remove them from machine graph so that there is minimal impact on the downstream passes.

Complete patch using generic operands which reduces the number of vector patterns from 510 to 222 is already posted over mainline https://mail.openjdk.java.net/piperail/hotspot-compiler-dev/2019-August/034822.html

Since vectorIntrinsics branch has bulk of the vector instruction patterns hence we plan to introduce the support in stages.

Following patch contains the infrastructure changes for generic operands, using it we can collapse the different vector length instructions for same operation without making any changes in the ideal graph.
CR : http://cr.openjdk.java.net/~jbhateja/vectorIntrinsics/GEN_OPERS/webrev.00/
Common JBS for jdk/mainline and panama/vectorIntrinsics : https://bugs.openjdk.java.net/browse/JDK-8230015

Kindly review it provide your feedback.

Best Regards,
Jatin Bhateja

PS : All the changes are currently enabled only for X86 target.
[1]  http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf


From henry.jen at oracle.com  Mon Sep  2 05:15:59 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Sun, 1 Sep 2019 22:15:59 -0700
Subject: [foreign] Panama EA - August 2019 edition
In-Reply-To: <f5a9af5e-7b0e-cc12-3b33-9dcbdc5a537a@gmail.com>
References: <79c97983-bff7-c585-b75d-8aced6303c71@gmail.com>
 <243c3854-a3d5-1773-017d-7eedc6bdbe5c@oracle.com>
 <5e449470-527d-0b5d-a3b1-478138d7d9b2@oracle.com>
 <49599123-0e2c-076c-a0a4-039564902f4c@gmail.com>
 <17a8ca15-55ec-a279-c47d-e9e14a470b86@oracle.com>
 <1d32e336-9768-7c08-20ee-4ddfea4f0820@gmail.com>
 <12c41ad1-6b79-6808-6551-5244dacaf091@oracle.com>
 <8b8ae39e-cbcb-8436-ecc6-726adcc12e68@gmail.com>
 <bff08c41-b254-b6f2-7143-066a983d5e7e@oracle.com>
 <f5a9af5e-7b0e-cc12-3b33-9dcbdc5a537a@gmail.com>
Message-ID: <48C16F74-DD6E-4584-876F-8542C9D5E35F@oracle.com>

In early days, we have a function in Scope to convert String[] into Pointer<Pointer<Byte>> as this is pretty common use case, it?s took out because it?s considered easy to implement. Anyhow, I found my self add this function all the time.

Cheers,
Henry

public static Pointer<Pointer<Byte>> toCStrArray(Scope sc, String[] ar) {
    if (ar.length == 0) {
        return Pointer.ofNull();
    }

    Pointer<Pointer<Byte>> ptr = sc.allocate(NativeTypes.UINT8.pointer(), ar.length);
    for (int i = 0; i < ar.length; i++) {
        Pointer<Byte> s = sc.allocateCString(ar[i]);
        ptr.offset(i).set(s);
    }

    return ptr;
}

> On Aug 30, 2019, at 1:21 PM, Ty Young <youngty1997 at gmail.com> wrote:
> 
> 
> On 8/30/19 3:12 PM, Maurizio Cimadamore wrote:
>> 
>> On 30/08/2019 20:07, Ty Young wrote:
>>> 
>>> On 8/30/19 12:54 PM, Maurizio Cimadamore wrote:
>>>> 
>>>> On 30/08/2019 18:41, Ty Young wrote:
>>>>> 
>>>>> On 8/30/19 12:25 PM, Maurizio Cimadamore wrote:
>>>>>> 
>>>>>> On 30/08/2019 17:59, Ty Young wrote:
>>>>>>> 
>>>>>>> On 8/28/19 5:11 AM, Maurizio Cimadamore wrote:
>>>>>>>> I just want to clarify on this point below; the foreign memory access work does not, in any way, hinder the higher level functionalities provided by the foreign API/binder. We arrived at the foreign memory access API because we felt that something low level was missing - e.g. that the high level Pointer API was doing too much at once; and that users not interested in a high-level API, but still wanting to access off-heap data would not be served very well by the Pointer API alone.
>>>>>>>> 
>>>>>>>> So, moving forward you can expect the bulk of the foreign API to be relatively stable (well, it's a prototype, so we might tweak things here and there); what will really change is how this API is _implemented_ - that is, moving forward the foreign API will be built _on top_ of the lower memory access and ABI layers. But high-level use cases using jextract need not to worry about this.
>>>>>>>> 
>>>>>>>> I hope this clarifies better where we'd like to land.
>>>>>>> 
>>>>>>> 
>>>>>>> Yes, it does greatly. Thanks for clarifying.
>>>>>>> 
>>>>>>> 
>>>>>>> Speaking of the Pointer API, could a method be added to wrap a pointer in another pointer for **char string pointers? AFAIK, the only way to do that is:
>>>>>>> 
>>>>>>> 
>>>>>>> <LIB>.scope().allocate(<LIB>.scope().allocateCString("").type().pointer()); 
>>>>>>> 
>>>>>>> 
>>>>>>> ...which gets the Pointer<Pointer<Byte>> type that I need but I'm not entirely sure if this is the correct way to go about getting the type. Using the layout of a throwaway pointer layout just seems wrong and wasteful.
>>>>>> 
>>>>>> If you want to allocate a Pointer<Pointer<Byte>> you can do this:
>>>>>> 
>>>>>> 
>>>>>> <LIB>.scope().allocate(NativeTypes.UINT8.pointer());
>>>>>> 
>>>>> 
>>>>> Is the size the same as a C String with that?
>>>> 
>>>> When you allocate a C string using allocateCString, you get back a Pointer<Byte>; this has an 'address' layout - that is, the size of this value is platform dependent, but on x64 platforms you can assume it's 64 bits.
>>>> 
>>>> So, when you have a Pointer<Byte> and call type() on it, as in your previous code, you get the pointee layout type - that for 'Byte' (which is 8 bits). At which point you are calling pointer() on it, which is sending you back to a pointer layout type, with size 64 (again assuming we're on x64). So, the outer allocate will allocate 64 bits.
>>>> 
>>>> The code I suggested does the same - but without the throwaway allocation.
>>>> 
>>>> 
>>>> That said - I think what you really wanted to ask, is another question, one that has been raised before: assuming I have a Pointer<Byte> representing a C string, how do I get a pointer to that?
>>>> 
>>>> Am I correct?
>>> 
>>> 
>>> Yes.
>>> 
>>> 
>>> The function calls for a **char(documented as a string) but there is no obvious way to wrap the type returned by allocateCString(Pointer<Byte>) into another Pointer(Pointer<Pointer<Byte>>), hence the wasteful code above.
>> 
>> So, let's say we have this:
>> 
>> Pointer<Byte> c_str = scope.allocateCString("Hello");
>> 
>> Now we have to create a pointer to that pointer. To do that:
>> 
>> Pointer<Pointer<Byte>> p_c_str = scope.allocate(NativeTypes.UINT8.pointer());
>> 
>> And then initialize the contents of the pointer to pointer:
>> 
>> p_c_str.set(c_str);
>> 
>> You can now pass p_c_str to your function.
>> 
>> Is this what you wanted to do?
> 
> 
> Yes.
> 
> 
>> 
>> Maurizio
>> 
>>> 
>>> 
>>>> 
>>>> Maurizio
>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Maurizio
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Cheers
>>>>>>>> Maurizio
>>>>>>>> 
>>>>>>>> On 19/08/2019 10:33, sundararajan.athijegannathan at oracle.com wrote:
>>>>>>>>>> 
>>>>>>>>>> All that said, how close is Panama? Is this foreign memory API going to stay going forward or will the project take a major shift? I'd *really* like to start putting this to use and am willing to make adjustment where needed if minor changes are made, but if the entire foreign API is scrapped it isn't worth it.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Panama "memory access" ("memaccess" panama-dev branch) API is expected to become stable first and then other parts of java.foreign later ("foreign" branch stuff). 


From henry.jen at oracle.com  Mon Sep  2 06:20:08 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Sun, 1 Sep 2019 23:20:08 -0700
Subject: [foreign] Panama EA - August 2019 edition
In-Reply-To: <d65c6efd-e3a9-9d59-25da-1fd9daa92daa@oracle.com>
References: <79c97983-bff7-c585-b75d-8aced6303c71@gmail.com>
 <243c3854-a3d5-1773-017d-7eedc6bdbe5c@oracle.com>
 <5e449470-527d-0b5d-a3b1-478138d7d9b2@oracle.com>
 <49599123-0e2c-076c-a0a4-039564902f4c@gmail.com>
 <17a8ca15-55ec-a279-c47d-e9e14a470b86@oracle.com>
 <1d32e336-9768-7c08-20ee-4ddfea4f0820@gmail.com>
 <12c41ad1-6b79-6808-6551-5244dacaf091@oracle.com>
 <8b8ae39e-cbcb-8436-ecc6-726adcc12e68@gmail.com>
 <bff08c41-b254-b6f2-7143-066a983d5e7e@oracle.com>
 <8a654e79-8ef4-e200-503e-10660c0c99d7@oracle.com>
 <a8ee59ce-e6a6-b966-1165-d0184079a35e@oracle.com>
 <d65c6efd-e3a9-9d59-25da-1fd9daa92daa@oracle.com>
Message-ID: <2C01497F-D8CE-4E18-AAFE-BC9DD1AE2EA1@oracle.com>


> On Aug 31, 2019, at 4:57 AM, Jorn Vernee <JORN.VERNEE at ORACLE.COM> wrote:
> 
> 
> On 30/08/2019 22:34, Maurizio Cimadamore wrote:
>> 
>> On 30/08/2019 21:22, Maurizio Cimadamore wrote:
>>> 
>>> On 30/08/2019 21:12, Maurizio Cimadamore wrote:
>>>> 
>>>> 
>>>> So, let's say we have this:
>>>> 
>>>> Pointer<Byte> c_str = scope.allocateCString("Hello");
>>>> 
>>>> Now we have to create a pointer to that pointer. To do that:
>>>> 
>>>> Pointer<Pointer<Byte>> p_c_str = scope.allocate(NativeTypes.UINT8.pointer());
>>>> 
>>>> And then initialize the contents of the pointer to pointer:
>>>> 
>>>> p_c_str.set(c_str);
>>>> 
>>>> You can now pass p_c_str to your function.
>>>> 
>>>> Is this what you wanted to do?
>>> 
>>> And, I think here what bugs you is the need to allocate the outer pointer - you want something akin to C's & operator.
>>> 

Uh, now I know what you really asking for, you can ignore my previous email. :)

>>> I made a proposal few months ago - which I've been able to find :-)
>>> 
>>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-February/004629.html 
>>> 
>>> Didn't get much traction back then - but maybe we should revisit?
>> 
>> For the records, the proposal didn't go ahead as a result of an accidentally private discussion between me and Jorn. The conclusion can be summarized as follows:
>> 
>> For Pointer, Arrays and Callback, it is hard to add an addressOf method because you need to allocate (so you need to take a scope) - e.g. to do something akin to what I showed you in the other email.
>> 
>> Structs has already an addressof (called ptr), so, not much to gain there (other than the renaming)
>> 
>> Which basically left us with the feeling that there's not much that can be improved.
> 
> FWIW, Array also has a ptr() method nowadays that returns a Pointer<Array<X>>.
> 

Now you mention this, it makes me feel that carrier type maybe a little misleading?

Note that the function is to have a Pointer with correct layout of an array, not as the element type.

But it?s still the same address, not really have the same meaning as Pointer<Pointer<X>>.

Cheers,
Henry


> Struct and Array are pretty easy to add such a method to, since they are implemented as a pointer to a block of memory that holds their value already. Pointer on the other hand stores it's value directly in a Java `long`. It is not really possible to return a 'stable' Pointer to that `long`; e.g. the Pointer object that holds the `long` might reside on the GC heap, and be moved from time to time, invalidating any Pointer that points to it. Even objects located on the stack are not guaranteed to be in the same place all the time (think of Loom's continuations).
> 
> So, you'd need to put this value in a stable place, e.g. off-heap. But, this also means that any pointer to the 'stable' value is not actually a Pointer to the Pointer you already had, but rather to a copy of it. i.e. Updating the value through this new Pointer will not affect the value of the original.
> 
> Maybe there is another way to get around these problems, but making things explicit in the written code also has it's merits, since you can _see_ what's going on, and don't have to memorize several corner cases in which things happen differently than you would expect.
> 
> Jorn
> 
>> 
>> Maurizio
>> 
>> 
>>> 
>>> Maurizio
>>> 
>>>> 
>>>> Maurizio
>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Maurizio
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Maurizio
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Cheers
>>>>>>>>>> Maurizio
>>>>>>>>>> 
>>>>>>>>>> On 19/08/2019 10:33, sundararajan.athijegannathan at oracle.com wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> All that said, how close is Panama? Is this foreign memory API going to stay going forward or will the project take a major shift? I'd *really* like to start putting this to use and am willing to make adjustment where needed if minor changes are made, but if the entire foreign API is scrapped it isn't worth it.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Panama "memory access" ("memaccess" panama-dev branch) API is expected to become stable first and then other parts of java.foreign later ("foreign" branch stuff). 


From maurizio.cimadamore at oracle.com  Mon Sep  2 15:27:11 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 2 Sep 2019 16:27:11 +0100
Subject: [foreign-memaccess] RFR 8230449: Simplify creation of handles for
 memory slices
Message-ID: <edbb5cd0-7f4f-3d22-7c09-90db0ffb88f2@oracle.com>

Hi,
the foreign memory API is pretty good at expressing access to 
multi-dimensional data, e.g. by allowing to define custom strides and 
offsets. There are however some limitations that limit the 
expressiveness of the API when it comes to denote complex 
VarHandle-based views of contiguous chunks of memory:

1) It is not possible to use negative strides (which makes it impossible 
e.g. to create a VarHandle which returns the contents of the memory 
region "in reverse order")
2) there's no way in the PathElement API to select a 'slice' of a 
sequence layout (e.g. from start given start index, with given step)

The following webrev aims at closing this gap:

http://cr.openjdk.java.net/~mcimadamore/panama/8230449/

P.S.
To allow negative strides I had to remove a validation of the stride in 
the combinator API which ensured that the stride was greater than the 
offset + carrierSize. I believe this restriction to be a tad obscure and 
not a fundamental one (this was also pointed out by Jorn when I added 
the restriction in the first place), so I'm ok to drop it in name for 
more expressiveness.

Maurizio


From nick.gasson at arm.com  Tue Sep  3 08:29:57 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Tue, 3 Sep 2019 16:29:57 +0800
Subject: [foreign+linkToNative] RFR: 8230202: Fix failure of
 foreign/pthread/Threads.java with linkToNative
In-Reply-To: <fbc8ad3e-c04e-e131-0958-cbd594aeaffa@oracle.com>
References: <1acdf331-0b47-51ce-9e53-6c212d222cbc@arm.com>
 <fbc8ad3e-c04e-e131-0958-cbd594aeaffa@oracle.com>
Message-ID: <a0f620eb-7227-6ea9-73b1-fe2987e0debe@arm.com>

Thanks Jorn. Just checking this is ok to push now?

Nick


On 27/08/2019 22:32, Jorn Vernee wrote:
> Hi Nick,
> 
> The patch looks good to me.
> 
>   > I'm wondering what the status of linkToNative is at that the moment?
> Is there a list of missing features/bugs that need to be fixed before it
> can replace the JNI-based fastpath?
> 
> Sorry for the radio silence w.r.t. linkToNative. Maurizio is currently
> away, and we have not really had a chance to discuss the plan going
> forward. I have my own ideas, but I'd like to wait until he gets back
> before starting the discussion (since he's the Architect).
> 
> Cheers,
> Jorn
> 
> On 27/08/2019 09:15, Nick Gasson wrote:
>> Hi,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230202
>> Webrev: http://cr.openjdk.java.net/~ngasson/foreign/8230202/webrev.0/
>>
>> This patch applies the fix for 8226250 (callback from native threads) to
>> linkToNative.
>>
>> In the upcall stub `__ get_thread(...)' calls Thread::current() but that
>> assumes the calling thread is already attached to the VM. Moved the
>> existing logic to handle attaching to the VM as a daemon in this case
>> out of the four upcall implementations into a static method in
>> UniversalUpcallHandler. We can then call this from the linkToNative
>> upcall stub.
>>
>> Also fixed a potential race in Threads.java between the native thread
>> starting and the VM exiting after main() returns.
>>
>> The new calls to in_bytes() are unrelated: just fixing the debug build.
>>
>> -- 
>>
>> I'm wondering what the status of linkToNative is at that the moment?
>> Is there a list of missing features/bugs that need to be fixed before
>> it can replace the JNI-based fastpath?
>>
>> Thanks,
>> Nick

From jorn.vernee at oracle.com  Tue Sep  3 09:37:10 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 3 Sep 2019 11:37:10 +0200
Subject: [foreign+linkToNative] RFR: 8230202: Fix failure of
 foreign/pthread/Threads.java with linkToNative
In-Reply-To: <a0f620eb-7227-6ea9-73b1-fe2987e0debe@arm.com>
References: <1acdf331-0b47-51ce-9e53-6c212d222cbc@arm.com>
 <fbc8ad3e-c04e-e131-0958-cbd594aeaffa@oracle.com>
 <a0f620eb-7227-6ea9-73b1-fe2987e0debe@arm.com>
Message-ID: <51edd706-6164-b8ac-c48d-ea03d0b1ce22@oracle.com>

Yes, this can be pushed.

Jorn

On 03/09/2019 10:29, Nick Gasson wrote:
> Thanks Jorn. Just checking this is ok to push now?
>
> Nick
>
>
> On 27/08/2019 22:32, Jorn Vernee wrote:
>> Hi Nick,
>>
>> The patch looks good to me.
>>
>> ? > I'm wondering what the status of linkToNative is at that the moment?
>> Is there a list of missing features/bugs that need to be fixed before it
>> can replace the JNI-based fastpath?
>>
>> Sorry for the radio silence w.r.t. linkToNative. Maurizio is currently
>> away, and we have not really had a chance to discuss the plan going
>> forward. I have my own ideas, but I'd like to wait until he gets back
>> before starting the discussion (since he's the Architect).
>>
>> Cheers,
>> Jorn
>>
>> On 27/08/2019 09:15, Nick Gasson wrote:
>>> Hi,
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8230202
>>> Webrev: http://cr.openjdk.java.net/~ngasson/foreign/8230202/webrev.0/
>>>
>>> This patch applies the fix for 8226250 (callback from native 
>>> threads) to
>>> linkToNative.
>>>
>>> In the upcall stub `__ get_thread(...)' calls Thread::current() but 
>>> that
>>> assumes the calling thread is already attached to the VM. Moved the
>>> existing logic to handle attaching to the VM as a daemon in this case
>>> out of the four upcall implementations into a static method in
>>> UniversalUpcallHandler. We can then call this from the linkToNative
>>> upcall stub.
>>>
>>> Also fixed a potential race in Threads.java between the native thread
>>> starting and the VM exiting after main() returns.
>>>
>>> The new calls to in_bytes() are unrelated: just fixing the debug build.
>>>
>>> -- 
>>>
>>> I'm wondering what the status of linkToNative is at that the moment?
>>> Is there a list of missing features/bugs that need to be fixed before
>>> it can replace the JNI-based fastpath?
>>>
>>> Thanks,
>>> Nick

From ningsheng.jian at arm.com  Tue Sep  3 10:07:55 2019
From: ningsheng.jian at arm.com (ningsheng.jian at arm.com)
Date: Tue, 03 Sep 2019 10:07:55 +0000
Subject: hg: panama/dev: 8230202: Fix failure of foreign/pthread/Threads.java
 with linkToNative
Message-ID: <201909031007.x83A7uuB004899@aojmv0008.oracle.com>

Changeset: 8b6903d6061a
Author:    ngasson
Date:      2019-09-03 18:06 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/8b6903d6061a

8230202: Fix failure of foreign/pthread/Threads.java with linkToNative
Reviewed-by: jvernee

! src/hotspot/cpu/aarch64/directUpcallHandler_aarch64.cpp
! src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp
! src/hotspot/cpu/x86/directUpcallHandler_x86.cpp
! src/hotspot/cpu/x86/universalUpcallHandler_x86.cpp
! src/hotspot/share/prims/universalUpcallHandler.cpp
! src/hotspot/share/prims/universalUpcallHandler.hpp
! test/jdk/java/foreign/pthread/Threads.java


From mark.hammons at inaf.cnrs-gif.fr  Tue Sep  3 10:15:38 2019
From: mark.hammons at inaf.cnrs-gif.fr (Mark Hammons)
Date: Tue, 3 Sep 2019 12:15:38 +0200
Subject: Maybe have jextract output binding information instead of binding
 code via a command-line flag?
Message-ID: <ae789508-1d7a-781c-7c58-8c67aba33415@inaf.cnrs-gif.fr>

Hi All,

I've been thinking about this since before when I was creating scala 
bindings to a native library using panama's foreign interface. Would it 
be possible for jextract to generate a set of binding information (not 
classfiles or a jar, but a text, xml, or json file) that could be parsed 
by languages like scala/clojure/etc, and used to generate their own 
bindings? There are some concepts in scala 3 I would like to combine 
with panama's foreign interface, but doing so requires manually writing 
the bindings. With a textual representation of the library info 
generated by jextract, I might be able to write some scala macros that 
produce scala 3 bindings using panama's foreign interface.

~Mark


From maurizio.cimadamore at oracle.com  Tue Sep  3 10:30:43 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 3 Sep 2019 11:30:43 +0100
Subject: Maybe have jextract output binding information instead of binding
 code via a command-line flag?
In-Reply-To: <ae789508-1d7a-781c-7c58-8c67aba33415@inaf.cnrs-gif.fr>
References: <ae789508-1d7a-781c-7c58-8c67aba33415@inaf.cnrs-gif.fr>
Message-ID: <f9e5182d-4683-f86d-1879-eb270a2d3795@oracle.com>


On 03/09/2019 11:15, Mark Hammons wrote:
> Hi All,
>
> I've been thinking about this since before when I was creating scala 
> bindings to a native library using panama's foreign interface. Would 
> it be possible for jextract to generate a set of binding information 
> (not classfiles or a jar, but a text, xml, or json file) that could be 
> parsed by languages like scala/clojure/etc, and used to generate their 
> own bindings? There are some concepts in scala 3 I would like to 
> combine with panama's foreign interface, but doing so requires 
> manually writing the bindings. With a textual representation of the 
> library info generated by jextract, I might be able to write some 
> scala macros that produce scala 3 bindings using panama's foreign 
> interface.

Short answer: yes and no (with a final twist) :-)

Full answer (which you might like or might not like): we are currently 
in a state where jextract is a relatively simple tool - you pass it an 
header, some options and it will spit a jarfile with some classes. That 
said, we have started to see some cracks in the ceilings - for instance 
the amount of options required for filtering headers seem to never be 
enough, some people would prefer jextract to output jmod, rather than 
jars - or something else (like in your case); lastly, some things that 
jextract needs to do require user intervention (e.g. function-like 
macros, C++ templates, civilization of bindings - such as exposing a 
Pointer<Byte> as a plain String).

All this seem to point to a model where the jextract tool is more 
open-ended, and allows users to inspect the internal representation it 
has with respect to the parsed C/C++ headers and, if they wish to do so, 
build plugins which tell jextract to do additional tasks, such as emit 
additional headers, or generate non-custom output on the side.

While we're not 100% sure of what the extension points will be - and how 
the user will be able to interact with them, all I can say at this point 
is that we're thinking about this, and see how this story would fit in 
the Panama picture.

In the interim (here's the twist), Sundar reminds me that there's an 
option in jextract which allows jextract to dump the generated sources 
"--src-dump-dir". With this and some parsing magic you might be able to 
derive the representation you want?

Cheers
Maurizio

>
> ~Mark
>

From jorn.vernee at oracle.com  Tue Sep  3 14:25:03 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 3 Sep 2019 16:25:03 +0200
Subject: [foreign-memaccess] RFR 8230449: Simplify creation of handles for
 memory slices
In-Reply-To: <edbb5cd0-7f4f-3d22-7c09-90db0ffb88f2@oracle.com>
References: <edbb5cd0-7f4f-3d22-7c09-90db0ffb88f2@oracle.com>
Message-ID: <0a78cab0-2352-3f6d-9e29-db0c95aa03e3@oracle.com>

Hi,

Some comments:
- MemoryLayout.java; The javadoc should be updated from "if the step 
factor is &lt; 0" -> "is 0", since it can also be negative.
- LayoutPathImpl.java; Could use a helper method to do the sequence 
index check (code is duplicated between 2 `sequenceElement` methods). 
Also, the `step == 0` check is done in the PathElement::sequenceElement 
already. Lastly, I'm not so sure about the last check for invalid step 
factor. It would still be valid to access a single element when the 
coordinate passed to the VH is 0, but this check blocks that.

Rest looks good.

Cheers,
Jorn

On 02/09/2019 17:27, Maurizio Cimadamore wrote:
> Hi,
> the foreign memory API is pretty good at expressing access to 
> multi-dimensional data, e.g. by allowing to define custom strides and 
> offsets. There are however some limitations that limit the 
> expressiveness of the API when it comes to denote complex 
> VarHandle-based views of contiguous chunks of memory:
>
> 1) It is not possible to use negative strides (which makes it 
> impossible e.g. to create a VarHandle which returns the contents of 
> the memory region "in reverse order")
> 2) there's no way in the PathElement API to select a 'slice' of a 
> sequence layout (e.g. from start given start index, with given step)
>
> The following webrev aims at closing this gap:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8230449/
>
> P.S.
> To allow negative strides I had to remove a validation of the stride 
> in the combinator API which ensured that the stride was greater than 
> the offset + carrierSize. I believe this restriction to be a tad 
> obscure and not a fundamental one (this was also pointed out by Jorn 
> when I added the restriction in the first place), so I'm ok to drop it 
> in name for more expressiveness.
>
> Maurizio
>

From maurizio.cimadamore at oracle.com  Tue Sep  3 14:55:00 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 3 Sep 2019 15:55:00 +0100
Subject: [foreign-memaccess] RFR 8230449: Simplify creation of handles for
 memory slices
In-Reply-To: <0a78cab0-2352-3f6d-9e29-db0c95aa03e3@oracle.com>
References: <edbb5cd0-7f4f-3d22-7c09-90db0ffb88f2@oracle.com>
 <0a78cab0-2352-3f6d-9e29-db0c95aa03e3@oracle.com>
Message-ID: <3a23f071-c87d-4e1c-96d7-7431b45069f6@oracle.com>


On 03/09/2019 15:25, Jorn Vernee wrote:
>
> Hi,
>
> Some comments:
> - MemoryLayout.java; The javadoc should be updated from "if the step 
> factor is &lt; 0" -> "is 0", since it can also be negative.
> - LayoutPathImpl.java; Could use a helper method to do the sequence 
> index check (code is duplicated between 2 `sequenceElement` methods). 
> Also, the `step == 0` check is done in the 
> PathElement::sequenceElement already.
>
Well spotted - will fix
>
> Lastly, I'm not so sure about the last check for invalid step factor. 
> It would still be valid to access a single element when the coordinate 
> passed to the VH is 0, but this check blocks that.
>
The idea is that if you pass a step factor that is bigger than the 
selected sequence slice.

It's true that, in general, we provide no guarantee for out-of-bound 
indices in array-like VH - but I guess I saw this as a user-mistake and 
wanted to prevent it.

Now that I think more, I guess I see that, by removing that check, we 
would actually be able to produce VH which are capable of accessing 
exactly ONE element, which I guess can come in handy in certain cases.

Maurizio

> Rest looks good.
>
> Cheers,
> Jorn
>
> On 02/09/2019 17:27, Maurizio Cimadamore wrote:
>> Hi,
>> the foreign memory API is pretty good at expressing access to 
>> multi-dimensional data, e.g. by allowing to define custom strides and 
>> offsets. There are however some limitations that limit the 
>> expressiveness of the API when it comes to denote complex 
>> VarHandle-based views of contiguous chunks of memory:
>>
>> 1) It is not possible to use negative strides (which makes it 
>> impossible e.g. to create a VarHandle which returns the contents of 
>> the memory region "in reverse order")
>> 2) there's no way in the PathElement API to select a 'slice' of a 
>> sequence layout (e.g. from start given start index, with given step)
>>
>> The following webrev aims at closing this gap:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/8230449/
>>
>> P.S.
>> To allow negative strides I had to remove a validation of the stride 
>> in the combinator API which ensured that the stride was greater than 
>> the offset + carrierSize. I believe this restriction to be a tad 
>> obscure and not a fundamental one (this was also pointed out by Jorn 
>> when I added the restriction in the first place), so I'm ok to drop 
>> it in name for more expressiveness.
>>
>> Maurizio
>>

From sandhya.viswanathan at intel.com  Tue Sep  3 17:03:58 2019
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Tue, 3 Sep 2019 17:03:58 +0000
Subject: [vector] generic operand infrastructure support.
In-Reply-To: <VE1PR08MB46567F15C97881E43CFB0AEB8EBE0@VE1PR08MB4656.eurprd08.prod.outlook.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A046865@BGSMSX106.gar.corp.intel.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB8B7BA31@FMSMSX125.amr.corp.intel.com>
 <VE1PR08MB46567F15C97881E43CFB0AEB8EBE0@VE1PR08MB4656.eurprd08.prod.outlook.com>
Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB8B7C2B8@FMSMSX125.amr.corp.intel.com>

Hi Yang, Thanks a lot for your feedback. We have proposed the patch on the main line as well and would like to proceed with this technique on this branch so as to continue to make progress. I will take care of the manual merge as before.  Please feel free to adopt this if you find it useful for your architecture.

Jatin, could you please fix the issues pointed by Yang.   

Best Regards,
Sandhya


-----Original Message-----
From: Yang Zhang (Arm Technology China) [mailto:Yang.Zhang at arm.com] 
Sent: Sunday, September 01, 2019 8:45 PM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Bhateja, Jatin <jatin.bhateja at intel.com>; panama-dev at openjdk.java.net
Subject: RE: [vector] generic operand infrastructure support.

Hi Jatin, Sandhya

This patch is very generic. All the projects which are using vector instructions in backend can benefit from it. To reduce manual merge works in the future, proposing this patch to jdk/jdk master would be better.

I test this patch in our internal ci test framework. In x86 platform, build fails. The post-selection pass is missed. The error log is as follows:
src/hotspot/share/opto/compile.cpp:2945: undefined reference to `Matcher::do_post_selection_processing(Compile*, Node*)'
Besides that, there are also some trailing spaces and blank lines.

Regards
Yang

-----Original Message-----
From: panama-dev <panama-dev-bounces at openjdk.java.net> On Behalf Of Viswanathan, Sandhya
Sent: Saturday, August 31, 2019 6:08 AM
To: Bhateja, Jatin <jatin.bhateja at intel.com>; panama-dev at openjdk.java.net
Subject: RE: [vector] generic operand infrastructure support.

Hi Jatin,

The patch looks good to me.

Best Regards,
Sandhya


From: Bhateja, Jatin
Sent: Friday, August 30, 2019 5:07 AM
To: panama-dev at openjdk.java.net
Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
Subject: [vector] generic operand infrastructure support.

Hi All,

We have been working over reducing the AD file and libjvm.so size by reducing the number of vector instruction patterns whose operands differ meagerly in vector lengths.
As of now we have several vector operand for X86 target like vecS , vecD, vecX , vecY, vecZ and their legacy variants. This patch adds an infrastructure to support generic operands[1]  and a post-selection pass to remove them from machine graph so that there is minimal impact on the downstream passes.

Complete patch using generic operands which reduces the number of vector patterns from 510 to 222 is already posted over mainline https://mail.openjdk.java.net/piperail/hotspot-compiler-dev/2019-August/034822.html

Since vectorIntrinsics branch has bulk of the vector instruction patterns hence we plan to introduce the support in stages.

Following patch contains the infrastructure changes for generic operands, using it we can collapse the different vector length instructions for same operation without making any changes in the ideal graph.
CR : http://cr.openjdk.java.net/~jbhateja/vectorIntrinsics/GEN_OPERS/webrev.00/
Common JBS for jdk/mainline and panama/vectorIntrinsics : https://bugs.openjdk.java.net/browse/JDK-8230015

Kindly review it provide your feedback.

Best Regards,
Jatin Bhateja

PS : All the changes are currently enabled only for X86 target.
[1]  http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

From maurizio.cimadamore at oracle.com  Tue Sep  3 18:16:35 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 3 Sep 2019 19:16:35 +0100
Subject: [foreign-memaccess] RFR 8230449: Simplify creation of handles for
 memory slices
In-Reply-To: <3a23f071-c87d-4e1c-96d7-7431b45069f6@oracle.com>
References: <edbb5cd0-7f4f-3d22-7c09-90db0ffb88f2@oracle.com>
 <0a78cab0-2352-3f6d-9e29-db0c95aa03e3@oracle.com>
 <3a23f071-c87d-4e1c-96d7-7431b45069f6@oracle.com>
Message-ID: <dc9be7d6-1824-e6aa-f613-5c28e0fc72fc@oracle.com>

New webrev:

http://cr.openjdk.java.net/~mcimadamore/panama/8230449_v2/

Cheers
Maurizio

On 03/09/2019 15:55, Maurizio Cimadamore wrote:
>
> On 03/09/2019 15:25, Jorn Vernee wrote:
>>
>> Hi,
>>
>> Some comments:
>> - MemoryLayout.java; The javadoc should be updated from "if the step 
>> factor is &lt; 0" -> "is 0", since it can also be negative.
>> - LayoutPathImpl.java; Could use a helper method to do the sequence 
>> index check (code is duplicated between 2 `sequenceElement` methods). 
>> Also, the `step == 0` check is done in the 
>> PathElement::sequenceElement already.
>>
> Well spotted - will fix
>>
>> Lastly, I'm not so sure about the last check for invalid step factor. 
>> It would still be valid to access a single element when the 
>> coordinate passed to the VH is 0, but this check blocks that.
>>
> The idea is that if you pass a step factor that is bigger than the 
> selected sequence slice.
>
> It's true that, in general, we provide no guarantee for out-of-bound 
> indices in array-like VH - but I guess I saw this as a user-mistake 
> and wanted to prevent it.
>
> Now that I think more, I guess I see that, by removing that check, we 
> would actually be able to produce VH which are capable of accessing 
> exactly ONE element, which I guess can come in handy in certain cases.
>
> Maurizio
>
>> Rest looks good.
>>
>> Cheers,
>> Jorn
>>
>> On 02/09/2019 17:27, Maurizio Cimadamore wrote:
>>> Hi,
>>> the foreign memory API is pretty good at expressing access to 
>>> multi-dimensional data, e.g. by allowing to define custom strides 
>>> and offsets. There are however some limitations that limit the 
>>> expressiveness of the API when it comes to denote complex 
>>> VarHandle-based views of contiguous chunks of memory:
>>>
>>> 1) It is not possible to use negative strides (which makes it 
>>> impossible e.g. to create a VarHandle which returns the contents of 
>>> the memory region "in reverse order")
>>> 2) there's no way in the PathElement API to select a 'slice' of a 
>>> sequence layout (e.g. from start given start index, with given step)
>>>
>>> The following webrev aims at closing this gap:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/panama/8230449/
>>>
>>> P.S.
>>> To allow negative strides I had to remove a validation of the stride 
>>> in the combinator API which ensured that the stride was greater than 
>>> the offset + carrierSize. I believe this restriction to be a tad 
>>> obscure and not a fundamental one (this was also pointed out by Jorn 
>>> when I added the restriction in the first place), so I'm ok to drop 
>>> it in name for more expressiveness.
>>>
>>> Maurizio
>>>

From jbvernee at xs4all.nl  Wed Sep  4 07:46:45 2019
From: jbvernee at xs4all.nl (Jorn Vernee)
Date: Wed, 4 Sep 2019 09:46:45 +0200
Subject: [foreign-memaccess] RFR 8230449: Simplify creation of handles for
 memory slices
In-Reply-To: <dc9be7d6-1824-e6aa-f613-5c28e0fc72fc@oracle.com>
References: <edbb5cd0-7f4f-3d22-7c09-90db0ffb88f2@oracle.com>
 <0a78cab0-2352-3f6d-9e29-db0c95aa03e3@oracle.com>
 <3a23f071-c87d-4e1c-96d7-7431b45069f6@oracle.com>
 <dc9be7d6-1824-e6aa-f613-5c28e0fc72fc@oracle.com>
Message-ID: <40b913c3-27bd-a752-54dc-6d19de199c94@xs4all.nl>

Looks good!

Cheers,
Jorn

On 03/09/2019 20:16, Maurizio Cimadamore wrote:

> New webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8230449_v2/
>
> Cheers
> Maurizio
>
> On 03/09/2019 15:55, Maurizio Cimadamore wrote:
>>
>> On 03/09/2019 15:25, Jorn Vernee wrote:
>>>
>>> Hi,
>>>
>>> Some comments:
>>> - MemoryLayout.java; The javadoc should be updated from "if the step 
>>> factor is &lt; 0" -> "is 0", since it can also be negative.
>>> - LayoutPathImpl.java; Could use a helper method to do the sequence 
>>> index check (code is duplicated between 2 `sequenceElement` 
>>> methods). Also, the `step == 0` check is done in the 
>>> PathElement::sequenceElement already.
>>>
>> Well spotted - will fix
>>>
>>> Lastly, I'm not so sure about the last check for invalid step 
>>> factor. It would still be valid to access a single element when the 
>>> coordinate passed to the VH is 0, but this check blocks that.
>>>
>> The idea is that if you pass a step factor that is bigger than the 
>> selected sequence slice.
>>
>> It's true that, in general, we provide no guarantee for out-of-bound 
>> indices in array-like VH - but I guess I saw this as a user-mistake 
>> and wanted to prevent it.
>>
>> Now that I think more, I guess I see that, by removing that check, we 
>> would actually be able to produce VH which are capable of accessing 
>> exactly ONE element, which I guess can come in handy in certain cases.
>>
>> Maurizio
>>
>>> Rest looks good.
>>>
>>> Cheers,
>>> Jorn
>>>
>>> On 02/09/2019 17:27, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> the foreign memory API is pretty good at expressing access to 
>>>> multi-dimensional data, e.g. by allowing to define custom strides 
>>>> and offsets. There are however some limitations that limit the 
>>>> expressiveness of the API when it comes to denote complex 
>>>> VarHandle-based views of contiguous chunks of memory:
>>>>
>>>> 1) It is not possible to use negative strides (which makes it 
>>>> impossible e.g. to create a VarHandle which returns the contents of 
>>>> the memory region "in reverse order")
>>>> 2) there's no way in the PathElement API to select a 'slice' of a 
>>>> sequence layout (e.g. from start given start index, with given step)
>>>>
>>>> The following webrev aims at closing this gap:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/panama/8230449/
>>>>
>>>> P.S.
>>>> To allow negative strides I had to remove a validation of the 
>>>> stride in the combinator API which ensured that the stride was 
>>>> greater than the offset + carrierSize. I believe this restriction 
>>>> to be a tad obscure and not a fundamental one (this was also 
>>>> pointed out by Jorn when I added the restriction in the first 
>>>> place), so I'm ok to drop it in name for more expressiveness.
>>>>
>>>> Maurizio
>>>>

From maurizio.cimadamore at oracle.com  Wed Sep  4 10:41:45 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 04 Sep 2019 10:41:45 +0000
Subject: hg: panama/dev: 8230449: Simplify creation of handles for memory
 slices
Message-ID: <201909041041.x84AfjPS025632@aojmv0008.oracle.com>

Changeset: 1c3022e67594
Author:    mcimadamore
Date:      2019-09-04 11:41 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/1c3022e67594

8230449: Simplify creation of handles for memory slices
Reviewed-by: jvernee

! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryHandles.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LayoutPathImpl.java
! test/jdk/java/foreign/TestLayoutPaths.java
+ test/jdk/java/foreign/TestSlices.java
! test/jdk/java/foreign/TestVarHandleCombinators.java


From maurizio.cimadamore at oracle.com  Wed Sep  4 10:45:14 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 04 Sep 2019 10:45:14 +0000
Subject: hg: panama/dev: Automatic merge with foreign-memaccess
Message-ID: <201909041045.x84AjEZa026872@aojmv0008.oracle.com>

Changeset: 9f640c164fdf
Author:    mcimadamore
Date:      2019-09-04 10:45 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/9f640c164fdf

Automatic merge with foreign-memaccess

! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java


From Yang.Zhang at arm.com  Thu Sep  5 08:28:58 2019
From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China))
Date: Thu, 5 Sep 2019 08:28:58 +0000
Subject: [vector] Update jtreg test cases to make sure that C2 is used
Message-ID: <VE1PR08MB4656FD3F2AB50370266030698EBB0@VE1PR08MB4656.eurprd08.prod.outlook.com>

Hi all

Could anyone please help to review this patch?

Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.jtreg/webrev.00/

In this patch, -Xbatch option is added in jtreg test cases to make sure that C2 is used. Without this option, many test cases are compiled in C1 compiler. 

Regards,
Yang

From maurizio.cimadamore at oracle.com  Thu Sep  5 17:10:20 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 05 Sep 2019 17:10:20 +0000
Subject: hg: panama/dev: manual merge with linkToNative
Message-ID: <201909051710.x85HAK6J001231@aojmv0008.oracle.com>

Changeset: 9bc8510bb19c
Author:    mcimadamore
Date:      2019-09-04 13:10 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/9bc8510bb19c

manual merge with linkToNative

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java


From sandhya.viswanathan at intel.com  Thu Sep  5 21:33:47 2019
From: sandhya.viswanathan at intel.com (sandhya.viswanathan at intel.com)
Date: Thu, 05 Sep 2019 21:33:47 +0000
Subject: hg: panama/dev: manual merge with vectorIntrinsics
Message-ID: <201909052133.x85LXmnc010109@aojmv0008.oracle.com>

Changeset: 33f3eb9006ed
Author:    sviswanathan
Date:      2019-09-05 14:30 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/33f3eb9006ed

manual merge with vectorIntrinsics

- make/CreateBuildJdkCopy.gmk
- make/data/cldr/common/main/ff_CM.xml
- make/data/cldr/common/main/ff_GN.xml
- make/data/cldr/common/main/ff_MR.xml
- make/data/cldr/common/main/ff_SN.xml
- make/data/cldr/common/main/yue_HK.xml
- make/data/cldr/common/supplemental/telephoneCodeData.xml
- make/jdk/src/classes/build/tools/tzdb/ZoneRules.java
- src/hotspot/cpu/aarch64/aarch64_call.cpp
- src/hotspot/cpu/aarch64/aarch64_linkage.S
- src/hotspot/cpu/aarch64/cpustate_aarch64.hpp
- src/hotspot/cpu/aarch64/decode_aarch64.hpp
- src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetC1_aarch64.cpp
- src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetC1_x86.cpp
- src/hotspot/os_cpu/linux_aarch64/linux_aarch64.S
- src/hotspot/os_cpu/linux_x86/gc/z/zAddress_linux_x86.inline.hpp
- src/hotspot/share/Xusage.txt
- src/hotspot/share/c1/c1_globals.cpp
- src/hotspot/share/gc/cms/cmsCollectorPolicy.cpp
- src/hotspot/share/gc/cms/cmsCollectorPolicy.hpp
- src/hotspot/share/gc/epsilon/epsilonCollectorPolicy.hpp
- src/hotspot/share/gc/g1/g1CollectorPolicy.cpp
- src/hotspot/share/gc/g1/g1CollectorPolicy.hpp
- src/hotspot/share/gc/g1/g1HeterogeneousCollectorPolicy.cpp
- src/hotspot/share/gc/g1/g1HeterogeneousCollectorPolicy.hpp
- src/hotspot/share/gc/g1/g1InCSetState.hpp
- src/hotspot/share/gc/parallel/generationSizer.cpp
- src/hotspot/share/gc/parallel/generationSizer.hpp
- src/hotspot/share/gc/parallel/heterogeneousGenerationSizer.cpp
- src/hotspot/share/gc/parallel/heterogeneousGenerationSizer.hpp
- src/hotspot/share/gc/shared/collectorPolicy.cpp
- src/hotspot/share/gc/shared/collectorPolicy.hpp
- src/hotspot/share/gc/shared/gcArguments.inline.hpp
- src/hotspot/share/gc/shenandoah/shenandoahBrooksPointer.hpp
- src/hotspot/share/gc/shenandoah/shenandoahBrooksPointer.inline.hpp
- src/hotspot/share/gc/shenandoah/shenandoahHeapLock.hpp
- src/hotspot/share/gc/z/zCollectorPolicy.cpp
- src/hotspot/share/gc/z/zCollectorPolicy.hpp
- src/hotspot/share/gc/z/zOopClosures.cpp
- src/hotspot/share/gc/z/zPreMappedMemory.cpp
- src/hotspot/share/gc/z/zPreMappedMemory.hpp
- src/hotspot/share/gc/z/zPreMappedMemory.inline.hpp
- src/hotspot/share/jfr/leakprofiler/emitEventOperation.cpp
- src/hotspot/share/jfr/leakprofiler/emitEventOperation.hpp
- src/hotspot/share/jvmci/systemDictionary_jvmci.hpp
- src/hotspot/share/opto/c2_globals.cpp
- src/java.base/share/classes/java/security/acl/Acl.java
- src/java.base/share/classes/java/security/acl/AclEntry.java
- src/java.base/share/classes/java/security/acl/AclNotFoundException.java
- src/java.base/share/classes/java/security/acl/Group.java
- src/java.base/share/classes/java/security/acl/LastOwnerException.java
- src/java.base/share/classes/java/security/acl/NotOwnerException.java
- src/java.base/share/classes/java/security/acl/Owner.java
- src/java.base/share/classes/java/security/acl/Permission.java
- src/java.base/share/classes/java/security/acl/package-info.java
- src/java.base/share/classes/jdk/internal/access/JavaNetSocketAccess.java
- src/java.base/share/classes/jdk/internal/access/JavaNetURLClassLoaderAccess.java
- src/java.base/share/classes/jdk/internal/reflect/LangReflectAccess.java
- src/java.base/share/classes/sun/text/resources/nfc.icu
- src/java.base/share/classes/sun/text/resources/nfkc.icu
- src/java.base/share/classes/sun/text/resources/nfkc_cf.icu
- src/java.base/share/lib/security/cacerts
- src/java.desktop/share/native/libfreetype/include/freetype/internal/ftpic.h
- src/java.desktop/share/native/libfreetype/src/autofit/afpic.c
- src/java.desktop/share/native/libfreetype/src/autofit/afpic.h
- src/java.desktop/share/native/libfreetype/src/base/basepic.c
- src/java.desktop/share/native/libfreetype/src/base/basepic.h
- src/java.desktop/share/native/libfreetype/src/base/ftapi.c
- src/java.desktop/share/native/libfreetype/src/base/ftpic.c
- src/java.desktop/share/native/libfreetype/src/base/md5.c
- src/java.desktop/share/native/libfreetype/src/base/md5.h
- src/java.desktop/share/native/libfreetype/src/cff/cffpic.c
- src/java.desktop/share/native/libfreetype/src/cff/cffpic.h
- src/java.desktop/share/native/libfreetype/src/pshinter/pshpic.c
- src/java.desktop/share/native/libfreetype/src/pshinter/pshpic.h
- src/java.desktop/share/native/libfreetype/src/psnames/pspic.c
- src/java.desktop/share/native/libfreetype/src/psnames/pspic.h
- src/java.desktop/share/native/libfreetype/src/raster/rastpic.c
- src/java.desktop/share/native/libfreetype/src/raster/rastpic.h
- src/java.desktop/share/native/libfreetype/src/sfnt/sfntpic.c
- src/java.desktop/share/native/libfreetype/src/sfnt/sfntpic.h
- src/java.desktop/share/native/libfreetype/src/smooth/ftspic.c
- src/java.desktop/share/native/libfreetype/src/smooth/ftspic.h
- src/java.desktop/share/native/libfreetype/src/truetype/ttpic.c
- src/java.desktop/share/native/libfreetype/src/truetype/ttpic.h
- src/java.desktop/unix/native/libawt_xawt/awt/awt_AWTEvent.h
- src/java.desktop/unix/native/libawt_xawt/awt/awt_Event.h
- src/java.desktop/unix/native/libawt_xawt/awt/awt_Insets.h
- src/java.desktop/unix/native/libawt_xawt/awt/multi_font.c
- src/java.desktop/unix/native/libawt_xawt/awt/multi_font.h
- src/java.desktop/windows/native/libawt/windows/awt_Color.h
- src/java.desktop/windows/native/libawt/windows/awt_Rectangle.h
- src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC
- src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java
- src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs-11v2-20a3.h
- src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPhysicalMemoryManager.java
- src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIMetaAccessContext.java
- src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/MetaspaceWrapperObject.java
- src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/.checkstyle_checks.xml
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/UnsafeAccess.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeAccess.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GuardedIntrinsicTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/UnsafeAccess.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/WriteBarrierVerificationTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/NodeCostDumpUtil.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/g1/G1ArrayRangePostWriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/g1/G1ArrayRangePreWriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/g1/G1BarrierSet.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/g1/G1PostWriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/g1/G1PreWriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/g1/G1ReferentFieldReadBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/shared/ArrayRangeWriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/shared/BarrierSet.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/shared/CardTableBarrierSet.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/shared/ObjectWriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/shared/SerialArrayRangeWriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/gc/shared/SerialWriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/WriteBarrier.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/WriteBarrierAdditionPhase.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/WriteBarrierVerificationPhase.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/WriteBarrierSnippets.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/tiers/PhaseContext.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64IntegerSubstitutions.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64LongSubstitutions.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/Log.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/UnsafeAccess.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyWithSlowPathNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/DirectStoreNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/UnsafeAccess.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesFrameWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageFrameWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/external/jquery/jquery.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_55_fbf9ee_1x400.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_65_dadada_1x400.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_dadada_1x400.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_e6e6e6_1x400.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_95_fef1ec_1x400.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_highlight-soft_75_cccccc_1x100.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_222222_256x240.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_2e83ff_256x240.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_454545_256x240.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_888888_256x240.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_cd0a0a_256x240.png
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.3.1.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-migrate-3.0.1.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.css
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.css
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.css
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.min.css
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.min.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.min.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.js
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.min.js
- src/jdk.javadoc/share/legal/jquery-migrate.md
- src/jdk.javadoc/share/legal/pako.md
- src/jdk.jsobject/share/classes/jdk/internal/netscape/javascript/spi/JSObjectProvider.java
- test/fmw/gtest/CHANGES
- test/fmw/gtest/LICENSE
- test/fmw/gtest/README
- test/fmw/gtest/include/gtest/gtest-death-test.h
- test/fmw/gtest/include/gtest/gtest-message.h
- test/fmw/gtest/include/gtest/gtest-param-test.h
- test/fmw/gtest/include/gtest/gtest-param-test.h.pump
- test/fmw/gtest/include/gtest/gtest-printers.h
- test/fmw/gtest/include/gtest/gtest-spi.h
- test/fmw/gtest/include/gtest/gtest-test-part.h
- test/fmw/gtest/include/gtest/gtest-typed-test.h
- test/fmw/gtest/include/gtest/gtest.h
- test/fmw/gtest/include/gtest/gtest_pred_impl.h
- test/fmw/gtest/include/gtest/gtest_prod.h
- test/fmw/gtest/include/gtest/internal/gtest-death-test-internal.h
- test/fmw/gtest/include/gtest/internal/gtest-filepath.h
- test/fmw/gtest/include/gtest/internal/gtest-internal.h
- test/fmw/gtest/include/gtest/internal/gtest-linked_ptr.h
- test/fmw/gtest/include/gtest/internal/gtest-param-util-generated.h
- test/fmw/gtest/include/gtest/internal/gtest-param-util-generated.h.pump
- test/fmw/gtest/include/gtest/internal/gtest-param-util.h
- test/fmw/gtest/include/gtest/internal/gtest-port.h
- test/fmw/gtest/include/gtest/internal/gtest-string.h
- test/fmw/gtest/include/gtest/internal/gtest-tuple.h
- test/fmw/gtest/include/gtest/internal/gtest-tuple.h.pump
- test/fmw/gtest/include/gtest/internal/gtest-type-util.h
- test/fmw/gtest/include/gtest/internal/gtest-type-util.h.pump
- test/fmw/gtest/src/gtest-all.cc
- test/fmw/gtest/src/gtest-death-test.cc
- test/fmw/gtest/src/gtest-filepath.cc
- test/fmw/gtest/src/gtest-internal-inl.h
- test/fmw/gtest/src/gtest-port.cc
- test/fmw/gtest/src/gtest-printers.cc
- test/fmw/gtest/src/gtest-test-part.cc
- test/fmw/gtest/src/gtest-typed-test.cc
- test/fmw/gtest/src/gtest.cc
- test/fmw/gtest/src/gtest_main.cc
- test/hotspot/jtreg/applications/ctw/modules/jdk_incubator_httpclient.java
- test/hotspot/jtreg/applications/ctw/modules/jdk_packager.java
- test/hotspot/jtreg/applications/ctw/modules/jdk_packager_services.java
- test/hotspot/jtreg/compiler/jsr292/NonInlinedCall/GCTest.java
- test/hotspot/jtreg/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java
- test/hotspot/jtreg/runtime/ErrorHandling/ExplicitArithmeticCheck.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/ArchiveDoesNotExist.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/BootAppendTests.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentCompactStrings.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsSameObjectAlignment.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CheckDefaultArchiveFile.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CheckSharingWithDefaultArchive.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSharedDictionary.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSymbolAndStringTable.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/LoadClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/MaxMetaspaceSize.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/NonBootLoaderClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedBaseAddress.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStrings.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsDedup.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsRunAuto.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsWb.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedSymbolTableBucketSize.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SpaceUtilizationCheck.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/TestInterpreterMethodEntries.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/javax/annotation/processing/FilerException.jasm
- test/hotspot/jtreg/runtime/SharedArchiveFile/javax/sound/sampled/MyClass.jasm
- test/hotspot/jtreg/runtime/SharedArchiveFile/nonjdk/myPackage/MyClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClassesForSubgraphs.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/Implementor.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/Interface.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/SubClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/SuperClazz.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TestEntry.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformInterfaceAndImplementor.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformRelatedClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformSuperAndSubClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformSuperSubTwoPckgs.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformTestCommon.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/myPkg1/SuperClazz.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/myPkg2/SubClass.java
- test/hotspot/jtreg/runtime/Thread/MonitorCacheMaybeExpand_DeadLock.java
- test/hotspot/jtreg/runtime/appcds/AppCDSOptions.java
- test/hotspot/jtreg/runtime/appcds/AppendClasspath.java
- test/hotspot/jtreg/runtime/appcds/BootClassPathMismatch.java
- test/hotspot/jtreg/runtime/appcds/CDSandJFR.java
- test/hotspot/jtreg/runtime/appcds/CaseSensitiveClassPath.java
- test/hotspot/jtreg/runtime/appcds/ClassLoaderTest.java
- test/hotspot/jtreg/runtime/appcds/ClassPathAttr.java
- test/hotspot/jtreg/runtime/appcds/CommandLineFlagCombo.java
- test/hotspot/jtreg/runtime/appcds/CommandLineFlagComboNegative.java
- test/hotspot/jtreg/runtime/appcds/CompilerUtils.java
- test/hotspot/jtreg/runtime/appcds/DirClasspathTest.java
- test/hotspot/jtreg/runtime/appcds/DumpClassList.java
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_1.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_2.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_3.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.java
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.symbols.txt
- test/hotspot/jtreg/runtime/appcds/FieldAnnotationsTest.java
- test/hotspot/jtreg/runtime/appcds/FreeUnusedMetadata.java
- test/hotspot/jtreg/runtime/appcds/GraalWithLimitedMetaspace.java
- test/hotspot/jtreg/runtime/appcds/HelloExtTest.java
- test/hotspot/jtreg/runtime/appcds/HelloTest.java
- test/hotspot/jtreg/runtime/appcds/IgnoreEmptyClassPaths.java
- test/hotspot/jtreg/runtime/appcds/JarBuilder.java
- test/hotspot/jtreg/runtime/appcds/JvmtiAddPath.java
- test/hotspot/jtreg/runtime/appcds/LongClassListPath.java
- test/hotspot/jtreg/runtime/appcds/LotsOfClasses.java
- test/hotspot/jtreg/runtime/appcds/MissingSuperTest.java
- test/hotspot/jtreg/runtime/appcds/MoveJDKTest.java
- test/hotspot/jtreg/runtime/appcds/MultiProcessSharing.java
- test/hotspot/jtreg/runtime/appcds/MultiReleaseJars.java
- test/hotspot/jtreg/runtime/appcds/OldClassTest.java
- test/hotspot/jtreg/runtime/appcds/PackageSealing.java
- test/hotspot/jtreg/runtime/appcds/ParallelLoad2.java
- test/hotspot/jtreg/runtime/appcds/ParallelLoadTest.java
- test/hotspot/jtreg/runtime/appcds/PrintSharedArchiveAndExit.java
- test/hotspot/jtreg/runtime/appcds/ProhibitedPackage.java
- test/hotspot/jtreg/runtime/appcds/ProtectionDomain.java
- test/hotspot/jtreg/runtime/appcds/RewriteBytecodesTest.java
- test/hotspot/jtreg/runtime/appcds/SharedArchiveConsistency.java
- test/hotspot/jtreg/runtime/appcds/SharedBaseAddress.java
- test/hotspot/jtreg/runtime/appcds/SharedPackages.java
- test/hotspot/jtreg/runtime/appcds/SignedJar.java
- test/hotspot/jtreg/runtime/appcds/SpecifySysLoaderProp.java
- test/hotspot/jtreg/runtime/appcds/TestCommon.java
- test/hotspot/jtreg/runtime/appcds/TestWithProfiler.java
- test/hotspot/jtreg/runtime/appcds/TraceLongClasspath.java
- test/hotspot/jtreg/runtime/appcds/UnusedCPDuringDump.java
- test/hotspot/jtreg/runtime/appcds/UseAppCDS_Test.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_0.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_1A.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_1B.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_2.java
- test/hotspot/jtreg/runtime/appcds/WideIloadTest.java
- test/hotspot/jtreg/runtime/appcds/WrongClasspath.java
- test/hotspot/jtreg/runtime/appcds/XShareAutoWithChangedJar.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedIntegerCacheTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleComboTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleCompareTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckArchivedModuleApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedMirrorApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedMirrorTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferences.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferencesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckIntegerCacheApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.config.txt
- test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStress.config.txt
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/InstrumentationAgent.mf
- test/hotspot/jtreg/runtime/appcds/cacheObject/MirrorWithReferenceFieldsApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MirrorWithReferenceFieldsTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MyException.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MyOuter.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/OpenArchiveRegion.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrimitiveTypesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrimitiveTypesTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrintSystemModulesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/src/test/jdk/test/Test.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/src/test/module-info.java
- test/hotspot/jtreg/runtime/appcds/condy/CondyHello.jasm
- test/hotspot/jtreg/runtime/appcds/condy/CondyHelloApp.java
- test/hotspot/jtreg/runtime/appcds/condy/CondyHelloTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatA.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatB.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatBase.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatC.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatD.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatE.java
- test/hotspot/jtreg/runtime/appcds/customLoader/CustomLoaderApp.java
- test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom.java
- test/hotspot/jtreg/runtime/appcds/customLoader/LoaderSegregationTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestBase.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestMultiFP.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestSingleFP.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ProhibitedPackageNamesTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ProtectionDomain.java
- test/hotspot/jtreg/runtime/appcds/customLoader/SameNameInTwoLoadersTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnintendedLoadersTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnloadUnregisteredLoaderTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnsupportedPlatforms.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomInterface2_ia.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomInterface2_ib.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee2.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee3.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee3Child.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/Hello.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/InProhibitedPkg.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/LoaderAPI.mf
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/LoaderSegregation.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/OnlyBuiltin.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/OnlyUnregistered.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/ProtDomain.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/SameNameUnrelatedLoaders.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/SimpleHello.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/UnintendedLoaders.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/UnloadUnregisteredLoader.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTest.java
- test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTestHelper.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/javaldr/GCSharedStringsDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCSharedStringsDuringDumpWb.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/jigsaw/CheckUnsupportedDumpingOptions.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/JigsawOptionsCombo.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/AppClassInCP.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/CustomPackage.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/MismatchedPatchModule.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchDir.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchJavaBase.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchMain.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/Simple.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/SubClassOfPatchedClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/TwoJars.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/BootAppendTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/com/sun/tools/javac/Main.jasm
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/com/sun/tools/javac/MyMain.jasm
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/jdk/test/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/sun/nio/cs/ext/MyClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/sun/nio/cs/ext1/MyClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddModules.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddOpens.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddReads.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ExportModule.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/JvmtiAddPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/MainModuleOnly.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.greetings/com/greetings/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.greetings/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.hello/com/hello/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.hello/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.nomodule/com/nomodule/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.norequires/com/norequires/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.norequires/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.simple/com/simple/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.simple/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/org.astro/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/org.astro/org/astro/World.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/OverrideTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/java.net.http/java/net/http/HttpTimeoutException.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/java.net.http/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/jdk.compiler/com/sun/tools/javac/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/jdk.compiler/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/test/jdk/test/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/test/module-info.java
- test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHook.java
- test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHookTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationAgent.mf
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationApp.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationClassFileTransformer.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationRegisterClassFileTransformer.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/DumpingWithJvmtiAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/SimpleAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/SimpleAgent.mf
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/libAddToSystemCLSearchOnLoad.c
- test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelClassesTransform.java
- test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelLoadAndTransformTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformInterfaceImplementorAppCDS.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformRelatedClassesAppCDS.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformSuperSubAppCDS.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasic.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_SharedHelper.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/ExerciseGC.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/ExtraSharedInput.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/FlagCombo.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloString.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloStringGC.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloStringPlus.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InternSharedString.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InternStringTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InvalidFileFormat.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LargePages.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockSharedStrings.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockStringTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockStringValueTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasicPlus.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsHumongous.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsStress.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsUtils.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWb.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWbTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/CorruptDataLine.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidDataType.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidHeader.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidString.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidStringFormat.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidSymbol.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidSymbolFormat.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidVersion.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/LengthOverflow.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/OverflowPrefix.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/TruncatedString.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/UnrecognizedPrefix.txt
- test/hotspot/jtreg/runtime/appcds/test-classes/ArrayListTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/BootClassPathAppendHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/C1.java
- test/hotspot/jtreg/runtime/appcds/test-classes/C2.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Child.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr1.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr2.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr3.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr4.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr5.java
- test/hotspot/jtreg/runtime/appcds/test-classes/DummyClassHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/EmptyClassHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/FieldAnnotationsApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ForNameTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/GetFlightRecorder.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Greet.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Hello.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExt.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExtApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExtExt.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloMore.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloWB.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Hi.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Iloadw.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/IloadwMain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JimageClassPackage.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JimageClassProtDomain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JvmtiApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MethodNoReturn.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/MissingSuper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MultiProcClass.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MyAnnotation.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MyThread.java
- test/hotspot/jtreg/runtime/appcds/test-classes/PackageSealingTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/PackageTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ParallelClasses.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ParallelLoad.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Prohibited.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/ProhibitedHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ProtDomain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ProtDomainB.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ReportMyLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/RewriteBytecodes.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Super.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TestClassLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TestWithProfilerHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TrySwitchMyLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Util.java
- test/hotspot/jtreg/runtime/appcds/test-classes/VerifierTest0.java
- test/hotspot/jtreg/runtime/appcds/test-classes/com/sun/tools/javac/Main.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr1.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr1_long.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr2.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr3.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr4.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr5_extra_long.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/java/net/HttpCookie.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/javax/transaction/InvalidTransactionException.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/package_seal.mf
- test/hotspot/jtreg/runtime/containers/cgroup/PlainRead.java
- test/hotspot/jtreg/runtime/containers/docker/AttemptOOM.java
- test/hotspot/jtreg/runtime/containers/docker/CheckContainerized.java
- test/hotspot/jtreg/runtime/containers/docker/DockerBasicTest.java
- test/hotspot/jtreg/runtime/containers/docker/HelloDocker.java
- test/hotspot/jtreg/runtime/containers/docker/JfrReporter.java
- test/hotspot/jtreg/runtime/containers/docker/PrintContainerInfo.java
- test/hotspot/jtreg/runtime/containers/docker/TEST.properties
- test/hotspot/jtreg/runtime/containers/docker/TestCPUAwareness.java
- test/hotspot/jtreg/runtime/containers/docker/TestCPUSets.java
- test/hotspot/jtreg/runtime/containers/docker/TestJFREvents.java
- test/hotspot/jtreg/runtime/containers/docker/TestMemoryAwareness.java
- test/hotspot/jtreg/runtime/containers/docker/TestMisc.java
- test/hotspot/jtreg/runtime/interpreter/WideStrictInline.java
- test/hotspot/jtreg/runtime/noClassDefFoundMsg/NoClassDefFoundMsg.java
- test/hotspot/jtreg/runtime/noClassDefFoundMsg/libNoClassDefFoundMsg.c
- test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java
- test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java
- test/jdk/java/lang/Character/PropList.txt
- test/jdk/java/lang/Character/PropertyValueAliases.txt
- test/jdk/java/lang/Character/Scripts.txt
- test/jdk/java/lang/Character/SpecialCasing.txt
- test/jdk/java/lang/Character/UnicodeBlock/Blocks.txt
- test/jdk/java/lang/Character/UnicodeData.txt
- test/jdk/java/lang/Character/charprop00.bin
- test/jdk/java/lang/Character/charprop01.bin
- test/jdk/java/lang/Character/charprop02.bin
- test/jdk/java/lang/Character/charprop03.bin
- test/jdk/java/lang/Character/charprop0E.bin
- test/jdk/java/lang/Character/charprop0F.bin
- test/jdk/java/lang/Character/charprop10.bin
- test/jdk/java/lang/String/concat/StringConcatFactoryEmptyMethods.java
- test/jdk/java/net/Socket/OldImpl.java
- test/jdk/java/net/Socket/OldSocketImpl.java
- test/jdk/java/net/Socket/OldSocketImplTestDriver.java
- test/jdk/java/nio/channels/SocketChannel/Stream.java
- test/jdk/java/util/regex/GraphemeBreakProperty.txt
- test/jdk/java/util/regex/GraphemeBreakTest.txt
- test/jdk/javax/accessibility/8197785/AccessibilityBundleMemoryLeakTest.java
- test/jdk/jdk/nio/zipfs/MultiReleaseJarTest.java
- test/jdk/jdk/nio/zipfs/jarfs/root/dir1/leaf1.txt
- test/jdk/jdk/nio/zipfs/jarfs/root/dir1/leaf2.txt
- test/jdk/jdk/nio/zipfs/jarfs/root/dir2/leaf3.txt
- test/jdk/jdk/nio/zipfs/jarfs/root/dir2/leaf4.txt
- test/jdk/jdk/nio/zipfs/jarfs/v9/root/dir1/leaf1.txt
- test/jdk/jdk/nio/zipfs/jarfs/v9/root/dir1/leaf2.txt
- test/jdk/jdk/nio/zipfs/jarfs/v9/root/dir2/leaf3.txt
- test/jdk/jdk/nio/zipfs/jarfs/v9/root/dir2/leaf4.txt
- test/jdk/sun/management/windows/revokeall.c
- test/jdk/sun/management/windows/revokeall.exe
- test/jdk/sun/misc/ClassLoaderUtil/test.jar
- test/jdk/sun/security/pkcs11/tls/tls12/TestTLS12.java
- test/jdk/sun/security/ssl/rsa/BrokenRSAPrivateCrtKey.java
- test/jdk/sun/security/tools/jarsigner/AlgOptions.sh
- test/jdk/sun/security/tools/jarsigner/PercentSign.sh
- test/jdk/sun/security/tools/jarsigner/certpolicy.sh
- test/jdk/sun/security/tools/jarsigner/checkusage.sh
- test/jdk/sun/security/tools/jarsigner/collator.sh
- test/jdk/sun/security/tools/jarsigner/concise_jarsigner.sh
- test/jdk/sun/security/tools/jarsigner/crl.sh
- test/jdk/sun/security/tools/jarsigner/default_options.sh
- test/jdk/sun/security/tools/jarsigner/diffend.sh
- test/jdk/sun/security/tools/jarsigner/ec.sh
- test/jdk/sun/security/tools/jarsigner/emptymanifest.sh
- test/jdk/sun/security/tools/jarsigner/jvindex.sh
- test/jdk/sun/security/tools/jarsigner/nameclash.sh
- test/jdk/sun/security/tools/jarsigner/newsize7.sh
- test/jdk/sun/security/tools/jarsigner/oldsig.sh
- test/jdk/sun/security/tools/jarsigner/onlymanifest.sh
- test/jdk/sun/security/tools/jarsigner/passtype.sh
- test/jdk/sun/security/tools/jarsigner/samename.sh
- test/jdk/sun/security/tools/jarsigner/weaksize.sh
- test/jdk/sun/security/tools/keytool/CloneKeyAskPassword.sh
- test/jdk/sun/security/tools/keytool/DefaultSignatureAlgorithm.java
- test/jdk/sun/security/tools/keytool/NoExtNPE.sh
- test/jdk/sun/security/tools/keytool/PSS.java
- test/jdk/sun/security/tools/keytool/SecretKeyKS.sh
- test/jdk/sun/security/tools/keytool/StandardAlgName.sh
- test/jdk/sun/security/tools/keytool/StorePasswordsByShell.sh
- test/jdk/sun/security/tools/keytool/default_options.sh
- test/jdk/sun/security/tools/keytool/emptysubject.sh
- test/jdk/sun/security/tools/keytool/file-in-help.sh
- test/jdk/sun/security/tools/keytool/i18n.sh
- test/jdk/sun/security/tools/keytool/importreadall.sh
- test/jdk/sun/security/tools/keytool/keyalg.sh
- test/jdk/sun/security/tools/keytool/newhelp.sh
- test/jdk/sun/security/tools/keytool/resource.sh
- test/jdk/sun/security/tools/keytool/selfissued.sh
- test/jdk/sun/security/tools/keytool/trystore.sh
- test/jdk/sun/util/calendar/zi/tzdata/VERSION
- test/jdk/sun/util/calendar/zi/tzdata/africa
- test/jdk/sun/util/calendar/zi/tzdata/antarctica
- test/jdk/sun/util/calendar/zi/tzdata/asia
- test/jdk/sun/util/calendar/zi/tzdata/australasia
- test/jdk/sun/util/calendar/zi/tzdata/backward
- test/jdk/sun/util/calendar/zi/tzdata/etcetera
- test/jdk/sun/util/calendar/zi/tzdata/europe
- test/jdk/sun/util/calendar/zi/tzdata/factory
- test/jdk/sun/util/calendar/zi/tzdata/gmt
- test/jdk/sun/util/calendar/zi/tzdata/iso3166.tab
- test/jdk/sun/util/calendar/zi/tzdata/jdk11_backward
- test/jdk/sun/util/calendar/zi/tzdata/leapseconds
- test/jdk/sun/util/calendar/zi/tzdata/northamerica
- test/jdk/sun/util/calendar/zi/tzdata/pacificnew
- test/jdk/sun/util/calendar/zi/tzdata/solar87
- test/jdk/sun/util/calendar/zi/tzdata/solar88
- test/jdk/sun/util/calendar/zi/tzdata/solar89
- test/jdk/sun/util/calendar/zi/tzdata/southamerica
- test/jdk/sun/util/calendar/zi/tzdata/systemv
- test/jdk/sun/util/calendar/zi/tzdata/zone.tab
- test/jdk/sun/util/calendar/zi/tzdata_jdk/gmt
- test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward
- test/langtools/jdk/javadoc/doclet/AccessFrameTitle/AccessFrameTitle.java
- test/langtools/jdk/javadoc/doclet/AccessFrameTitle/p1/C1.java
- test/langtools/jdk/javadoc/doclet/AccessFrameTitle/p2/C2.java
- test/langtools/jdk/javadoc/doclet/PackagesHeader/PackagesHeader.java
- test/langtools/jdk/javadoc/doclet/PackagesHeader/p1/C1.java
- test/langtools/jdk/javadoc/doclet/PackagesHeader/p2/C2.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyAnnotation.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyClass.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyEnum.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyError.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyException.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyInterface.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyAnnotation.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyClass.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyEnum.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyError.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyException.java
- test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyInterface.java
- test/langtools/jdk/javadoc/doclet/testFramesNoFrames/TestFramesNoFrames.java
- test/langtools/jdk/javadoc/doclet/testWindowTitle/TestWindowTitle.java
- test/langtools/jdk/javadoc/doclet/testWindowTitle/p1/C1.java
- test/langtools/jdk/javadoc/doclet/testWindowTitle/p2/C2.java
- test/langtools/tools/javac/diags/examples/BreakAmbiguousTarget.java
- test/langtools/tools/javac/diags/examples/BreakComplexValueNoSwitchExpression.java
- test/langtools/tools/javac/diags/examples/BreakExprNotImmediate.java
- test/langtools/tools/javac/diags/examples/BreakMissingValue.java


From sandhya.viswanathan at intel.com  Fri Sep  6 01:17:46 2019
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Fri, 6 Sep 2019 01:17:46 +0000
Subject: [vector] generic operand infrastructure support.
In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB8B7C2B8@FMSMSX125.amr.corp.intel.com>
References: <A66BBE673E08E1428E3A918AE4D5B32C0A046865@BGSMSX106.gar.corp.intel.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB8B7BA31@FMSMSX125.amr.corp.intel.com>
 <VE1PR08MB46567F15C97881E43CFB0AEB8EBE0@VE1PR08MB4656.eurprd08.prod.outlook.com>
 <02FCFB8477C4EF43A2AD8E0C60F3DA2BB8B7C2B8@FMSMSX125.amr.corp.intel.com>
Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2BB8B7D944@FMSMSX125.amr.corp.intel.com>

Hi Jatin,

Let us use the vector-unstable branch on panama/dev for the generic operand infrastructure work in progress.  Please go ahead and check in this patch on the vector-unstable branch.

Best Regards,
Sandhya


-----Original Message-----
From: panama-dev <panama-dev-bounces at openjdk.java.net> On Behalf Of Viswanathan, Sandhya
Sent: Tuesday, September 03, 2019 10:04 AM
To: Yang Zhang (Arm Technology China) <Yang.Zhang at arm.com>; Bhateja, Jatin <jatin.bhateja at intel.com>; panama-dev at openjdk.java.net
Subject: RE: [vector] generic operand infrastructure support.

Hi Yang, Thanks a lot for your feedback. We have proposed the patch on the main line as well and would like to proceed with this technique on this branch so as to continue to make progress. I will take care of the manual merge as before.  Please feel free to adopt this if you find it useful for your architecture.

Jatin, could you please fix the issues pointed by Yang.   

Best Regards,
Sandhya


-----Original Message-----
From: Yang Zhang (Arm Technology China) [mailto:Yang.Zhang at arm.com] 
Sent: Sunday, September 01, 2019 8:45 PM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Bhateja, Jatin <jatin.bhateja at intel.com>; panama-dev at openjdk.java.net
Subject: RE: [vector] generic operand infrastructure support.

Hi Jatin, Sandhya

This patch is very generic. All the projects which are using vector instructions in backend can benefit from it. To reduce manual merge works in the future, proposing this patch to jdk/jdk master would be better.

I test this patch in our internal ci test framework. In x86 platform, build fails. The post-selection pass is missed. The error log is as follows:
src/hotspot/share/opto/compile.cpp:2945: undefined reference to `Matcher::do_post_selection_processing(Compile*, Node*)'
Besides that, there are also some trailing spaces and blank lines.

Regards
Yang

-----Original Message-----
From: panama-dev <panama-dev-bounces at openjdk.java.net> On Behalf Of Viswanathan, Sandhya
Sent: Saturday, August 31, 2019 6:08 AM
To: Bhateja, Jatin <jatin.bhateja at intel.com>; panama-dev at openjdk.java.net
Subject: RE: [vector] generic operand infrastructure support.

Hi Jatin,

The patch looks good to me.

Best Regards,
Sandhya


From: Bhateja, Jatin
Sent: Friday, August 30, 2019 5:07 AM
To: panama-dev at openjdk.java.net
Cc: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
Subject: [vector] generic operand infrastructure support.

Hi All,

We have been working over reducing the AD file and libjvm.so size by reducing the number of vector instruction patterns whose operands differ meagerly in vector lengths.
As of now we have several vector operand for X86 target like vecS , vecD, vecX , vecY, vecZ and their legacy variants. This patch adds an infrastructure to support generic operands[1]  and a post-selection pass to remove them from machine graph so that there is minimal impact on the downstream passes.

Complete patch using generic operands which reduces the number of vector patterns from 510 to 222 is already posted over mainline https://mail.openjdk.java.net/piperail/hotspot-compiler-dev/2019-August/034822.html

Since vectorIntrinsics branch has bulk of the vector instruction patterns hence we plan to introduce the support in stages.

Following patch contains the infrastructure changes for generic operands, using it we can collapse the different vector length instructions for same operation without making any changes in the ideal graph.
CR : http://cr.openjdk.java.net/~jbhateja/vectorIntrinsics/GEN_OPERS/webrev.00/
Common JBS for jdk/mainline and panama/vectorIntrinsics : https://bugs.openjdk.java.net/browse/JDK-8230015

Kindly review it provide your feedback.

Best Regards,
Jatin Bhateja

PS : All the changes are currently enabled only for X86 target.
[1]  http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

From jatin.bhateja at intel.com  Fri Sep  6 05:57:17 2019
From: jatin.bhateja at intel.com (jatin.bhateja at intel.com)
Date: Fri, 06 Sep 2019 05:57:17 +0000
Subject: hg: panama/dev: Summary: Infrastructure changes for generic vector
 operands, includes following:-
Message-ID: <201909060557.x865vIjE003045@aojmv0008.oracle.com>

Changeset: 784d7b4adfe7
Author:    Jatin Bhateja <jatin.bhateja at intel.com>
Date:      2019-09-06 11:26 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/784d7b4adfe7

Summary: Infrastructure changes for generic vector operands, includes following:-
         1) Creation of new generic operands vecG and legVecG along
            with the chain instructions MoveLegVecG2VecG and MoveVecG2LegVecG.
         2) Post-selection stage for its resolution to concrete vector operands.
         3) All the changes are currently enabled only for X86 target.
Reviewed-by: sandhya.viswanathan at intel.com
Contributed-by: jatin.bhateja at intel.com

+ src/hotspot/cpu/x86/postSelection_x86.cpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/archDesc.cpp
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/adlc/output_h.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/opcodes.cpp
! src/hotspot/share/opto/opcodes.hpp
! src/hotspot/share/opto/phase.cpp
! src/hotspot/share/opto/phase.hpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp


From jatin.bhateja at intel.com  Fri Sep  6 12:34:56 2019
From: jatin.bhateja at intel.com (jatin.bhateja at intel.com)
Date: Fri, 06 Sep 2019 12:34:56 +0000
Subject: hg: panama/dev: Summary: Infrastructure changes for generic vector
 operands, includes following:-
Message-ID: <201909061234.x86CYuon009679@aojmv0008.oracle.com>

Changeset: 4ca845a25642
Author:    jbhateja
Date:      2019-09-06 18:07 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/4ca845a25642

Summary: Infrastructure changes for generic vector operands, includes following:-
         1) Creation of new generic operands vecG and legVecG along
            with the chain instructions MoveLegVecG2VecG and MoveVecG2LegVecG.
         2) Post-selection stage for its resolution to concrete vector operands.
         3) All the changes are currently enabled only for X86 target.
Reviewed-by: sandhya.viswanathan at intel.com
Contributed-by: jatin.bhateja at intel.com

+ src/hotspot/cpu/x86/postSelection_x86.cpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/archDesc.cpp
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/adlc/output_h.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/opcodes.cpp
! src/hotspot/share/opto/opcodes.hpp
! src/hotspot/share/opto/phase.cpp
! src/hotspot/share/opto/phase.hpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp


From youngty1997 at gmail.com  Fri Sep  6 23:24:23 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 6 Sep 2019 18:24:23 -0500
Subject: Project Panama & dynamic library loading
Message-ID: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>

Hi,


I mentioned this before in a linked article I did, but another major 
issue with current jextract/java library pathing is that it is static 
instead of dyanamic(that is, a specific path). This causes huge problems 
not only with cross-platform libraries but also in the heavily 
fragmented Linux ecosystem. NVML(Nvidia Management Library) for example 
exists in entirely different locations in /usr/lib in Ubuntu, Arch, and 
Fedora as well as in Windows. As a result, bindings have to be generated 
multiple times even on the same platform in order to work correctly.


Can a way to dynamically specify the library path from within Java be added?


From youngty1997 at gmail.com  Fri Sep  6 23:58:43 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 6 Sep 2019 18:58:43 -0500
Subject: Project Panama & dynamic library loading
In-Reply-To: <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
Message-ID: <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>


On 9/6/19 6:36 PM, Ty Young wrote:
>
>
> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>> Hi Ty, you are not forced to save the library path in the generated 
>> extracted jar with the --record-library-path? option. If you can also 
>> omit that option, and then set java.library.path (or LD_LIBRARY_PATH) 
>> accordingly when it's time to run your application.


Can java.library.path be modified in code or does it have to be a launch 
option to work? I've always assumed it was a launch option only and 
haven't thought much of it.


It would really be nice if the whole thing was dynamic with zero 
hardcoded values, even if startup time was sacrificed due to library 
searching. With how fragmented the Linux ecosystem specifically is, 
there is never any guarantee that any hardcoded values(s) will work for 
all Linux distros.


>> One thing that we'd also like to improve longer term is how the 
>> default value of the java.library.path is populated across the 
>> various OS/distros. The values under linux e.g. do not make a lot of 
>> sense (apart from /usr/lib) - and we need a better way to talk to the 
>> system linker.


Sounds like a fun game of wackamole.


>> Maurizio On 07/09/2019 00:24, Ty Young wrote:
>>
>>     Hi, I mentioned this before in a linked article I did, but
>>     another major issue with current jextract/java library pathing
>>     is that it is static instead of dyanamic(that is, a specific
>>     path). This causes huge problems not only with cross-platform
>>     libraries but also in the heavily fragmented Linux ecosystem.
>>     NVML(Nvidia Management Library) for example exists in entirely
>>     different locations in /usr/lib in Ubuntu, Arch, and Fedora as
>>     well as in Windows. As a result, bindings have to be generated
>>     multiple times even on the same platform in order to work
>>     correctly. Can a way to dynamically specify the library path from
>>     within Java be added? 
>>

From henry.jen at oracle.com  Sat Sep  7 01:12:05 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 6 Sep 2019 18:12:05 -0700
Subject: Project Panama & dynamic library loading
In-Reply-To: <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
Message-ID: <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>



> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
> 
> 
> On 9/6/19 6:36 PM, Ty Young wrote:
>> 
>> 
>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>> Hi Ty, you are not forced to save the library path in the generated extracted jar with the --record-library-path  option. If you can also omit that option, and then set java.library.path (or LD_LIBRARY_PATH) accordingly when it's time to run your application.
> 
> 
> Can java.library.path be modified in code or does it have to be a launch option to work? I've always assumed it was a launch option only and haven't thought much of it.
> 

It?s a launch option, and thus can adapt to your deployment environment.

> 
> It would really be nice if the whole thing was dynamic with zero hardcoded values, even if startup time was sacrificed due to library searching. With how fragmented the Linux ecosystem specifically is, there is never any guarantee that any hardcoded values(s) will work for all Linux distros.
> 

Dynamic loading is supported since beginning, typical code snippet is like following.

Library lib = Libraries.loadLibrary(MethodHandles.lookup(), "tensorflow");
libTF = Libraries.bind(c_api_h.class, lib);

As long as you define java.library.path to include correct search path for the native library, it should work just fine.

The ?record-library-path is added to provide a default search path for the static-forwarder class. It?s not an required options, but was added to search path provided by JVM, which include the path defined in  java.library.path.

HTH,
Henry


>>> One thing that we'd also like to improve longer term is how the default value of the java.library.path is populated across the various OS/distros. The values under linux e.g. do not make a lot of sense (apart from /usr/lib) - and we need a better way to talk to the system linker.
> 
> 
> Sounds like a fun game of wackamole.
> 
> 
>>> Maurizio On 07/09/2019 00:24, Ty Young wrote:
>>> 
>>>    Hi, I mentioned this before in a linked article I did, but
>>>    another major issue with current jextract/java library pathing
>>>    is that it is static instead of dyanamic(that is, a specific
>>>    path). This causes huge problems not only with cross-platform
>>>    libraries but also in the heavily fragmented Linux ecosystem.
>>>    NVML(Nvidia Management Library) for example exists in entirely
>>>    different locations in /usr/lib in Ubuntu, Arch, and Fedora as
>>>    well as in Windows. As a result, bindings have to be generated
>>>    multiple times even on the same platform in order to work
>>>    correctly. Can a way to dynamically specify the library path from
>>>    within Java be added? 


From youngty1997 at gmail.com  Sat Sep  7 01:47:16 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 6 Sep 2019 20:47:16 -0500
Subject: Project Panama & dynamic library loading
In-Reply-To: <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
Message-ID: <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>


On 9/6/19 8:12 PM, Henry Jen wrote:
>
>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>
>>
>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>
>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>>> Hi Ty, you are not forced to save the library path in the generated extracted jar with the --record-library-path  option. If you can also omit that option, and then set java.library.path (or LD_LIBRARY_PATH) accordingly when it's time to run your application.
>>
>> Can java.library.path be modified in code or does it have to be a launch option to work? I've always assumed it was a launch option only and haven't thought much of it.
>>
> It?s a launch option, and thus can adapt to your deployment environment.


There is no specific "deployment environment". If you were to create 
bindings in Arch Linux you'd need to specify the pathing for every other 
Linux distro and even Windows, resulting in not working on more obscure 
Linux distros and two different builds between Windows and Linux. If you 
could just dynamically add the paths that'd make this so much easier...


>
>> It would really be nice if the whole thing was dynamic with zero hardcoded values, even if startup time was sacrificed due to library searching. With how fragmented the Linux ecosystem specifically is, there is never any guarantee that any hardcoded values(s) will work for all Linux distros.
>>
> Dynamic loading is supported since beginning, typical code snippet is like following.
>
> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), "tensorflow");
> libTF = Libraries.bind(c_api_h.class, lib);
>
> As long as you define java.library.path to include correct search path for the native library, it should work just fine.


The search path being static is the problem here. Without a dynamic way 
to add libraries easily things will blowup real badly.


>
> The ?record-library-path is added to provide a default search path for the static-forwarder class. It?s not an required options, but was added to search path provided by JVM, which include the path defined in  java.library.path.
>
> HTH,
> Henry
>
>
>>>> One thing that we'd also like to improve longer term is how the default value of the java.library.path is populated across the various OS/distros. The values under linux e.g. do not make a lot of sense (apart from /usr/lib) - and we need a better way to talk to the system linker.
>>
>> Sounds like a fun game of wackamole.
>>
>>
>>>> Maurizio On 07/09/2019 00:24, Ty Young wrote:
>>>>
>>>>     Hi, I mentioned this before in a linked article I did, but
>>>>     another major issue with current jextract/java library pathing
>>>>     is that it is static instead of dyanamic(that is, a specific
>>>>     path). This causes huge problems not only with cross-platform
>>>>     libraries but also in the heavily fragmented Linux ecosystem.
>>>>     NVML(Nvidia Management Library) for example exists in entirely
>>>>     different locations in /usr/lib in Ubuntu, Arch, and Fedora as
>>>>     well as in Windows. As a result, bindings have to be generated
>>>>     multiple times even on the same platform in order to work
>>>>     correctly. Can a way to dynamically specify the library path from
>>>>     within Java be added?

From samuel.audet at gmail.com  Sat Sep  7 02:44:18 2019
From: samuel.audet at gmail.com (Samuel Audet)
Date: Sat, 7 Sep 2019 11:44:18 +0900
Subject: Project Panama & dynamic library loading
In-Reply-To: <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
Message-ID: <2832e93b-f722-f4ed-2418-64ed91113582@gmail.com>

On 9/7/19 10:47 AM, Ty Young wrote:
> There is no specific "deployment environment". If you were to create 
> bindings in Arch Linux you'd need to specify the pathing for every other 
> Linux distro and even Windows, resulting in not working on more obscure 
> Linux distros and two different builds between Windows and Linux. If you 
> could just dynamically add the paths that'd make this so much easier...

It's not just the paths, the libraries themselves are almost never built 
exactly the same. That's why people don't try to use RPMs for Fedora on 
Ubuntu or vice versa. What we need is a similar kind of distribution for 
Java.

Samuel

From youngty1997 at gmail.com  Sat Sep  7 03:29:26 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 6 Sep 2019 22:29:26 -0500
Subject: Project Panama & dynamic library loading
In-Reply-To: <2832e93b-f722-f4ed-2418-64ed91113582@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <2832e93b-f722-f4ed-2418-64ed91113582@gmail.com>
Message-ID: <df870638-05ce-8c3f-49a3-4957f01312a0@gmail.com>


On 9/6/19 9:44 PM, Samuel Audet wrote:
> On 9/7/19 10:47 AM, Ty Young wrote:
>> There is no specific "deployment environment". If you were to create 
>> bindings in Arch Linux you'd need to specify the pathing for every 
>> other Linux distro and even Windows, resulting in not working on more 
>> obscure Linux distros and two different builds between Windows and 
>> Linux. If you could just dynamically add the paths that'd make this 
>> so much easier...
>
> It's not just the paths, the libraries themselves are almost never 
> built exactly the same. That's why people don't try to use RPMs for 
> Fedora on Ubuntu or vice versa. What we need is a similar kind of 
> distribution for Java.


If by "almost never built exactly the same" you mean different versions 
and patches then yeah, that's an issue. The only real solution AFAIK is 
to package specifically for that distro/platform or maybe try to target 
older versions and hope noone changes anything in newer versions.


...but there are libraries that are stable either because they aren't 
open source or because they are lower level, such as NVML. The location 
in such cases is the only issue. Again, for this library specifically it 
can either be located in:


Ubuntu: /usr/lib/<whatever-gnu-folder-from-jextract-examples>


Arch Linux: /usr/lib


Fedora: /usr/lib64


Windows: \%ProgramW6432\%\\"NVIDIA Corporation"\\NVSMI\\


Also, according to NVML documentation C support library loading:


"To dynamically load NVML, call LoadLibrary with this path."


So why won't/can't Java support it?


If the default library search paths were fixed this would be less of an 
issue but because of the fragmented nature of Linux would there ever be 
a complete and accurate default library search paths that works on all 
platforms anyway?


There is a possible solution in my case I think: specify "./libraries" 
or some current directory folder as part of the application as the path 
and then have a launcher find and copy the library to that folder... but 
I don't know how well that'd work if at all. How literal does jextract 
take the specified library path?


>
> Samuel

From henry.jen at oracle.com  Sat Sep  7 04:04:30 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 6 Sep 2019 21:04:30 -0700
Subject: Project Panama & dynamic library loading
In-Reply-To: <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
Message-ID: <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>



> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
> 
> 
> On 9/6/19 8:12 PM, Henry Jen wrote:
>> 
>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>> 
>>> 
>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>> 
>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>>>> Hi Ty, you are not forced to save the library path in the generated extracted jar with the --record-library-path  option. If you can also omit that option, and then set java.library.path (or LD_LIBRARY_PATH) accordingly when it's time to run your application.
>>> 
>>> Can java.library.path be modified in code or does it have to be a launch option to work? I've always assumed it was a launch option only and haven't thought much of it.
>>> 
>> It?s a launch option, and thus can adapt to your deployment environment.
> 
> 
> There is no specific "deployment environment". If you were to create bindings in Arch Linux you'd need to specify the pathing for every other Linux distro and even Windows, resulting in not working on more obscure Linux distros and two different builds between Windows and Linux. If you could just dynamically add the paths that'd make this so much easier?
> 

In this case, you are looking for a sane system default, which as Mauricio mentioned, we need to look for better ways. OpenJDK by default is not providing proper value across various Linux distros. But java.library.path provide a way to accommodate that. Also, it?s possible to 

Usually, a Linux distro will have a customized OpenJDK package has customized default.

> 
>> 
>>> It would really be nice if the whole thing was dynamic with zero hardcoded values, even if startup time was sacrificed due to library searching. With how fragmented the Linux ecosystem specifically is, there is never any guarantee that any hardcoded values(s) will work for all Linux distros.
>>> 
>> Dynamic loading is supported since beginning, typical code snippet is like following.
>> 
>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), "tensorflow");
>> libTF = Libraries.bind(c_api_h.class, lib);
>> 
>> As long as you define java.library.path to include correct search path for the native library, it should work just fine.
> 
> 
> The search path being static is the problem here. Without a dynamic way to add libraries easily things will blowup real badly.
> 
> 

With jextract, combine -L option with -l and ?record-library-path, the provided search paths is saved to be used for runtime. I know it?s not the same as an API, but provide the behavior you described?

Cheers,
Henry


From youngty1997 at gmail.com  Sat Sep  7 04:17:40 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 6 Sep 2019 23:17:40 -0500
Subject: Project Panama & dynamic library loading
In-Reply-To: <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
Message-ID: <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>


On 9/6/19 11:04 PM, Henry Jen wrote:
>
>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>
>>
>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>
>>>>
>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>>>>> Hi Ty, you are not forced to save the library path in the generated extracted jar with the --record-library-path  option. If you can also omit that option, and then set java.library.path (or LD_LIBRARY_PATH) accordingly when it's time to run your application.
>>>> Can java.library.path be modified in code or does it have to be a launch option to work? I've always assumed it was a launch option only and haven't thought much of it.
>>>>
>>> It?s a launch option, and thus can adapt to your deployment environment.
>>
>> There is no specific "deployment environment". If you were to create bindings in Arch Linux you'd need to specify the pathing for every other Linux distro and even Windows, resulting in not working on more obscure Linux distros and two different builds between Windows and Linux. If you could just dynamically add the paths that'd make this so much easier?
>>
> In this case, you are looking for a sane system default, which as Mauricio mentioned, we need to look for better ways. OpenJDK by default is not providing proper value across various Linux distros. But java.library.path provide a way to accommodate that. Also, it?s possible to
>
> Usually, a Linux distro will have a customized OpenJDK package has customized default.
>
>>>> It would really be nice if the whole thing was dynamic with zero hardcoded values, even if startup time was sacrificed due to library searching. With how fragmented the Linux ecosystem specifically is, there is never any guarantee that any hardcoded values(s) will work for all Linux distros.
>>>>
>>> Dynamic loading is supported since beginning, typical code snippet is like following.
>>>
>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), "tensorflow");
>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>
>>> As long as you define java.library.path to include correct search path for the native library, it should work just fine.
>>
>> The search path being static is the problem here. Without a dynamic way to add libraries easily things will blowup real badly.
>>
>>
> With jextract, combine -L option with -l and ?record-library-path, the provided search paths is saved to be used for runtime. I know it?s not the same as an API, but provide the behavior you described?


Path(s) or path? None of the examples that I see show multiple library 
paths being specified. If it is possible then sure, I guess. It's still 
hardcoded and could break but at least I'll have the three major distros 
covered and don't have to copy libraries around...


That said, can a Windows path be specified alongside the Linux paths?


>
> Cheers,
> Henry
>

From maurizio.cimadamore at oracle.com  Sat Sep  7 17:14:12 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 7 Sep 2019 18:14:12 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
Message-ID: <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>


On 07/09/2019 05:17, Ty Young wrote:
>
> On 9/6/19 11:04 PM, Henry Jen wrote:
>>
>>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>
>>>
>>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>>
>>>>>
>>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore 
>>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>>> Hi Ty, you are not forced to save the library path in the 
>>>>>>> generated extracted jar with the --record-library-path? option. 
>>>>>>> If you can also omit that option, and then set java.library.path 
>>>>>>> (or LD_LIBRARY_PATH) accordingly when it's time to run your 
>>>>>>> application.
>>>>> Can java.library.path be modified in code or does it have to be a 
>>>>> launch option to work? I've always assumed it was a launch option 
>>>>> only and haven't thought much of it.
>>>>>
>>>> It?s a launch option, and thus can adapt to your deployment 
>>>> environment.
>>>
>>> There is no specific "deployment environment". If you were to create 
>>> bindings in Arch Linux you'd need to specify the pathing for every 
>>> other Linux distro and even Windows, resulting in not working on 
>>> more obscure Linux distros and two different builds between Windows 
>>> and Linux. If you could just dynamically add the paths that'd make 
>>> this so much easier?
>>>
>> In this case, you are looking for a sane system default, which as 
>> Mauricio mentioned, we need to look for better ways. OpenJDK by 
>> default is not providing proper value across various Linux distros. 
>> But java.library.path provide a way to accommodate that. Also, it?s 
>> possible to
>>
>> Usually, a Linux distro will have a customized OpenJDK package has 
>> customized default.
>>
>>>>> It would really be nice if the whole thing was dynamic with zero 
>>>>> hardcoded values, even if startup time was sacrificed due to 
>>>>> library searching. With how fragmented the Linux ecosystem 
>>>>> specifically is, there is never any guarantee that any hardcoded 
>>>>> values(s) will work for all Linux distros.
>>>>>
>>>> Dynamic loading is supported since beginning, typical code snippet 
>>>> is like following.
>>>>
>>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), 
>>>> "tensorflow");
>>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>>
>>>> As long as you define java.library.path to include correct search 
>>>> path for the native library, it should work just fine.
>>>
>>> The search path being static is the problem here. Without a dynamic 
>>> way to add libraries easily things will blowup real badly.
>>>
>>>
>> With jextract, combine -L option with -l and ?record-library-path, 
>> the provided search paths is saved to be used for runtime. I know 
>> it?s not the same as an API, but provide the behavior you described?
>
>
> Path(s) or path? None of the examples that I see show multiple library 
> paths being specified. If it is possible then sure, I guess. It's 
> still hardcoded and could break but at least I'll have the three major 
> distros covered and don't have to copy libraries around...
>
>
> That said, can a Windows path be specified alongside the Linux paths?

When you use --record-library-path whatever path you specify with -L 
will end up saved in the generated annotations. You can put non-existent 
paths in there - it's no harm, they will be just ignored at runtime on 
th eplatforms where they don't make sense.

Maurizio

>
>
>>
>> Cheers,
>> Henry
>>

From youngty1997 at gmail.com  Sat Sep  7 19:15:01 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sat, 7 Sep 2019 14:15:01 -0500
Subject: Project Panama & dynamic library loading
In-Reply-To: <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
Message-ID: <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>


On 9/7/19 12:14 PM, Maurizio Cimadamore wrote:
>
> On 07/09/2019 05:17, Ty Young wrote:
>>
>> On 9/6/19 11:04 PM, Henry Jen wrote:
>>>
>>>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>
>>>>
>>>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore 
>>>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>>>> Hi Ty, you are not forced to save the library path in the 
>>>>>>>> generated extracted jar with the --record-library-path? option. 
>>>>>>>> If you can also omit that option, and then set 
>>>>>>>> java.library.path (or LD_LIBRARY_PATH) accordingly when it's 
>>>>>>>> time to run your application.
>>>>>> Can java.library.path be modified in code or does it have to be a 
>>>>>> launch option to work? I've always assumed it was a launch option 
>>>>>> only and haven't thought much of it.
>>>>>>
>>>>> It?s a launch option, and thus can adapt to your deployment 
>>>>> environment.
>>>>
>>>> There is no specific "deployment environment". If you were to 
>>>> create bindings in Arch Linux you'd need to specify the pathing for 
>>>> every other Linux distro and even Windows, resulting in not working 
>>>> on more obscure Linux distros and two different builds between 
>>>> Windows and Linux. If you could just dynamically add the paths 
>>>> that'd make this so much easier?
>>>>
>>> In this case, you are looking for a sane system default, which as 
>>> Mauricio mentioned, we need to look for better ways. OpenJDK by 
>>> default is not providing proper value across various Linux distros. 
>>> But java.library.path provide a way to accommodate that. Also, it?s 
>>> possible to
>>>
>>> Usually, a Linux distro will have a customized OpenJDK package has 
>>> customized default.
>>>
>>>>>> It would really be nice if the whole thing was dynamic with zero 
>>>>>> hardcoded values, even if startup time was sacrificed due to 
>>>>>> library searching. With how fragmented the Linux ecosystem 
>>>>>> specifically is, there is never any guarantee that any hardcoded 
>>>>>> values(s) will work for all Linux distros.
>>>>>>
>>>>> Dynamic loading is supported since beginning, typical code snippet 
>>>>> is like following.
>>>>>
>>>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), 
>>>>> "tensorflow");
>>>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>>>
>>>>> As long as you define java.library.path to include correct search 
>>>>> path for the native library, it should work just fine.
>>>>
>>>> The search path being static is the problem here. Without a dynamic 
>>>> way to add libraries easily things will blowup real badly.
>>>>
>>>>
>>> With jextract, combine -L option with -l and ?record-library-path, 
>>> the provided search paths is saved to be used for runtime. I know 
>>> it?s not the same as an API, but provide the behavior you described?
>>
>>
>> Path(s) or path? None of the examples that I see show multiple 
>> library paths being specified. If it is possible then sure, I guess. 
>> It's still hardcoded and could break but at least I'll have the three 
>> major distros covered and don't have to copy libraries around...
>>
>>
>> That said, can a Windows path be specified alongside the Linux paths?
>
> When you use --record-library-path whatever path you specify with -L 
> will end up saved in the generated annotations. You can put 
> non-existent paths in there - it's no harm, they will be just ignored 
> at runtime on th eplatforms where they don't make sense.


Alright, but how do you specify multiple paths? Something like this:


-L /usr/lib:/usr/lib64


Or does it have its own unique regex?


>
> Maurizio
>
>>
>>
>>>
>>> Cheers,
>>> Henry
>>>

From maurizio.cimadamore at oracle.com  Sat Sep  7 20:11:14 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 7 Sep 2019 21:11:14 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
Message-ID: <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>


On 07/09/2019 20:15, Ty Young wrote:
>
> On 9/7/19 12:14 PM, Maurizio Cimadamore wrote:
>>
>> On 07/09/2019 05:17, Ty Young wrote:
>>>
>>> On 9/6/19 11:04 PM, Henry Jen wrote:
>>>>
>>>>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>>
>>>>>
>>>>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore 
>>>>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>>>>> Hi Ty, you are not forced to save the library path in the 
>>>>>>>>> generated extracted jar with the --record-library-path? 
>>>>>>>>> option. If you can also omit that option, and then set 
>>>>>>>>> java.library.path (or LD_LIBRARY_PATH) accordingly when it's 
>>>>>>>>> time to run your application.
>>>>>>> Can java.library.path be modified in code or does it have to be 
>>>>>>> a launch option to work? I've always assumed it was a launch 
>>>>>>> option only and haven't thought much of it.
>>>>>>>
>>>>>> It?s a launch option, and thus can adapt to your deployment 
>>>>>> environment.
>>>>>
>>>>> There is no specific "deployment environment". If you were to 
>>>>> create bindings in Arch Linux you'd need to specify the pathing 
>>>>> for every other Linux distro and even Windows, resulting in not 
>>>>> working on more obscure Linux distros and two different builds 
>>>>> between Windows and Linux. If you could just dynamically add the 
>>>>> paths that'd make this so much easier?
>>>>>
>>>> In this case, you are looking for a sane system default, which as 
>>>> Mauricio mentioned, we need to look for better ways. OpenJDK by 
>>>> default is not providing proper value across various Linux distros. 
>>>> But java.library.path provide a way to accommodate that. Also, it?s 
>>>> possible to
>>>>
>>>> Usually, a Linux distro will have a customized OpenJDK package has 
>>>> customized default.
>>>>
>>>>>>> It would really be nice if the whole thing was dynamic with zero 
>>>>>>> hardcoded values, even if startup time was sacrificed due to 
>>>>>>> library searching. With how fragmented the Linux ecosystem 
>>>>>>> specifically is, there is never any guarantee that any hardcoded 
>>>>>>> values(s) will work for all Linux distros.
>>>>>>>
>>>>>> Dynamic loading is supported since beginning, typical code 
>>>>>> snippet is like following.
>>>>>>
>>>>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), 
>>>>>> "tensorflow");
>>>>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>>>>
>>>>>> As long as you define java.library.path to include correct search 
>>>>>> path for the native library, it should work just fine.
>>>>>
>>>>> The search path being static is the problem here. Without a 
>>>>> dynamic way to add libraries easily things will blowup real badly.
>>>>>
>>>>>
>>>> With jextract, combine -L option with -l and ?record-library-path, 
>>>> the provided search paths is saved to be used for runtime. I know 
>>>> it?s not the same as an API, but provide the behavior you described?
>>>
>>>
>>> Path(s) or path? None of the examples that I see show multiple 
>>> library paths being specified. If it is possible then sure, I guess. 
>>> It's still hardcoded and could break but at least I'll have the 
>>> three major distros covered and don't have to copy libraries around...
>>>
>>>
>>> That said, can a Windows path be specified alongside the Linux paths?
>>
>> When you use --record-library-path whatever path you specify with -L 
>> will end up saved in the generated annotations. You can put 
>> non-existent paths in there - it's no harm, they will be just ignored 
>> at runtime on th eplatforms where they don't make sense.
>
>
> Alright, but how do you specify multiple paths? Something like this:
>
>
> -L /usr/lib:/usr/lib64

You repeat -L as many times as you want e.g.

-L /usr/lib -L /usr/lib64

Maurizio

>
>
> Or does it have its own unique regex?
>
>
>>
>> Maurizio
>>
>>>
>>>
>>>>
>>>> Cheers,
>>>> Henry
>>>>

From yang.zhang at arm.com  Mon Sep  9 02:21:31 2019
From: yang.zhang at arm.com (yang.zhang at arm.com)
Date: Mon, 09 Sep 2019 02:21:31 +0000
Subject: hg: panama/dev: Update jtreg test cases to make sure that C2 is used.
Message-ID: <201909090221.x892LWfG022075@aojmv0008.oracle.com>

Changeset: c3d5bb0b6a60
Author:    yzhang
Date:      2019-09-05 16:16 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/c3d5bb0b6a60

Update jtreg test cases to make sure that C2 is used.

! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/templates/Unit-header.template


From jorn.vernee at oracle.com  Tue Sep 10 12:07:18 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 10 Sep 2019 14:07:18 +0200
Subject: [foreign-abi] RFR 8230806: Use libTestUpcall in TestUpcall
Message-ID: <7269c605-38bc-40a7-37d4-ee0370260174@oracle.com>

Hi,

While working on another patch I noticed the current TestUpcall test is 
loading the downcall test library instead of the upcall test library. 
This means that the upcall tests were not actually using the callback 
that they were being passed. I've changed the library that is loaded, 
and added some checks that check that the callback is actually being 
called. (this also revealed a small bug in UniversalUpcallHandler that I 
fixed)

Please review the following:

Bug: https://bugs.openjdk.java.net/browse/JDK-8230806
Webrev: 
http://cr.openjdk.java.net/~jvernee/panama/webrevs/8230806/webrev.00/

Thanks,
Jorn


From maurizio.cimadamore at oracle.com  Tue Sep 10 12:44:11 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 10 Sep 2019 13:44:11 +0100
Subject: [foreign-abi] RFR 8230806: Use libTestUpcall in TestUpcall
In-Reply-To: <7269c605-38bc-40a7-37d4-ee0370260174@oracle.com>
References: <7269c605-38bc-40a7-37d4-ee0370260174@oracle.com>
Message-ID: <b57d7434-3d4d-0b01-4848-bd616c34b2ce@oracle.com>

Looks good, thanks for catching (and fixing) this.

Maurizio

On 10/09/2019 13:07, Jorn Vernee wrote:
> Hi,
>
> While working on another patch I noticed the current TestUpcall test 
> is loading the downcall test library instead of the upcall test 
> library. This means that the upcall tests were not actually using the 
> callback that they were being passed. I've changed the library that is 
> loaded, and added some checks that check that the callback is actually 
> being called. (this also revealed a small bug in 
> UniversalUpcallHandler that I fixed)
>
> Please review the following:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230806
> Webrev: 
> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8230806/webrev.00/
>
> Thanks,
> Jorn
>

From jbvernee at xs4all.nl  Tue Sep 10 12:55:56 2019
From: jbvernee at xs4all.nl (jbvernee at xs4all.nl)
Date: Tue, 10 Sep 2019 12:55:56 +0000
Subject: hg: panama/dev: 8230806: Use libTestUpcall in TestUpcall
Message-ID: <201909101255.x8ACtvMZ002961@aojmv0008.oracle.com>

Changeset: 398a5db82c40
Author:    jvernee
Date:      2019-09-10 14:55 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/398a5db82c40

8230806: Use libTestUpcall in TestUpcall
Reviewed-by: mcimadamore

! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UniversalUpcallHandler.java
! test/jdk/java/foreign/TestUpcall.java


From maurizio.cimadamore at oracle.com  Wed Sep 11 22:04:16 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 11 Sep 2019 22:04:16 +0000
Subject: hg: panama/dev: 307 new changesets
Message-ID: <201909112204.x8BM4WTY016827@aojmv0008.oracle.com>

Changeset: cafd691c6c04
Author:    jwilhelm
Date:      2019-08-08 03:09 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/cafd691c6c04

Added tag jdk-14+9 for changeset 18f189e69b29

! .hgtags

Changeset: 41f2f2829a09
Author:    rraghavan
Date:      2019-08-08 14:13 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/41f2f2829a09

8227439: Turn off AOT by default
Summary: Made UseAOT, AOTLibrary experimental and UseAOT false by default
Reviewed-by: iignatyev, kvn

! make/RunTests.gmk
! make/launcher/Launcher-jdk.aot.gmk
! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/compiler/aot/DeoptimizationTest.java
! test/hotspot/jtreg/compiler/aot/RecompilationTest.java
! test/hotspot/jtreg/compiler/aot/SharedUsageTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeDynamic2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeDynamic2CompiledTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeDynamic2InterpretedTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeDynamic2NativeTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeInterface2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeInterface2CompiledTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeInterface2InterpretedTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeInterface2NativeTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeSpecial2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeSpecial2CompiledTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeSpecial2InterpretedTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeSpecial2NativeTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeStatic2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeStatic2CompiledTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeStatic2InterpretedTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeStatic2NativeTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeVirtual2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeVirtual2CompiledTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeVirtual2InterpretedTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromAot/AotInvokeVirtual2NativeTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromCompiled/CompiledInvokeDynamic2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromCompiled/CompiledInvokeInterface2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromCompiled/CompiledInvokeSpecial2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromCompiled/CompiledInvokeStatic2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromCompiled/CompiledInvokeVirtual2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromInterpreted/InterpretedInvokeDynamic2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromInterpreted/InterpretedInvokeInterface2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromInterpreted/InterpretedInvokeSpecial2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromInterpreted/InterpretedInvokeStatic2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromInterpreted/InterpretedInvokeVirtual2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromNative/NativeInvokeSpecial2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromNative/NativeInvokeStatic2AotTest.java
! test/hotspot/jtreg/compiler/aot/calls/fromNative/NativeInvokeVirtual2AotTest.java
! test/hotspot/jtreg/compiler/aot/cli/AotLibraryNegativeBase.java
! test/hotspot/jtreg/compiler/aot/cli/DisabledAOTWithLibraryTest.java
! test/hotspot/jtreg/compiler/aot/cli/MultipleAOTLibraryTest.java
! test/hotspot/jtreg/compiler/aot/cli/SingleAOTLibraryTest.java
! test/hotspot/jtreg/compiler/aot/cli/SingleAOTOptionTest.java
! test/hotspot/jtreg/compiler/aot/cli/jaotc/JaotcTestHelper.java
! test/hotspot/jtreg/compiler/aot/fingerprint/SelfChanged.java
! test/hotspot/jtreg/compiler/aot/fingerprint/SelfChangedCDS.java
! test/hotspot/jtreg/compiler/aot/fingerprint/SuperChanged.java
! test/hotspot/jtreg/compiler/aot/scripts/build-bootmodules.sh
! test/hotspot/jtreg/compiler/aot/scripts/test-helloworld.sh
! test/hotspot/jtreg/compiler/aot/scripts/test-jaotc.sh
! test/hotspot/jtreg/compiler/aot/scripts/test-javac.sh
! test/hotspot/jtreg/compiler/aot/scripts/test-nashorn.sh
! test/hotspot/jtreg/compiler/aot/verification/ClassAndLibraryNotMatchTest.java
! test/hotspot/jtreg/compiler/aot/verification/vmflags/BasicFlagsChange.java
! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/AotTestGeneratorsFactory.java

Changeset: 1cf884e437ea
Author:    jcbeyler
Date:      2019-08-08 04:29 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/1cf884e437ea

8229036: Remove the testing against NSK_TRUE from tests
Summary: Remove the testing against NSK_TRUE from tests
Reviewed-by: sspitsyn, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTime/gettime001/gettime001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetTimerInfo/timerinfo001/timerinfo001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps001/relcaps001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/RelinquishCapabilities/relcaps002/relcaps002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS103/hs103t002/hs103t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t001/hs104t001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS104/hs104t002/hs104t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t001/hs202t001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t001/hs203t001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t002/hs203t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t003/hs203t003.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t002/hs204t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t004/hs204t004.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t002/hs301t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t003/hs301t003.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004/hs301t004.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t005/hs301t005.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t001/hs302t001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t002/hs302t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t003/hs302t003.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t004/hs302t004.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t005/hs302t005.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t006/hs302t006.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t007/hs302t007.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t008/hs302t008.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t009/hs302t009.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t010/hs302t010.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t011/hs302t011.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS302/hs302t012/hs302t012.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t003/sp02t003.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/sp06t003.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/earlyretbase.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp

Changeset: e4cc5231ce2d
Author:    dfuchs
Date:      2019-08-08 18:44 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/e4cc5231ce2d

8228970: AssertionError in ResponseSubscribers$HttpResponseInputStream
Summary: HttpResponseInputStream::read(byte[],int,int) now implements the same check than the InputStream::read(byte[],int,int).
Reviewed-by: prappo, chegar, dfuchs
Contributed-by: Patrick Concannon <patrick.concannon at oracle.com>

! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java
! test/jdk/java/net/httpclient/HttpResponseInputStreamTest.java

Changeset: 70f5cbb711a9
Author:    aefimov
Date:      2019-08-08 21:58 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/70f5cbb711a9

8225430: Replace wildcard address with loopback or local host in tests - part 14
Reviewed-by: dfuchs, chegar, vtewari

! test/jdk/java/net/DatagramSocket/ReuseAddressTest.java
! test/jdk/java/net/DatagramSocket/SendSize.java
! test/jdk/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java
! test/jdk/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java
! test/jdk/java/net/Socket/NullHost.java
! test/jdk/java/net/Socket/ProxyCons.java
! test/jdk/java/net/Socket/SocksConnectTimeout.java
! test/jdk/java/net/Socket/TestClose.java
! test/jdk/java/net/URLClassLoader/ClassLoad.java
! test/jdk/java/net/URLClassLoader/closetest/CloseTest.java
! test/jdk/java/net/URLConnection/HandleContentTypeWithAttrs.java
! test/jdk/java/net/URLConnection/RedirectLimit.java

Changeset: 8b104d8b27fd
Author:    jwilhelm
Date:      2019-08-08 03:08 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8b104d8b27fd

Added tag jdk-13+33 for changeset 5c85b58e2a42

! .hgtags

Changeset: 8f3fcb9251d1
Author:    thartmann
Date:      2019-08-08 07:05 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8f3fcb9251d1

8229219: C2 compilation fails with assert: Bad graph detected in build_loop_late
Summary: Backed out JDK-8173196.
Reviewed-by: shade, rbackman

! src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp
! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp

Changeset: 36a842b472e8
Author:    rrich
Date:      2019-08-08 07:07 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/36a842b472e8

8228359: [TESTBUG] jdk.jfr.e.g.c.TestGCHeapConfigurationEventWith32BitOops.java does not expect MinHeapSize to be aligned to HeapAlignment
Reviewed-by: mseledtsov, clanger

! test/jdk/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java

Changeset: 7faf0261e0a2
Author:    ljiang
Date:      2019-08-08 09:32 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/7faf0261e0a2

8228778: JDK 13 L10n resource files update - msgdrop 20
Reviewed-by: naoto

! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties
! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties

Changeset: 9c250a7600e1
Author:    diazhou
Date:      2019-08-08 05:05 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/9c250a7600e1

8229180: Remove EA from JDK 13 version string
Reviewed-by: tbell, mikael

! make/autoconf/version-numbers

Changeset: 31b7274c7b9e
Author:    jwilhelm
Date:      2019-08-09 03:36 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/31b7274c7b9e

Added tag jdk-13+33 for changeset 9c250a7600e1

! .hgtags

Changeset: 2e38a71e6038
Author:    jwilhelm
Date:      2019-08-09 03:51 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/2e38a71e6038

Merge

! .hgtags
! make/autoconf/version-numbers
! src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp

Changeset: 9dc92e89243a
Author:    eosterlund
Date:      2019-08-09 10:06 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9dc92e89243a

8229027: Improve how JNIHandleBlock::oops_do distinguishes oops from non-oops
Reviewed-by: pliden, stuefe, dlong

! src/hotspot/share/runtime/jniHandles.cpp
! src/hotspot/share/runtime/jniHandles.hpp

Changeset: 4aea554692aa
Author:    rehn
Date:      2019-08-09 11:04 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/4aea554692aa

8226228: Make Threads_lock an always safepoint checked lock.
Reviewed-by: coleenp, dcubed, dholmes

! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/threadSMR.cpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/utilities/vmError.cpp

Changeset: def8e77a3ad1
Author:    shade
Date:      2019-08-09 13:07 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/def8e77a3ad1

8229350: Shenandoah does not need barriers before CreateEx
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp

Changeset: 90688c5ff482
Author:    redestad
Date:      2019-08-09 13:58 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/90688c5ff482

8229283: StringLatin1 should consistently use CharacterDataLatin1.instance when applicable
Reviewed-by: jlaskey

! src/java.base/share/classes/java/lang/StringLatin1.java

Changeset: a64caa5269cf
Author:    cjplummer
Date:      2019-08-09 11:27 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/a64caa5269cf

8227645: Some tests in serviceability/sa run with fixed -Xmx values and risk running out of memory
Summary: move tests to seprate directory
Reviewed-by: dtitov, jcbeyler, ctornqvi, sspitsyn

! test/hotspot/jtreg/TEST.groups
+ test/hotspot/jtreg/resourcehogs/TEST.properties
+ test/hotspot/jtreg/resourcehogs/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
+ test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeArray.java
+ test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeStringArray.java
+ test/hotspot/jtreg/resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java
- test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeArray.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeStringArray.java
- test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java

Changeset: 072f27397b69
Author:    jjg
Date:      2019-08-09 12:27 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/072f27397b69

8227697: Improve text in Taglet API spec for expected results with standard doclet
Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/StandardDoclet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java

Changeset: 7cf02b2c1455
Author:    iklam
Date:      2019-08-09 13:13 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/7cf02b2c1455

8229267: [TESTBUG] Remove unnecessary @modules dependencies in CDS tests
Reviewed-by: alanb, lfoltan

! test/hotspot/jtreg/runtime/cds/ArchiveDoesNotExist.java
! test/hotspot/jtreg/runtime/cds/BootAppendTests.java
! test/hotspot/jtreg/runtime/cds/CdsDifferentObjectAlignment.java
! test/hotspot/jtreg/runtime/cds/CdsSameObjectAlignment.java
! test/hotspot/jtreg/runtime/cds/CheckDefaultArchiveFile.java
! test/hotspot/jtreg/runtime/cds/CheckSharingWithDefaultArchive.java
! test/hotspot/jtreg/runtime/cds/DumpSharedDictionary.java
! test/hotspot/jtreg/runtime/cds/DumpSymbolAndStringTable.java
! test/hotspot/jtreg/runtime/cds/NonBootLoaderClasses.java
! test/hotspot/jtreg/runtime/cds/SharedBaseAddress.java
! test/hotspot/jtreg/runtime/cds/SharedStrings.java
! test/hotspot/jtreg/runtime/cds/SharedStringsDedup.java
! test/hotspot/jtreg/runtime/cds/SharedStringsRunAuto.java
! test/hotspot/jtreg/runtime/cds/SpaceUtilizationCheck.java
! test/hotspot/jtreg/runtime/cds/TestInterpreterMethodEntries.java
! test/hotspot/jtreg/runtime/cds/appcds/AppendClasspath.java
! test/hotspot/jtreg/runtime/cds/appcds/BootClassPathMismatch.java
! test/hotspot/jtreg/runtime/cds/appcds/CDSandJFR.java
! test/hotspot/jtreg/runtime/cds/appcds/CaseSensitiveClassPath.java
! test/hotspot/jtreg/runtime/cds/appcds/ClassLoaderTest.java
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java
! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagCombo.java
! test/hotspot/jtreg/runtime/cds/appcds/CommandLineFlagComboNegative.java
! test/hotspot/jtreg/runtime/cds/appcds/DumpClassList.java
! test/hotspot/jtreg/runtime/cds/appcds/ExtraSymbols.java
! test/hotspot/jtreg/runtime/cds/appcds/FieldAnnotationsTest.java
! test/hotspot/jtreg/runtime/cds/appcds/HelloExtTest.java
! test/hotspot/jtreg/runtime/cds/appcds/HelloTest.java
! test/hotspot/jtreg/runtime/cds/appcds/IgnoreEmptyClassPaths.java
! test/hotspot/jtreg/runtime/cds/appcds/JvmtiAddPath.java
! test/hotspot/jtreg/runtime/cds/appcds/LongClassListPath.java
! test/hotspot/jtreg/runtime/cds/appcds/MissingSuperTest.java
! test/hotspot/jtreg/runtime/cds/appcds/MoveJDKTest.java
! test/hotspot/jtreg/runtime/cds/appcds/MultiProcessSharing.java
! test/hotspot/jtreg/runtime/cds/appcds/MultiReleaseJars.java
! test/hotspot/jtreg/runtime/cds/appcds/OldClassTest.java
! test/hotspot/jtreg/runtime/cds/appcds/ParallelLoad2.java
! test/hotspot/jtreg/runtime/cds/appcds/ParallelLoadTest.java
! test/hotspot/jtreg/runtime/cds/appcds/PrintSharedArchiveAndExit.java
! test/hotspot/jtreg/runtime/cds/appcds/ProtectionDomain.java
! test/hotspot/jtreg/runtime/cds/appcds/RelativePath.java
! test/hotspot/jtreg/runtime/cds/appcds/RewriteBytecodesTest.java
! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java
! test/hotspot/jtreg/runtime/cds/appcds/SharedBaseAddress.java
! test/hotspot/jtreg/runtime/cds/appcds/SharedPackages.java
! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java
! test/hotspot/jtreg/runtime/cds/appcds/SpecifySysLoaderProp.java
! test/hotspot/jtreg/runtime/cds/appcds/TestWithProfiler.java
! test/hotspot/jtreg/runtime/cds/appcds/TraceLongClasspath.java
! test/hotspot/jtreg/runtime/cds/appcds/VerifierTest_0.java
! test/hotspot/jtreg/runtime/cds/appcds/VerifierTest_1A.java
! test/hotspot/jtreg/runtime/cds/appcds/VerifierTest_1B.java
! test/hotspot/jtreg/runtime/cds/appcds/VerifierTest_2.java
! test/hotspot/jtreg/runtime/cds/appcds/WideIloadTest.java
! test/hotspot/jtreg/runtime/cds/appcds/WrongClasspath.java
! test/hotspot/jtreg/runtime/cds/appcds/XShareAutoWithChangedJar.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleComboTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleCompareTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/CheckCachedMirrorTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/CheckCachedResolvedReferences.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/DumpTimeVerifyFailure.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/GCStressTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/MirrorWithReferenceFieldsTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/OpenArchiveRegion.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/PrimitiveTypesTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/RedefineClassTest.java
! test/hotspot/jtreg/runtime/cds/appcds/condy/CondyHelloTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatA.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatB.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatC.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatD.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatE.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/HelloCustom.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/LoaderSegregationTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ParallelTestMultiFP.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ParallelTestSingleFP.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ProhibitedPackageNamesTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ProtectionDomain.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/SameNameInTwoLoadersTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnintendedLoadersTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnloadUnregisteredLoaderTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnsupportedPlatforms.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/AppendClasspath.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicFlag.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicLotsOfClasses.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/JITInteraction.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/MainModuleOnly.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/RelativePath.java
! test/hotspot/jtreg/runtime/cds/appcds/javaldr/AnonVmClassesDuringDump.java
! test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCDuringDump.java
! test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java
! test/hotspot/jtreg/runtime/cds/appcds/javaldr/HumongousDuringDump.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/CheckUnsupportedDumpingOptions.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/JigsawOptionsCombo.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/PatchModule/AppClassInCP.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/PatchModule/CustomPackage.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/PatchModule/MismatchedPatchModule.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/PatchModule/PatchDir.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/PatchModule/PatchJavaBase.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/PatchModule/Simple.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/PatchModule/SubClassOfPatchedClass.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/PatchModule/TwoJars.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/classpathtests/BootAppendTests.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/classpathtests/ClassPathTests.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddModules.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddOpens.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddReads.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ExportModule.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/JvmtiAddPath.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/MainModuleOnly.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/overridetests/OverrideTests.java
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/parallelLoad/ParallelLoadAndTransformTest.java
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/transformRelatedClasses/TransformInterfaceImplementorAppCDS.java
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/transformRelatedClasses/TransformSuperSubAppCDS.java
! test/hotspot/jtreg/runtime/cds/appcds/redefineClass/RedefineBasicTest.java
! test/hotspot/jtreg/runtime/cds/appcds/redefineClass/RedefineRunningMethods_Shared.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/FlagCombo.java
! test/hotspot/jtreg/runtime/cds/serviceability/transformRelatedClasses/TransformInterfaceAndImplementor.java
! test/hotspot/jtreg/runtime/cds/serviceability/transformRelatedClasses/TransformSuperAndSubClasses.java
! test/hotspot/jtreg/runtime/cds/serviceability/transformRelatedClasses/TransformSuperSubTwoPckgs.java

Changeset: 7ac414640ad5
Author:    jjg
Date:      2019-08-09 15:22 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/7ac414640ad5

8229386: Typo "lables" in doc comment
Reviewed-by: mchung

! src/jdk.compiler/share/classes/com/sun/source/tree/CaseTree.java

Changeset: 155b084cf384
Author:    thartmann
Date:      2019-08-12 08:48 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/155b084cf384

8225670: compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type"
Summary: Clear entry in the ciProfileData object if the klass is NULL.
Reviewed-by: eosterlund, thartmann

! src/hotspot/share/ci/ciMethodData.cpp
! test/hotspot/jtreg/ProblemList.txt

Changeset: 05ff6e27de45
Author:    mdoerr
Date:      2019-08-12 10:02 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/05ff6e27de45

8229236: CriticalJNINatives: dll handling should be done in native thread state
Summary: Temporarily switch thread state from _thread_in_vm to _thread_in_native to execute I/O.
Reviewed-by: dlong, dholmes

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/zero/sharedRuntime_zero.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/prims/nativeLookup.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp

Changeset: 8ebc8f74f2d2
Author:    pliden
Date:      2019-08-12 10:49 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8ebc8f74f2d2

8229406: ZGC: Fix incorrect statistics
Reviewed-by: pliden, eosterlund
Contributed-by: albert.th at alibaba-inc.com

! src/hotspot/share/gc/z/zStat.cpp

Changeset: 145300cc8ea6
Author:    mbaesken
Date:      2019-08-09 15:39 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/145300cc8ea6

8219082: jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace()
Reviewed-by: mdoerr, mseledtsov

! test/jdk/jdk/jfr/event/runtime/TestShutdownEvent.java

Changeset: 0211b062843d
Author:    michaelm
Date:      2019-08-12 11:24 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/0211b062843d

8185898: setRequestProperty(key, null) results in HTTP header without colon in request
Reviewed-by: chegar, dfuchs

! src/java.base/share/classes/sun/net/www/MessageHeader.java
+ test/jdk/sun/net/www/B8185898.java

Changeset: 9f44485e7441
Author:    redestad
Date:      2019-08-12 15:27 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9f44485e7441

8229407: Avoid ConcurrentHashMap resizes during bootstrap
Reviewed-by: alanb, shade, dfuchs

! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java
! src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java

Changeset: 6390e7056d12
Author:    shade
Date:      2019-08-12 20:27 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/6390e7056d12

8229416: Shenandoah: Demote or remove ShenandoahOptimize*Final optimizations
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: bfcdcd00e4fb
Author:    rkennke
Date:      2019-08-12 23:37 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/bfcdcd00e4fb

8228369: Shenandoah: Refactor LRB C1 stubs
Reviewed-by: shade

! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp

Changeset: a93b7b28f644
Author:    xuelei
Date:      2019-08-12 21:36 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/a93b7b28f644

8226374: Restrict TLS signature schemes and named groups
Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ssl/CertificateMessage.java
! src/java.base/share/classes/sun/security/ssl/CertificateRequest.java
! src/java.base/share/classes/sun/security/ssl/CertificateVerify.java
! src/java.base/share/classes/sun/security/ssl/CipherSuite.java
! src/java.base/share/classes/sun/security/ssl/DHKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/ECPointFormatsExtension.java
! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java
! src/java.base/share/classes/sun/security/ssl/NamedGroup.java
! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java
! src/java.base/share/classes/sun/security/ssl/SupportedGroupsExtension.java
! src/java.base/share/classes/sun/security/ssl/XDHKeyExchange.java
! src/java.base/share/classes/sun/security/util/CurveDB.java
! src/java.base/share/conf/security/java.security
+ test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java
+ test/jdk/sun/security/ssl/CipherSuite/RestrictSignatureScheme.java

Changeset: 75375b6617e6
Author:    thartmann
Date:      2019-08-13 08:25 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/75375b6617e6

8229447: Problem list compiler/unsafe/UnsafeGetConstantField.java on Sparc until JDK-8229446 is fixed
Summary: Problem list a test.
Reviewed-by: dholmes

! test/hotspot/jtreg/ProblemList.txt

Changeset: 4fbcbd248c52
Author:    thartmann
Date:      2019-08-13 09:54 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/4fbcbd248c52

8228772: C2 compilation fails due to unschedulable graph if DominatorSearchLimit is reached
Summary: Ignore membar if the load is already control dependent on it.
Reviewed-by: neliasso, kvn

! src/hotspot/share/opto/gcm.cpp
+ test/hotspot/jtreg/compiler/controldependency/TestAntiDependentMembar.java

Changeset: 8e51da27b53a
Author:    thartmann
Date:      2019-08-13 09:56 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8e51da27b53a

8224957: C2 compilation fails with assert: Bad graph detected in build_loop_late
Summary: Disable walking up the dominator chain for regions with more than 2 input paths.
Reviewed-by: roland, kvn

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/node.cpp
+ test/hotspot/jtreg/compiler/eliminateAutobox/TestSplitThroughPhi.java

Changeset: 54a04db114d8
Author:    jlahoda
Date:      2019-08-13 10:27 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/54a04db114d8

8227922: DocTreeScanner does not dive into AttributeTree.getValue() and LiteralTree.getBody()
Summary: DocTreeScanner.visitAttribute and visitLiteral have to scan through the subnodes of AttributeTree and LiteralTree, respectivelly.
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
! src/jdk.compiler/share/classes/com/sun/tools/doclint/Checker.java
! test/langtools/tools/javac/tree/AbstractTreeScannerTest.java
! test/langtools/tools/javac/tree/JavacTreeScannerTest.java
+ test/langtools/tools/javac/tree/SourceDocTreeScannerTest.java
! test/langtools/tools/javac/tree/SourceTreeScannerTest.java

Changeset: 447d48371b41
Author:    jlahoda
Date:      2019-08-13 10:27 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/447d48371b41

8228647: Broken enum produce inconvenient errors and AST
Summary: Improving error recovery for misplace members in enums.
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/langtools/tools/javac/T4994049/T4994049.java
! test/langtools/tools/javac/T4994049/T4994049.out
+ test/langtools/tools/javac/diags/examples/EnumConstantExpected.java
+ test/langtools/tools/javac/diags/examples/EnumConstantNotExpected.java
! test/langtools/tools/javac/enum/EnumMembersOrder.out
! test/langtools/tools/javac/parser/JavacParserTest.java

Changeset: ffc34eaf7b49
Author:    jlahoda
Date:      2019-08-13 10:27 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/ffc34eaf7b49

8228502: javac crashed on a broken classfile with ConstantValue attribute on a field of type Object
Summary: Produce an error when reading a classfile with a field with ConstantValue with a wrong type.
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/javac/classfiles/attributes/ConstantValue/BrokenConstantValue.java
+ test/langtools/tools/javac/classfiles/attributes/ConstantValue/BrokenConstantValue.out
+ test/langtools/tools/javac/classfiles/attributes/ConstantValue/HasBrokenConstantValue.jcod
+ test/langtools/tools/javac/diags/examples/BadConstantValueType/BadConstantValueType.java
+ test/langtools/tools/javac/diags/examples/BadConstantValueType/processors/CreateBadClassFile.java

Changeset: f3630a2d3d5c
Author:    shade
Date:      2019-08-13 14:59 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/f3630a2d3d5c

8229419: Shenandoah: Cleanup LRB strength selector code
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp

Changeset: 9c0715c5bbf3
Author:    rkennke
Date:      2019-08-13 16:05 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9c0715c5bbf3

8229470: Shenandoah: Fix C1 getAndSetObject() failure
Reviewed-by: shade

! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp
! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp

Changeset: 0ec272e1822e
Author:    aefimov
Date:      2019-08-13 16:11 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/0ec272e1822e

8228508: [TESTBUG] java/net/httpclient/SmokeTest.java fails on Windows7
Reviewed-by: dfuchs, chegar

! test/jdk/com/sun/net/httpserver/EchoHandler.java
! test/jdk/java/net/httpclient/SmokeTest.java

Changeset: a414a1b8884a
Author:    dfuchs
Date:      2019-08-13 16:18 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/a414a1b8884a

8229348: java/net/DatagramSocket/UnreferencedDatagramSockets.java fails intermittently
Summary: The test was observed blocking on receive and is updated to avoid using the wildcard address
Reviewed-by: chegar, msheppar

! test/jdk/java/net/DatagramSocket/UnreferencedDatagramSockets.java

Changeset: 23e13076e102
Author:    zgu
Date:      2019-08-13 13:01 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/23e13076e102

8229474: Shenandoah: Cleanup CM::update_roots()
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp

Changeset: be8c11fc16bb
Author:    naoto
Date:      2019-08-13 10:10 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/be8c11fc16bb

8211990: DateTimeException thrown when calculating duration between certain dates
Reviewed-by: lancea, scolebourne, rriggs

! src/java.base/share/classes/java/time/OffsetDateTime.java
! src/java.base/share/classes/java/time/ZonedDateTime.java
! test/jdk/java/time/test/java/time/TestOffsetDateTime.java
! test/jdk/java/time/test/java/time/TestZonedDateTime.java

Changeset: 18f4d3d46d54
Author:    dcubed
Date:      2019-08-13 16:13 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/18f4d3d46d54

8229212: clear up CHECK_OWNER confusion in objectMonitor.cpp
Reviewed-by: dholmes, coleenp

! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/objectMonitor.inline.hpp
! src/hotspot/share/runtime/synchronizer.cpp
+ test/hotspot/jtreg/runtime/Monitor/NonOwnerOps.java

Changeset: 7ba5e49258de
Author:    mchung
Date:      2019-08-13 15:49 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/7ba5e49258de

8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works
8209078: Unable to call default method from interface in another module from named module
Reviewed-by: dfuchs, plevart

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+ test/jdk/java/lang/invoke/findSpecial/FindSpecialTest.java
+ test/jdk/java/lang/invoke/findSpecial/m1/module-info.java
+ test/jdk/java/lang/invoke/findSpecial/m1/test/FindSpecial.java

Changeset: 7f75db20c209
Author:    valeriep
Date:      2019-08-14 00:57 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/7f75db20c209

8228613: java.security.Provider#getServices order is no longer deterministic
Summary: Changed to use SunEntries.DEF_SECURE_RANDOM_ALGO instead of relying on ordering of SecureRandom services
Reviewed-by: weijun

! src/java.base/share/classes/java/security/SecureRandom.java
! src/java.base/share/classes/sun/security/provider/SunEntries.java
+ test/jdk/java/security/SecureRandom/DefaultAlgo.java

Changeset: 6bbb4af131e3
Author:    valeriep
Date:      2019-08-14 01:40 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/6bbb4af131e3

8228835: Memory leak in PKCS11 provider when using AES GCM
Summary: updated freeCKMechanismPtr to free mechanism-specific memories
Reviewed-by: jnimeh

! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11wrapper.h

Changeset: 807d192fb7dd
Author:    dholmes
Date:      2019-08-14 00:18 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/807d192fb7dd

8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor
Reviewed-by: kbarrett, dcubed, pliden

! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/posix/os_posix.hpp
! src/hotspot/os/posix/os_posix.inline.hpp
! src/hotspot/os/solaris/os_solaris.cpp
! src/hotspot/os/solaris/os_solaris.hpp
! src/hotspot/os/windows/os_windows.hpp
! src/hotspot/os/windows/os_windows.inline.hpp

Changeset: 6717d7e59db4
Author:    prappo
Date:      2019-08-14 11:14 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/6717d7e59db4

8217606: LdapContext#reconnect always opens a new connection
Reviewed-by: lancea, vtewari, rriggs
Contributed-by: Chris Yin <xu.y.yin at oracle.com>

! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java
+ test/jdk/com/sun/jndi/ldap/LdapCtx/Reconnect.java
+ test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java
+ test/jdk/com/sun/jndi/ldap/lib/LdapMessage.java

Changeset: 789e967c2731
Author:    coleenp
Date:      2019-08-14 10:07 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/789e967c2731

5103339: Strengthen NoSafepointVerifier
Summary: Add NSV check at possible safepoint transition or places that could take out locks.  Consolidate with clearing unhandled oops.
Reviewed-by: dholmes, rehn

! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/vtableStubs.cpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/oops/objArrayKlass.cpp
! src/hotspot/share/oops/typeArrayKlass.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/prims/jvmtiThreadState.inline.hpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/jniHandles.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: 5a9af5262566
Author:    lancea
Date:      2019-08-14 12:57 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/5a9af5262566

8184432: Remove references to jdbc at sun.com from javax.sql.rowset.spi.SyncProvider
Reviewed-by: rriggs

! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProvider.java

Changeset: 9bddbd69351c
Author:    shade
Date:      2019-08-14 20:32 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9bddbd69351c

8229709: x86_32 build and test failures after JDK-8228369 (Shenandoah: Refactor LRB C1 stubs)
Reviewed-by: rkennke

! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp

Changeset: ececb6dae777
Author:    shade
Date:      2019-08-14 20:32 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/ececb6dae777

8229707: [TESTBUG] Some Shenandoah tests assume Server VM by default
Reviewed-by: rkennke

! test/hotspot/jtreg/gc/shenandoah/compiler/TestWriteBarrierClearControl.java
! test/hotspot/jtreg/gc/shenandoah/options/TestLoopMiningArguments.java

Changeset: 7284b00e6db3
Author:    dholmes
Date:      2019-08-14 18:26 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/7284b00e6db3

8228858: Reimplement JVM_RawMonitors to use PlatformMutex
Reviewed-by: coleenp, dcubed, pchilanomate

! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/park.cpp

Changeset: 76ff3491e3b8
Author:    jwilhelm
Date:      2019-08-15 03:57 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/76ff3491e3b8

Added tag jdk-14+10 for changeset ececb6dae777

! .hgtags

Changeset: 902cef494e66
Author:    ngasson
Date:      2019-08-15 14:00 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/902cef494e66

8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64
Reviewed-by: cjplummer, adinn

! test/hotspot/jtreg/serviceability/sa/ClhsdbFindPC.java
+ test/hotspot/jtreg/serviceability/sa/LingeredAppWithTrivialMain.java

Changeset: 91a758925be7
Author:    rehn
Date:      2019-08-15 09:06 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/91a758925be7

8225788: Dead code in thread and safepoint
Reviewed-by: dholmes, dcubed, coleenp

! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/safepoint.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vframe_hp.cpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/runtime/vmThread.cpp

Changeset: 22fa46d5dc2e
Author:    weijun
Date:      2019-08-15 15:39 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/22fa46d5dc2e

8229767: Typo in java.security: Sasl.createClient and Sasl.createServer
Reviewed-by: xuelei

! src/java.base/share/conf/security/java.security

Changeset: ec948d19180a
Author:    dfuchs
Date:      2019-08-15 12:58 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/ec948d19180a

8229486: Replace wildcard address with loopback or local host in tests - part 21
Reviewed-by: chegar

! test/jdk/java/net/SocketOption/TcpKeepAliveTest.java
! test/jdk/java/net/URLConnection/SetIfModifiedSince.java
! test/jdk/sun/net/www/http/HttpClient/GetProxyPort.java
! test/jdk/sun/net/www/http/HttpClient/ImplicitFileName.java
! test/jdk/sun/net/www/http/HttpClient/IsAvailable.java
! test/jdk/sun/net/www/http/HttpClient/IsKeepingAlive.java
! test/jdk/sun/net/www/http/HttpClient/OpenServer.java
! test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java
! test/jdk/sun/net/www/protocol/http/StreamingOutputStream.java
! test/jdk/sun/net/www/protocol/http/UserAuth.java
! test/jdk/sun/net/www/protocol/http/UserCookie.java

Changeset: 7a700a9a89f2
Author:    jlahoda
Date:      2019-08-15 14:35 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/7a700a9a89f2

8226848: jline/terminal/impl files missing classpath exception clause in license header
Summary: Adding CPE to several files in jdk.internal.le.
Reviewed-by: jjg

! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/IntByReference.java
! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/Kernel32Impl.java
! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/LastErrorException.java
! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/Pointer.java

Changeset: 47511761bd04
Author:    mchung
Date:      2019-08-15 13:41 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/47511761bd04

8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767
Reviewed-by: coleenp, fparain, shade, plevart

! src/hotspot/share/classfile/javaClasses.cpp
! src/java.base/share/classes/java/lang/StackFrameInfo.java

Changeset: 2c66dbb94227
Author:    bobv
Date:      2019-08-15 19:29 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/2c66dbb94227

8229699: [Graal] jck tests fail on windows with AOTed Graal
Reviewed-by: kvn

! src/hotspot/os/windows/os_windows.cpp

Changeset: a89ec7fc99aa
Author:    ccheung
Date:      2019-08-15 16:23 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/a89ec7fc99aa

8226645: [TESTBUG] some AppCDS tests rely on illegal reflective access
Summary: Updated tests to use Lookup.defineClass instead of ClassLoader.defineClass.
Reviewed-by: iklam, dholmes, alanb

! test/hotspot/jtreg/runtime/cds/appcds/RewriteBytecodesTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/LoaderSegregationTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/LoaderSegregation.java
! test/hotspot/jtreg/runtime/cds/appcds/test-classes/RewriteBytecodes.java
! test/hotspot/jtreg/runtime/cds/appcds/test-classes/Util.java

Changeset: 81ce766c9111
Author:    weijun
Date:      2019-08-16 08:42 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/81ce766c9111

8229775: Incorrect warning when jar was signed with -sectionsonly
Reviewed-by: mullan

! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
+ test/jdk/sun/security/tools/jarsigner/SectionsOnly.java

Changeset: b3e44e1b135d
Author:    lkorinth
Date:      2019-08-16 09:18 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/b3e44e1b135d

8224659: Parallel GC: Use WorkGang (1: PCRefProcTask)
Reviewed-by: stefank, kbarrett, tschatzl

! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
! src/hotspot/share/gc/parallel/pcTasks.cpp
! src/hotspot/share/gc/parallel/pcTasks.hpp
! src/hotspot/share/gc/parallel/psCompactionManager.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! test/hotspot/jtreg/gc/ergonomics/TestInitialGCThreadLogging.java

Changeset: fc82b6cb8b14
Author:    lkorinth
Date:      2019-08-16 09:18 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/fc82b6cb8b14

8224660: Parallel GC: Use WorkGang (2: MarksFromRootsTask)
Reviewed-by: stefank, kbarrett, tschatzl

! src/hotspot/share/gc/parallel/pcTasks.cpp
! src/hotspot/share/gc/parallel/pcTasks.hpp
! src/hotspot/share/gc/parallel/psCompactionManager.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
+ src/hotspot/share/gc/parallel/psRootType.hpp

Changeset: f7ca942a2714
Author:    lkorinth
Date:      2019-08-16 09:18 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/f7ca942a2714

8224661: Parallel GC: Use WorkGang (3: UpdateDensePrefixAndCompactionTask)
Reviewed-by: stefank, kbarrett, tschatzl

- src/hotspot/share/gc/parallel/pcTasks.cpp
- src/hotspot/share/gc/parallel/pcTasks.hpp
! src/hotspot/share/gc/parallel/psCompactionManager.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp

Changeset: b5ca334ed54c
Author:    lkorinth
Date:      2019-08-16 09:18 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/b5ca334ed54c

8224662: Parallel GC: Use WorkGang (4: SharedRestorePreservedMarksTaskExecutor)
Reviewed-by: stefank, kbarrett, tschatzl

! src/hotspot/share/gc/parallel/psPromotionManager.cpp

Changeset: 50c959cc40e8
Author:    lkorinth
Date:      2019-08-16 09:18 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/50c959cc40e8

8224663: Parallel GC: Use WorkGang (5: ScavengeRootsTask)
Reviewed-by: stefank, kbarrett, tschatzl

! src/hotspot/share/gc/parallel/psCardTable.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.hpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/parallel/psTasks.cpp
! src/hotspot/share/gc/parallel/psTasks.hpp

Changeset: 2410b04f074f
Author:    lkorinth
Date:      2019-08-16 09:18 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/2410b04f074f

8224664: Parallel GC: Use WorkGang (6: PSRefProcTaskProxy)
Reviewed-by: stefank, kbarrett, tschatzl

! src/hotspot/share/gc/parallel/psCardTable.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.hpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
- src/hotspot/share/gc/parallel/psTasks.cpp
- src/hotspot/share/gc/parallel/psTasks.hpp

Changeset: 5cbc3bd9fdfd
Author:    lkorinth
Date:      2019-08-16 09:18 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/5cbc3bd9fdfd

8224665: Parallel GC: Use WorkGang (7: remove task manager)
Reviewed-by: stefank, kbarrett, tschatzl

- src/hotspot/share/gc/parallel/gcTaskManager.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.hpp
- src/hotspot/share/gc/parallel/gcTaskThread.cpp
- src/hotspot/share/gc/parallel/gcTaskThread.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
! src/hotspot/share/gc/parallel/parallel_globals.hpp
! src/hotspot/share/gc/parallel/psCardTable.cpp
! src/hotspot/share/gc/parallel/psCardTable.hpp
! src/hotspot/share/gc/parallel/psCompactionManager.cpp
! src/hotspot/share/gc/parallel/psCompactionManager.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp
! src/hotspot/share/gc/parallel/psPromotionManager.cpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/parallel/psScavenge.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: 21dccfac0ec5
Author:    lkorinth
Date:      2019-08-16 09:18 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/21dccfac0ec5

8224666: Parallel GC: Use WorkGang (8: obsolete and remove flags)
Reviewed-by: stefank, kbarrett, tschatzl

! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/runtime/arguments.cpp

Changeset: 90ead0febf56
Author:    stefank
Date:      2019-08-06 10:48 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/90ead0febf56

8229258: Rework markOop and markOopDesc into a simpler mark word value carrier
Reviewed-by: rkennke, coleenp, kbarrett, dcubed

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.hpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/sparc/c1_MacroAssembler_sparc.cpp
! src/hotspot/cpu/sparc/interp_masm_sparc.cpp
! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/sparc/templateTable_sparc.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/zero/cppInterpreter_zero.cpp
! src/hotspot/share/classfile/altHashing.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/gc/cms/compactibleFreeListSpace.hpp
! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp
! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.hpp
! src/hotspot/share/gc/cms/freeChunk.hpp
! src/hotspot/share/gc/cms/parNewGeneration.cpp
! src/hotspot/share/gc/cms/parNewGeneration.hpp
! src/hotspot/share/gc/cms/parOopClosures.inline.hpp
! src/hotspot/share/gc/cms/promotionInfo.cpp
! src/hotspot/share/gc/cms/promotionInfo.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp
! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp
! src/hotspot/share/gc/parallel/psMarkSweepDecorator.cpp
! src/hotspot/share/gc/parallel/psPromotionLAB.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.hpp
! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/parallel/psYoungGen.cpp
! src/hotspot/share/gc/serial/markSweep.cpp
! src/hotspot/share/gc/serial/markSweep.hpp
! src/hotspot/share/gc/serial/markSweep.inline.hpp
! src/hotspot/share/gc/shared/ageTable.cpp
! src/hotspot/share/gc/shared/ageTable.hpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shared/generation.cpp
! src/hotspot/share/gc/shared/generation.hpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/preservedMarks.cpp
! src/hotspot/share/gc/shared/preservedMarks.hpp
! src/hotspot/share/gc/shared/preservedMarks.inline.hpp
! src/hotspot/share/gc/shared/space.cpp
! src/hotspot/share/gc/shared/space.inline.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp
! src/hotspot/share/interpreter/bytecodeInterpreter.cpp
! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp
! src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp
! src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp
! src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp
! src/hotspot/share/jfr/leakprofiler/chains/objectSampleMarker.hpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp
! src/hotspot/share/jfr/leakprofiler/utilities/saveRestore.cpp
! src/hotspot/share/jfr/leakprofiler/utilities/saveRestore.hpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/memory/heapShared.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/oops/arrayOop.hpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/klass.inline.hpp
! src/hotspot/share/oops/markOop.cpp
! src/hotspot/share/oops/markOop.hpp
! src/hotspot/share/oops/markOop.inline.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/objArrayOop.hpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/oops/oopsHierarchy.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/basicLock.cpp
! src/hotspot/share/runtime/basicLock.hpp
! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/biasedLocking.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/objectMonitor.inline.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/vframe.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Mark.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
! test/hotspot/gtest/gc/shared/test_preservedMarks.cpp
! test/hotspot/gtest/oops/test_markOop.cpp
! test/hotspot/jtreg/serviceability/sa/ClhsdbAttach.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbLongConstant.java

Changeset: 6768b0f490df
Author:    dfuchs
Date:      2019-08-16 15:01 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/6768b0f490df

8229481: sun/net/www/protocol/https/ChunkedOutputStream.java failed with a SSLException
Summary: The test is updated to ignore plain text connections
Reviewed-by: chegar, michaelm

! test/jdk/sun/net/www/protocol/https/ChunkedOutputStream.java
! test/jdk/sun/net/www/protocol/https/HttpCallback.java
! test/jdk/sun/net/www/protocol/https/TestHttpsServer.java

Changeset: 0a8407a78a2f
Author:    eosterlund
Date:      2019-08-16 16:50 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/0a8407a78a2f

8229345: Memory leak due to vtable stubs not being shared on SPARC
Reviewed-by: mdoerr, dholmes, kvn

! src/hotspot/cpu/aarch64/globals_aarch64.hpp
! src/hotspot/cpu/arm/globals_arm.hpp
! src/hotspot/cpu/ppc/globals_ppc.hpp
! src/hotspot/cpu/s390/globals_s390.hpp
! src/hotspot/cpu/sparc/globals_sparc.hpp
! src/hotspot/cpu/x86/globals_x86.hpp
! src/hotspot/cpu/zero/globals_zero.hpp
! src/hotspot/share/code/vtableStubs.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: ca133d5ea78a
Author:    poonam
Date:      2019-08-16 18:06 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/ca133d5ea78a

8229420: [Redo] jstat reports incorrect values for OU for CMS GC
Reviewed-by: tschatzl, sgehwolf

! src/hotspot/share/gc/cms/cmsHeap.cpp
! src/hotspot/share/gc/cms/compactibleFreeListSpace.cpp
! src/hotspot/share/gc/cms/compactibleFreeListSpace.hpp
! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp
! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.hpp
! src/hotspot/share/gc/cms/gSpaceCounters.hpp
! src/hotspot/share/gc/shared/generation.cpp
! src/hotspot/share/gc/shared/generation.hpp

Changeset: a0257f1458aa
Author:    igerasim
Date:      2019-08-16 11:35 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/a0257f1458aa

8221307: String.substring() OOB exception on start index reports improper information
Reviewed-by: rriggs, redestad

! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/StringUTF16.java
+ test/micro/org/openjdk/bench/java/lang/StringSubstring.java

Changeset: 8d9362f3b8aa
Author:    kbarrett
Date:      2019-08-16 14:46 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/8d9362f3b8aa

8229044: G1RedirtyCardsQueueSet should be local to a collection
Summary: Stack allocate redirty qsets in do_collection_pause_at_safepoint.
Reviewed-by: tschatzl, sangheki

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1EvacFailure.cpp
! src/hotspot/share/gc/g1/g1EvacFailure.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.cpp
! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.hpp

Changeset: 948ac3112da8
Author:    srukmannagar
Date:      2019-08-16 14:42 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/948ac3112da8

8225625: AES Electronic Codebook (ECB) encryption and decryption optimization using AVX512 + VAES instructions
Summary: AES-ECB encryption and decryption optimization for x86_64 architectures supporting AVX3+VAES
Reviewed-by: kvn, valeriep
Contributed-by: shravya.rukmannagari at intel.com, smita.kamath at intel.com

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86_aes.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/classfile/vmSymbols.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java
! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java
! test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java

Changeset: 094ef5a91b68
Author:    dholmes
Date:      2019-08-16 18:27 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/094ef5a91b68

8229808: javaVFrame::print_lock_info_on fails to disable extra printing
Reviewed-by: hseigel, dcubed

! src/hotspot/share/runtime/vframe.cpp

Changeset: 34bbd91b1522
Author:    jnimeh
Date:      2019-08-17 06:20 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/34bbd91b1522

8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException
Reviewed-by: xuelei

! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java
+ test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/OutputSizeTest.java

Changeset: 1b6806340400
Author:    redestad
Date:      2019-08-19 06:13 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/1b6806340400

8229773: Resolve permissions for code source URLs lazily
Reviewed-by: alanb, mullan, rriggs, dfuchs

! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/security/CodeSource.java
! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java
+ src/java.base/share/classes/sun/security/util/LazyCodeSourcePermissionCollection.java

Changeset: d372747e8f08
Author:    dfuchs
Date:      2019-08-19 11:14 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/d372747e8f08

8191169: java/net/Authenticator/B4769350.java failed intermittently
Summary: fixed a race condition in AuthenticationInfo when serializeAuth=true
Reviewed-by: chegar, michaelm

! src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java
! test/jdk/java/net/Authenticator/B4769350.java
! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java
! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTest.java
! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTestServer.java

Changeset: ffdb18fb88b9
Author:    ysuenaga
Date:      2019-08-19 19:43 +0900
URL:       https://hg.openjdk.java.net/panama/dev/rev/ffdb18fb88b9

8226204: SA: Refactoring for option processing in SALauncher
Reviewed-by: cjplummer, sspitsyn

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/SALauncher.java

Changeset: 2e58f5d927a6
Author:    bulasevich
Date:      2019-08-19 15:36 +0300
URL:       https://hg.openjdk.java.net/panama/dev/rev/2e58f5d927a6

8229352: Use of an uninitialized register in 32-bit ARM template interpreter
Reviewed-by: dlong, shade
Contributed-by: christoph.goettschkes at microdoc.com

! src/hotspot/cpu/arm/templateTable_arm.cpp

Changeset: 56df9a08ed9c
Author:    chegar
Date:      2019-08-19 14:28 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/56df9a08ed9c

8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries
Reviewed-by: dfuchs, alanb, erikj

! make/lib/Lib-java.base.gmk
! src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
! src/java.base/windows/native/libnet/NTLMAuthentication.c
+ test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java

Changeset: d48a1703ad6e
Author:    fweimer
Date:      2019-08-16 21:20 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/d48a1703ad6e

8229835: Shenandoah should recommend -Xlog:safepoint+stats
Reviewed-by: shade
Contributed-by: Florian Weimer <fweimer at redhat.com>

! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp

Changeset: f0c73a5683e7
Author:    shade
Date:      2019-08-19 19:58 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/f0c73a5683e7

8229865: Use explicit #include debug.hpp for STATIC_ASSERT in gc/shenandoah/shenandoahUtils.cpp
Reviewed-by: zgu

! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp

Changeset: 7cc5a5b4eee9
Author:    xuelei
Date:      2019-08-19 12:56 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/7cc5a5b4eee9

8228757: Fail fast if the handshake type is unknown
Reviewed-by: jnimeh

! src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLHandshake.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java

Changeset: 0abdc5a425dd
Author:    darcy
Date:      2019-08-19 18:12 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/0abdc5a425dd

8202385: Annotation to mark serial-related fields and methods
Reviewed-by: rriggs, chegar, alanb

+ src/java.base/share/classes/java/io/Serial.java

Changeset: aff991f6e64d
Author:    thartmann
Date:      2019-08-20 07:47 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/aff991f6e64d

8228888: C2 compilation fails with assert "m has strange control"
Summary: Weakened too strong assert.
Reviewed-by: kvn, roland

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/StrangeControl.jasm
+ test/hotspot/jtreg/compiler/loopopts/TestStrangeControl.java

Changeset: 854e828d6b5b
Author:    tschatzl
Date:      2019-08-20 09:22 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/854e828d6b5b

8227442: Make young_index_in_cset zero-based
Summary: Avoid unnecessary increment of young_index_in_cset in copy_to_survivor_space.
Reviewed-by: kbarrett, sangheki

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectionSet.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
! src/hotspot/share/gc/g1/heapRegion.cpp
! src/hotspot/share/gc/g1/heapRegion.hpp

Changeset: 23e3ab980622
Author:    chagedorn
Date:      2019-08-20 10:46 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/23e3ab980622

8229158: make UseSwitchProfiling non-experimental or false by-default
Summary: Changed UseSwitchProfiling from experimental to diagnostic.
Reviewed-by: dholmes, shade, thartmann

! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/compiler/loopopts/LoopUnswitchingBadNodeBudget.java
! test/hotspot/jtreg/compiler/loopopts/TestOverunrolling.java

Changeset: 9b7b9f16dfd9
Author:    adinn
Date:      2019-08-20 10:11 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/9b7b9f16dfd9

8224974: Implement JEP 352
Summary: Non-Volatile Mapped Byte Buffers
Reviewed-by: alanb, kvn, bpb, gromero, darcy, shade, bulasevich, dchuyko

! make/common/Modules.gmk
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/globals_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/solaris/os_solaris.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/memnode.hpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp
! src/hotspot/share/runtime/vm_version.cpp
! src/hotspot/share/runtime/vm_version.hpp
! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
! src/java.base/share/classes/java/nio/MappedByteBuffer.java
+ src/java.base/share/classes/jdk/internal/misc/ExtendedMapMode.java
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java
! src/java.base/share/classes/module-info.java
! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java
! src/java.base/share/classes/sun/nio/ch/Util.java
! src/java.base/unix/native/libnio/ch/FileChannelImpl.c
! src/java.base/windows/native/libnio/ch/FileChannelImpl.c
! src/java.management/share/classes/sun/management/ManagementFactoryHelper.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
+ src/jdk.nio.mapmode/share/classes/jdk/nio/mapmode/ExtendedMapMode.java
+ src/jdk.nio.mapmode/share/classes/module-info.java
+ test/jdk/java/nio/MappedByteBuffer/MapSyncFail.java
+ test/jdk/java/nio/MappedByteBuffer/PmemTest.java

Changeset: e62f402c337f
Author:    dfuchs
Date:      2019-08-20 11:15 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/e62f402c337f

8229421: The logic of java/net/ipv6tests/TcpTest.java is flawed
Summary: The test is fixed to ignore rogue client connection. However it remains succeptible to intermittent failures due to the use of the wildcad address.
Reviewed-by: dfuchs
Contributed-by: Patrick Concannon <patrick.concannon at oracle.com>

! test/jdk/java/net/ipv6tests/TcpTest.java

Changeset: 947252a54b98
Author:    stefank
Date:      2019-08-19 11:30 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/947252a54b98

8229838: Rename markOop files to markWord
Reviewed-by: dholmes, rehn

! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/frame_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/frame_arm.cpp
! src/hotspot/cpu/arm/interp_masm_arm.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/frame_ppc.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/frame_s390.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/sparc/c1_MacroAssembler_sparc.cpp
! src/hotspot/cpu/sparc/frame_sparc.cpp
! src/hotspot/cpu/sparc/interp_masm_sparc.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86.cpp
! src/hotspot/cpu/zero/frame_zero.cpp
! src/hotspot/share/adlc/main.cpp
! src/hotspot/share/classfile/altHashing.cpp
! src/hotspot/share/gc/cms/freeChunk.hpp
! src/hotspot/share/gc/cms/promotionInfo.cpp
! src/hotspot/share/gc/g1/g1FullGCMarker.hpp
! src/hotspot/share/gc/g1/g1OopClosures.hpp
! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp
! src/hotspot/share/gc/serial/markSweep.hpp
! src/hotspot/share/gc/serial/markSweep.inline.hpp
! src/hotspot/share/gc/shared/ageTable.hpp
! src/hotspot/share/gc/shared/space.hpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp
! src/hotspot/share/jfr/leakprofiler/chains/objectSampleMarker.hpp
! src/hotspot/share/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp
! src/hotspot/share/jfr/leakprofiler/utilities/saveRestore.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/klass.inline.hpp
- src/hotspot/share/oops/markOop.cpp
- src/hotspot/share/oops/markOop.hpp
- src/hotspot/share/oops/markOop.inline.hpp
+ src/hotspot/share/oops/markWord.cpp
+ src/hotspot/share/oops/markWord.hpp
+ src/hotspot/share/oops/markWord.inline.hpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/runtime/basicLock.hpp
! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp
! src/hotspot/share/runtime/frame.cpp
! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/MonitorSnippets.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbLongConstant.java

Changeset: 9bb28ccc6106
Author:    stefank
Date:      2019-08-19 12:40 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9bb28ccc6106

8229839: Break circular dependency between oop.inline.hpp and markWord.inline.hpp
Reviewed-by: pliden, tonyp

! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp
! src/hotspot/share/gc/cms/promotionInfo.cpp
! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp
! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp
! src/hotspot/share/gc/serial/markSweep.inline.hpp
! src/hotspot/share/gc/shared/preservedMarks.inline.hpp
! src/hotspot/share/oops/markWord.hpp
! src/hotspot/share/oops/markWord.inline.hpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/prims/jvmtiTagMap.cpp

Changeset: 80fad5f39a42
Author:    stefank
Date:      2019-07-02 12:28 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/80fad5f39a42

8227086: Use AS_NO_KEEPALIVE loads in HeapDumper
Reviewed-by: kbarrett, sspitsyn

! src/hotspot/share/services/heapDumper.cpp

Changeset: 699b8ef42f30
Author:    godin
Date:      2019-08-20 15:54 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/699b8ef42f30

8152467: remove uses of anachronistic array declarations for method return type
Reviewed-by: shade, alanb
Contributed-by: Evgeny Mandrikov <mandrikov at gmail.com>

! src/java.base/share/classes/sun/text/CompactByteArray.java
! src/jdk.rmic/share/classes/sun/tools/java/BinaryAttribute.java
! src/jdk.rmic/share/classes/sun/tools/java/BinaryClass.java
! src/jdk.rmic/share/classes/sun/tools/java/BinaryCode.java
! src/jdk.rmic/share/classes/sun/tools/java/ClassDefinition.java
! src/jdk.rmic/share/classes/sun/tools/java/MethodType.java
! src/jdk.rmic/share/classes/sun/tools/java/Parser.java
! src/jdk.rmic/share/classes/sun/tools/java/Type.java

Changeset: 348f7933e2cc
Author:    dfuchs
Date:      2019-08-20 15:40 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/348f7933e2cc

8229916: Delete redundant test java/net/Socket/reset/Test.java
Summary: remove java/net/Socket/reset/Test.java which misses an @test tag and is obsoleted by java/net/Socket/ConnectionReset.java
Reviewed-by: alanb
Contributed-by: Patrick Concannon <patrick.concannon at oracle.com>

- test/jdk/java/net/Socket/reset/Test.java

Changeset: a445d4305fad
Author:    aeubanks
Date:      2019-08-19 16:08 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/a445d4305fad

8229899: Make java.io.File.isInvalid() less racy
Reviewed-by: alanb, martin, shade

! src/java.base/share/classes/java/io/File.java

Changeset: 1ba30faf88e5
Author:    rkennke
Date:      2019-08-20 18:39 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/1ba30faf88e5

8229921: Shenandoah: Make Traversal mode non-experimental
Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp
! test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java

Changeset: c83245fe66b3
Author:    lmesnik
Date:      2019-08-20 11:36 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/c83245fe66b3

8229854: Move runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java out of tier1_runtime
Reviewed-by: dholmes

! test/hotspot/jtreg/TEST.groups

Changeset: 40006c0ada91
Author:    godin
Date:      2019-08-21 00:08 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/40006c0ada91

8139820: URLClassPath.FileLoader constructor redundantly checks protocol
Reviewed-by: chegar, redestad

! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java

Changeset: 182f94955cfb
Author:    sundar
Date:      2019-08-21 17:38 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/182f94955cfb

8220700: jlink generated launcher script needs quoting to avoid parameter expansion
Reviewed-by: mchung, alanb, sgehwolf

! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java
! test/jdk/tools/jlink/basic/BasicTest.java
+ test/jdk/tools/jlink/basic/src/test/jdk/test/Adder.java

Changeset: df3397f95387
Author:    bulasevich
Date:      2019-08-21 17:09 +0300
URL:       https://hg.openjdk.java.net/panama/dev/rev/df3397f95387

8229254: solaris_x64 build fails after JDK-8191278
Reviewed-by: kbarrett, dholmes

! src/hotspot/os/solaris/os_solaris.cpp
! src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp

Changeset: efb2770e8288
Author:    hseigel
Date:      2019-08-21 11:29 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/efb2770e8288

8229930: internal_name() in annotations.hpp returns "{constant pool}"
Summary: Fix typo and change text to "{annotations}"
Reviewed-by: mdoerr, dcubed

! src/hotspot/share/oops/annotations.cpp
! src/hotspot/share/oops/annotations.hpp

Changeset: 253c817653b6
Author:    rkennke
Date:      2019-08-21 18:05 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/253c817653b6

8229977: Shenandoah: save/restore FPU state aroud LRB runtime call
Reviewed-by: shade

! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp

Changeset: 8c73d2a46ba9
Author:    amenkov
Date:      2019-08-21 12:34 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/8c73d2a46ba9

8228547: accessibility errors in jvmti.html
Reviewed-by: jcbeyler, sspitsyn, dholmes

! src/hotspot/share/prims/jvmti.xml
! src/hotspot/share/prims/jvmti.xsl

Changeset: bf4c808a4488
Author:    igerasim
Date:      2019-08-21 13:49 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/bf4c808a4488

8211360: Change #if DEF to #if defined(DEF)
Reviewed-by: bpb, vtewari

! src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template
! src/java.base/share/native/libfdlibm/fdlibm.h
! src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c
! src/java.base/windows/native/libjava/java_props_md.c
! src/java.security.jgss/share/native/libj2gss/gssapi.h
! src/jdk.sctp/unix/native/libsctp/SctpNet.c

Changeset: 425412369353
Author:    rriggs
Date:      2019-08-21 16:19 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/425412369353

8207814: (proxy) upgrade the proxy class generator
Reviewed-by: mchung

! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/lang/reflect/Proxy.java
! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
+ src/java.base/share/classes/java/lang/reflect/ProxyGenerator_v49.java
+ test/jdk/java/lang/reflect/Proxy/ProxyGeneratorCombo.java
+ test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyBench.java
+ test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyPerf.java

Changeset: 35db8fba55f9
Author:    kbarrett
Date:      2019-08-21 18:42 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/35db8fba55f9

8227054: ServiceThread needs to know about all OopStorage objects
8227053: ServiceThread cleanup of OopStorage is missing some
Summary: OopStorages provides named access and iteration.
Reviewed-by: eosterlund, pliden, coleenp

! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/stringTable.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/gc/shared/oopStorageParState.hpp
+ src/hotspot/share/gc/shared/oopStorageSet.cpp
+ src/hotspot/share/gc/shared/oopStorageSet.hpp
! src/hotspot/share/gc/shared/weakProcessor.cpp
! src/hotspot/share/gc/shared/weakProcessor.inline.hpp
! src/hotspot/share/gc/shared/weakProcessorPhaseTimes.cpp
! src/hotspot/share/gc/shared/weakProcessorPhaseTimes.hpp
! src/hotspot/share/gc/shared/weakProcessorPhases.cpp
! src/hotspot/share/gc/shared/weakProcessorPhases.hpp
! src/hotspot/share/gc/z/zRootsIterator.cpp
! src/hotspot/share/jvmci/jvmci.cpp
! src/hotspot/share/jvmci/jvmci.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/weakHandle.cpp
! src/hotspot/share/prims/resolvedMethodTable.cpp
! src/hotspot/share/prims/resolvedMethodTable.hpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/jniHandles.cpp
! src/hotspot/share/runtime/jniHandles.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! src/hotspot/share/runtime/serviceThread.cpp
+ test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp
! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java

Changeset: 58891103f9cc
Author:    kbarrett
Date:      2019-08-21 19:21 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/58891103f9cc

8189633: Missing -Xcheck:jni checking for DeleteWeakGlobalRef
Summary: Added validity check on the handle before deleting it.
Reviewed-by: dholmes, dcubed

! src/hotspot/share/prims/jniCheck.cpp

Changeset: 26ada504269a
Author:    jwilhelm
Date:      2019-08-22 02:05 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/26ada504269a

Added tag jdk-14+11 for changeset bf4c808a4488

! .hgtags

Changeset: d41c18a68257
Author:    kvn
Date:      2019-08-21 18:03 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/d41c18a68257

8229848: [Graal] missing Graal intrinsics for Electronic Code Book (ECB) encryption
Summary: new intrinsics were added to Graal test
Reviewed-by: dlong

! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

Changeset: da4cf75505a7
Author:    ngasson
Date:      2019-08-22 10:53 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/da4cf75505a7

8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6
Reviewed-by: alanb, dfuchs

! test/jdk/java/net/Socks/SocksIPv6Test.java

Changeset: 3283cff319c8
Author:    thartmann
Date:      2019-08-22 12:22 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/3283cff319c8

8230020: [BACKOUT] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type"
Summary: Back out JDK-8225670 due to performance regressions.
Reviewed-by: roland

! src/hotspot/share/ci/ciMethodData.cpp
! test/hotspot/jtreg/ProblemList.txt

Changeset: e686b661fa05
Author:    thartmann
Date:      2019-08-22 12:24 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/e686b661fa05

8224624: Inefficiencies in CodeStrings::add_comment cause timeouts
Summary: Changing CodeStrings to a doubly-linked-list and searching for the comment with the right offset in reverse.
Reviewed-by: kvn

! src/hotspot/share/asm/codeBuffer.cpp
! src/hotspot/share/asm/codeBuffer.hpp

Changeset: c2bc7b07c67a
Author:    rehn
Date:      2019-08-22 12:46 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/c2bc7b07c67a

8229967: Enable thread local handshakes on zero
Reviewed-by: sgehwolf, shade

! src/hotspot/cpu/zero/globalDefinitions_zero.hpp
! src/hotspot/cpu/zero/globals_zero.hpp

Changeset: e70dec4229e9
Author:    shade
Date:      2019-08-22 13:47 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/e70dec4229e9

8230024: Shenandoah: remove unnecessary ShenandoahTimingConverter
Reviewed-by: rkennke, zgu

! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: 2227a0cfd6b3
Author:    shade
Date:      2019-08-22 13:47 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/2227a0cfd6b3

8229998: Build failure after JDK-8227054
Reviewed-by: rkennke, zgu

! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp

Changeset: 78844dceede6
Author:    michaelm
Date:      2019-08-22 14:36 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/78844dceede6

8199849: Add support for UTF-8 encoded credentials in HTTP Basic Authentication
Reviewed-by: chegar, dfuchs

! src/java.base/share/classes/sun/net/www/protocol/http/BasicAuthentication.java
! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java
! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java
+ test/jdk/com/sun/net/httpserver/bugs/8199849/BasicAuthenticatorCharset.java
+ test/jdk/com/sun/net/httpserver/bugs/8199849/ParamTest.java
+ test/jdk/com/sun/net/httpserver/bugs/8199849/TestHttpUnicode.java

Changeset: de0ccdc4db13
Author:    mdoerr
Date:      2019-08-22 15:52 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/de0ccdc4db13

8229925: [s390, PPC64] Exception check missing in interpreter
Reviewed-by: dholmes, rrich

! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp

Changeset: 4863a802a7c1
Author:    coleenp
Date:      2019-08-22 09:51 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/4863a802a7c1

8230003: Make Monitor inherit from Mutex
Summary: Reverse inheritance that makes more sense.
Reviewed-by: dholmes, rehn, pchilanomate

! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: 0094711309c3
Author:    coleenp
Date:      2019-08-22 09:53 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/0094711309c3

Merge


Changeset: abf6ee4c477c
Author:    lancea
Date:      2019-08-22 10:43 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/abf6ee4c477c

8229887: (zipfs) zip file corruption when replacing an existing STORED entry
Reviewed-by: alanb, redestad, dfuchs

! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
+ test/jdk/jdk/nio/zipfs/UpdateEntryTest.java

Changeset: d6a422987d86
Author:    mseledtsov
Date:      2019-08-22 10:35 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/d6a422987d86

8226779: [TESTBUG] Test JFR API from Java agent
Summary: Created new tests for JFR plus Java Agent
Reviewed-by: egahlin

+ test/jdk/jdk/jfr/javaagent/EventEmitterAgent.java
+ test/jdk/jdk/jfr/javaagent/JavaAgentBuilder.java
+ test/jdk/jdk/jfr/javaagent/TestLoadedAgent.java
+ test/jdk/jdk/jfr/javaagent/TestPremainAgent.java

Changeset: 3bc26ffdf001
Author:    lmesnik
Date:      2019-08-22 10:40 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/3bc26ffdf001

8229957: Harden pid verification in attach mechanism
Reviewed-by: sspitsyn, ysuenaga, sgehwolf

! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java
+ test/hotspot/jtreg/serviceability/attach/AttachNegativePidTest.java

Changeset: db6829c1cc3a
Author:    lmesnik
Date:      2019-08-22 10:41 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/db6829c1cc3a

Merge


Changeset: 01d9a1cff83a
Author:    aefimov
Date:      2019-08-22 18:54 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/01d9a1cff83a

8078219: Verify lack of @test tag in files in java/net test directory
Reviewed-by: alanb
Contributed-by: Patrick Concannon <patrick.concannon at oracle.com>

! test/jdk/java/net/MulticastSocket/MulticastAddresses.java
! test/jdk/java/net/MulticastSocket/Reuse.java
! test/jdk/java/net/URLClassLoader/GetURLsTest.java

Changeset: bc14eec6f4bc
Author:    shade
Date:      2019-08-22 20:22 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/bc14eec6f4bc

8230046: Build failure after JDK-8230003
Reviewed-by: zgu, coleenp

! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp

Changeset: e1269de19aa5
Author:    jnimeh
Date:      2019-08-22 14:09 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/e1269de19aa5

8225436: Stapled OCSPResponses should be added to PKIXRevocationChecker irrespective of revocationEnabled flag
Reviewed-by: mullan

! src/java.base/share/classes/sun/security/validator/PKIXValidator.java
+ test/jdk/sun/security/validator/PKIXValAndRevCheckTests.java

Changeset: b2b77f6922dc
Author:    pliden
Date:      2019-08-23 08:48 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/b2b77f6922dc

8227226: ZGC: Segmented array clearing
Reviewed-by: eosterlund
Contributed-by: stefan.karlsson at oracle.com, erik.osterlund at oracle.com, per.liden at oracle.com, sci at amazon.com

! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/memAllocator.hpp
! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zCollectedHeap.hpp
+ src/hotspot/share/gc/z/zObjArrayAllocator.cpp
+ src/hotspot/share/gc/z/zObjArrayAllocator.hpp

Changeset: 6728c41f2a08
Author:    pliden
Date:      2019-08-23 08:48 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/6728c41f2a08

8229451: ZGC: Make some roots invisible to the heap iterator
Reviewed-by: eosterlund

! src/hotspot/share/gc/shared/gcThreadLocalData.hpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/gc/z/zObjArrayAllocator.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRootsIterator.cpp
! src/hotspot/share/gc/z/zRootsIterator.hpp
! src/hotspot/share/gc/z/zThreadLocalData.hpp

Changeset: 92f994585e25
Author:    pliden
Date:      2019-08-23 08:48 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/92f994585e25

8229127: Make some methods in the allocation path non-virtual
Reviewed-by: eosterlund

! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shared/memAllocator.hpp

Changeset: 3029be26f9ea
Author:    neliasso
Date:      2019-08-23 10:11 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/3029be26f9ea

8228839: Non-CFG nodes have control edges to calls, instead of the call's control projection
Reviewed-by: kvn, thartmann

! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp

Changeset: 8b8d8a1621f2
Author:    neliasso
Date:      2019-08-23 10:11 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8b8d8a1621f2

8229970: ZGC: C2: fixup_uses_in_catch may fail when expanding many uses
Reviewed-by: kvn, thartmann

! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp

Changeset: 00bf1e66de11
Author:    afarley
Date:      2019-08-23 03:06 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/00bf1e66de11

8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN
Summary: The size of each path in sun.boot.library.path property should not exceed JVM_MAXPATHLEN
Reviewed-by: dholmes, coleenp, sspitsyn

! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
+ test/hotspot/jtreg/runtime/LoadLibrary/TestSunBootLibraryPath.java

Changeset: cf45b7945e4b
Author:    dfuchs
Date:      2019-08-23 18:40 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/cf45b7945e4b

8229337: java.lang.Math class doc should be adjusted regarding -Exact methods
Reviewed-by: rriggs, bpb
Contributed-by: Julia Boes <julia.boes at oracle.com>

! src/java.base/share/classes/java/lang/Math.java

Changeset: c370cc1b2a86
Author:    joehw
Date:      2019-08-23 17:57 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/c370cc1b2a86

8229388: ErrorHandler and ContentHandler contain ambiguous/unfinished specification
Reviewed-by: lancea

! src/java.xml/share/classes/org/xml/sax/ContentHandler.java
! src/java.xml/share/classes/org/xml/sax/ErrorHandler.java

Changeset: 489b8e142559
Author:    iklam
Date:      2019-08-23 10:39 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/489b8e142559

8230011: Consolidate duplicated classpath parsing code in classLoader.cpp
Reviewed-by: ccheung, fparain

! src/hotspot/share/classfile/classLoader.cpp

Changeset: 1e85670cb9ee
Author:    rriggs
Date:      2019-08-23 14:04 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/1e85670cb9ee

8230058: Replace exception from sun.rmi.runtime.Log#getSource() with StackWalker
Reviewed-by: mchung, rriggs
Contributed-by: kustos at gmx.net

! src/java.rmi/share/classes/sun/rmi/runtime/Log.java

Changeset: 36f5e20be69a
Author:    dfuchs
Date:      2019-08-23 19:55 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/36f5e20be69a

8229485: Add decrementExact(), incrementExact(), and negateExact() to java.lang.StrictMath
Summary: three methods are added to StrictMath for consistency with Math. Tests are updated accordingly.
Reviewed-by: bpb, lancea, igerasim, dfuchs, joehw, rriggs
Contributed-by: Julia Boes <julia.boes at oracle.com>

! src/java.base/share/classes/java/lang/StrictMath.java
! test/jdk/java/lang/Math/ExactArithTests.java
! test/jdk/java/lang/StrictMath/ExactArithTests.java

Changeset: 7ae075afc72f
Author:    rriggs
Date:      2019-08-23 15:24 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/7ae075afc72f

8230104: JNU_IsInstanceOfByName needs const parameter
Reviewed-by: alanb, rriggs
Contributed-by: andrewluotechnologies at outlook.com

! src/java.base/share/native/libjava/jni_util.c
! src/java.base/share/native/libjava/jni_util.h

Changeset: 2d2c2428bf52
Author:    coleenp
Date:      2019-08-23 23:27 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/2d2c2428bf52

8230116: Test workaround to Klass::_class_loader_data sometimes NULL problem
Summary: This is a low frequency problem that we are seeing internally, this patch is mostly to rule out one theory.
Reviewed-by: dcubed

! src/hotspot/share/oops/klass.cpp

Changeset: 427b38332f20
Author:    stefank
Date:      2019-08-26 09:13 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/427b38332f20

8229836: Remove include of globals.hpp from allocation.hpp
Reviewed-by: coleenp, kbarrett

! src/hotspot/os/linux/gc/z/zNUMA_linux.cpp
! src/hotspot/os/linux/osContainer_linux.cpp
! src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
! src/hotspot/share/code/vmreg.hpp
! src/hotspot/share/gc/cms/allocationStats.hpp
! src/hotspot/share/gc/g1/g1Analytics.cpp
! src/hotspot/share/gc/shared/gcOverheadChecker.hpp
! src/hotspot/share/gc/z/zValue.hpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/allocation.inline.hpp
! src/hotspot/share/memory/metaspace.hpp
! src/hotspot/share/oops/accessBackend.hpp
! src/hotspot/share/oops/markWord.hpp
! src/hotspot/share/oops/oopsHierarchy.hpp
! src/hotspot/share/runtime/perfMemory.hpp
! src/hotspot/share/utilities/globalDefinitions.cpp
! src/hotspot/share/utilities/virtualizationSupport.cpp
! test/hotspot/gtest/runtime/test_os_linux.cpp
! test/hotspot/gtest/utilities/test_globalDefinitions.cpp

Changeset: 30db6422848b
Author:    stefank
Date:      2019-08-26 09:15 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/30db6422848b

8224878: Use JVMFlag parameters instead of name strings
Reviewed-by: gziemski, dholmes, jrose

! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/flags/jvmFlag.cpp
! src/hotspot/share/runtime/flags/jvmFlag.hpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintList.cpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintList.hpp
! src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp
! src/hotspot/share/runtime/flags/jvmFlagRangeList.hpp
! src/hotspot/share/runtime/globals_extension.hpp
! src/hotspot/share/services/attachListener.cpp
! src/hotspot/share/services/dtraceAttacher.cpp
! src/hotspot/share/services/management.cpp
! src/hotspot/share/services/writeableFlags.cpp

Changeset: eebdf6aa4907
Author:    michaelm
Date:      2019-08-26 11:46 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/eebdf6aa4907

8222363: Update ServerSocket.isBound spec to reflect implementation after close
Reviewed-by: dfuchs

! src/java.base/share/classes/java/net/ServerSocket.java

Changeset: 095c2f21dd10
Author:    michaelm
Date:      2019-08-26 12:25 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/095c2f21dd10

8177648: getResponseCode() throws IllegalArgumentException caused by protocol error while following redirect
Reviewed-by: michaelm, chegar, dfuchs
Contributed-by: jai.forums2013 at gmail.com

! src/java.base/share/classes/java/net/ProxySelector.java
! src/java.base/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java
! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/jdk/java/net/HttpURLConnection/HttpURLProxySelectionTest.java
+ test/jdk/sun/net/spi/DefaultProxySelectorTest.java

Changeset: ff08db52ad92
Author:    dfuchs
Date:      2019-08-26 14:48 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/ff08db52ad92

8230000: some httpclients testng tests run zero test
Summary: two tests needed to declared their test methods public, the last one was a simple abstract framework for subclasses and needed its @test keyword removed.
Reviewed-by: chegar, aefimov, dfuchs
Contributed-by: Julia Boes <julia.boes at oracle.com>

! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java
! test/jdk/java/net/httpclient/LineStreamsAndSurrogatesTest.java
! test/jdk/java/net/httpclient/LineSubscribersAndSurrogatesTest.java

Changeset: c414c554b38b
Author:    erikj
Date:      2019-08-26 07:14 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/c414c554b38b

8230079: Update test document by changing "TIMEOUT" to "TIMEOUT_FACTOR"
Reviewed-by: erikj
Contributed-by: Wang Xue <wangxue at loongson.cn>

! doc/building.html
! doc/testing.html
! doc/testing.md

Changeset: 85fbdb87baad
Author:    mbaesken
Date:      2019-08-14 15:07 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/85fbdb87baad

8229706: java/net/MulticastSocket/NoLoopbackPackets.java fails on some AIX machines
Reviewed-by: chegar, clanger

! test/jdk/java/net/MulticastSocket/NoLoopbackPackets.java

Changeset: cb836bd08d58
Author:    shade
Date:      2019-08-27 11:15 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/cb836bd08d58

8230214: AArch64 build failures after JDK-8229836 (Remove include of globals.hpp from allocation.hpp)
Reviewed-by: dholmes

! src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp

Changeset: 41b68dc5e0b9
Author:    jpai
Date:      2019-08-27 16:17 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/41b68dc5e0b9

8230220: java/net/HttpURLConnection/HttpURLProxySelectionTest.java fails intermittently
Summary: Fix the test to use volatile on members which are accessed across threads
Reviewed-by: dfuchs

! test/jdk/java/net/HttpURLConnection/HttpURLProxySelectionTest.java

Changeset: e6d7c5fbf09d
Author:    shade
Date:      2019-08-27 17:02 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/e6d7c5fbf09d

8230215: MacOS debug build is broken after JDK-8230003
Reviewed-by: zgu, mdoerr

! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp

Changeset: 6bb824c45df1
Author:    kbarrett
Date:      2019-08-27 11:05 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/6bb824c45df1

8230192: Rename G1RedirtyCardsBufferList to G1BufferNodeList
Summary: Rename class and move to new files.
Reviewed-by: sjohanss, lkorinth

+ src/hotspot/share/gc/g1/g1BufferNodeList.cpp
+ src/hotspot/share/gc/g1/g1BufferNodeList.hpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.cpp
! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.hpp

Changeset: 460f412c1358
Author:    eosterlund
Date:      2019-08-27 16:35 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/460f412c1358

8219708: Stop flushing OSR nmethods earlier in the sweeper
Reviewed-by: neliasso, thartmann

! src/hotspot/share/runtime/sweeper.cpp

Changeset: fb6cd98e4dec
Author:    shade
Date:      2019-08-27 19:22 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/fb6cd98e4dec

8230118: 32-bit build failures after JDK-8227054
Reviewed-by: zgu, kbarrett

! src/hotspot/share/gc/shared/weakProcessor.cpp

Changeset: 49fea19f0726
Author:    pchilanomate
Date:      2019-08-27 20:10 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/49fea19f0726

8229844: Remove attempt_rebias parameter from revoke_and_rebias()
Summary: Removed attempt_rebias parameter and merged fast_enter() and slow_enter() into enter()
Reviewed-by: dholmes, rehn, coleenp, dcubed

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/biasedLocking.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp
! test/hotspot/gtest/oops/test_markOop.cpp

Changeset: 01b9c26e2651
Author:    redestad
Date:      2019-08-27 22:26 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/01b9c26e2651

8228507: Archive FDBigInteger
Reviewed-by: jiangli, bpb

! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java
! src/hotspot/share/memory/heapShared.cpp
! src/java.base/share/classes/jdk/internal/math/FDBigInteger.java
! src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java

Changeset: 82a71d82e326
Author:    igerasim
Date:      2019-08-27 14:44 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/82a71d82e326

8226831: Use Objects.equals() when appropriate
Reviewed-by: rriggs, bpb

! src/java.base/share/classes/java/net/InterfaceAddress.java
! src/java.base/share/classes/java/net/URLStreamHandler.java
! src/java.base/share/classes/java/text/AttributedString.java
! src/java.base/share/classes/java/util/TreeMap.java
! src/java.base/share/classes/java/util/TreeSet.java
! src/java.base/share/classes/sun/net/www/protocol/ftp/Handler.java
! src/java.base/share/classes/sun/security/x509/AlgorithmId.java

Changeset: 48f52ad5a2c3
Author:    fyuan
Date:      2019-08-28 11:00 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/48f52ad5a2c3

8230010: Remove jdk8037819/BasicTest1.java
8230002: javax/xml/jaxp/unittest/transform/SecureProcessingTest.java runs zero test
Reviewed-by: joehw, vtewari

! test/jaxp/javax/xml/jaxp/unittest/transform/SecureProcessingTest.java
- test/jdk/javax/xml/jaxp/testng/validation/jdk8037819/BasicTest1.java

Changeset: e2e315f1aa63
Author:    iklam
Date:      2019-08-27 22:14 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/e2e315f1aa63

8230168: Use ClasspathStream for FileMapInfo::create_path_array
Reviewed-by: lfoltan, fparain

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/filemap.hpp
+ src/hotspot/share/utilities/classpathStream.cpp
+ src/hotspot/share/utilities/classpathStream.hpp

Changeset: 5ddb746d45e0
Author:    iklam
Date:      2019-08-27 22:14 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/5ddb746d45e0

8227370: Remove SharedPathsMiscInfo
Reviewed-by: ccheung, jiangli

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp
! src/hotspot/share/classfile/classLoaderExt.cpp
! src/hotspot/share/classfile/classLoaderExt.hpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.hpp
! src/hotspot/share/include/cds.h
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/filemap.hpp
! src/hotspot/share/prims/cdsoffsets.cpp
! test/hotspot/jtreg/runtime/cds/appcds/AppendClasspath.java
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java
+ test/hotspot/jtreg/runtime/cds/appcds/NonExistClasspath.java
! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java
! test/hotspot/jtreg/runtime/cds/appcds/TraceLongClasspath.java
+ test/hotspot/jtreg/runtime/cds/appcds/test-classes/CpAttr6.java

Changeset: 54845835747f
Author:    pliden
Date:      2019-08-28 09:50 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/54845835747f

8230090: ZGC: Introduce ZSyscall
Reviewed-by: stefank

+ src/hotspot/os/linux/gc/z/zSyscall_linux.cpp
+ src/hotspot/os/linux/gc/z/zSyscall_linux.hpp
! src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
+ src/hotspot/os_cpu/linux_aarch64/gc/z/zSyscall_linux_aarch64.hpp
! src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
+ src/hotspot/os_cpu/linux_x86/gc/z/zSyscall_linux_x86.hpp

Changeset: 0cd210d5cb9c
Author:    pliden
Date:      2019-08-28 09:50 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/0cd210d5cb9c

8230092: ZGC: Consolidate ZBackingFile, ZBackingPath and ZPhysicalMemoryBacking on Linux
Reviewed-by: stefank

! src/hotspot/os/linux/gc/z/zBackingFile_linux.cpp < src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
+ src/hotspot/os/linux/gc/z/zBackingFile_linux.hpp
+ src/hotspot/os/linux/gc/z/zBackingPath_linux.cpp
+ src/hotspot/os/linux/gc/z/zBackingPath_linux.hpp
+ src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp
+ src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp
! src/hotspot/share/gc/z/zPhysicalMemory.hpp

Changeset: 53ed0cf870b0
Author:    pliden
Date:      2019-08-28 09:50 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/53ed0cf870b0

8230096: ZGC: Remove unused ZObjectAllocator::_nworkers
Reviewed-by: stefank

! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zObjectAllocator.cpp
! src/hotspot/share/gc/z/zObjectAllocator.hpp

Changeset: 5e2576c303a2
Author:    eosterlund
Date:      2019-08-28 11:19 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/5e2576c303a2

8229278: Improve hs_err location printing to assume less about GC internals
Reviewed-by: stefank, kbarrett

! src/hotspot/share/gc/epsilon/epsilonHeap.cpp
! src/hotspot/share/gc/epsilon/epsilonHeap.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.hpp
+ src/hotspot/share/gc/shared/locationPrinter.cpp
+ src/hotspot/share/gc/shared/locationPrinter.hpp
+ src/hotspot/share/gc/shared/locationPrinter.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zCollectedHeap.hpp
! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zHeap.hpp
! src/hotspot/share/gc/z/zPage.hpp
! src/hotspot/share/gc/z/zPage.inline.hpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/runtime/os.cpp

Changeset: 4f38fcd65577
Author:    neliasso
Date:      2019-08-26 11:36 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/4f38fcd65577

8230091: Add verification of clean_catch_blocks
Reviewed-by: rbackman, kvn

! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp

Changeset: 55723932d06e
Author:    iklam
Date:      2019-08-28 07:41 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/55723932d06e

8230294: runtime/cds/appcds/ClassPathAttr.java failed with jar operation failed
Reviewed-by: lfoltan

+ test/hotspot/jtreg/runtime/cds/appcds/test-classes/cpattr6.mf

Changeset: e17f768b3b71
Author:    dcubed
Date:      2019-08-28 10:56 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/e17f768b3b71

8230184: rename, whitespace, indent and comments changes in preparation for lock free Monitor lists
Reviewed-by: kbarrett, dholmes

! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/serviceThread.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/runtime/vmStructs.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectSynchronizer.java
! test/hotspot/gtest/runtime/test_synchronizer.cpp

Changeset: f080150a6a7e
Author:    dcubed
Date:      2019-08-28 12:53 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/f080150a6a7e

8230317: serviceability/sa/ClhsdbPrintStatics.java fails after 8230184
Reviewed-by: eosterlund

! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintStatics.java

Changeset: d1a6f72e4aec
Author:    kbarrett
Date:      2019-08-28 14:06 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/d1a6f72e4aec

8230126: delay_to_keep_mmu can delay shutdown
Summary: Wait on CGC_lock instead of sleeping to provide the delay.
Reviewed-by: sangheki, sjohanss

! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp

Changeset: 9c98f8788762
Author:    godin
Date:      2019-08-28 14:37 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/9c98f8788762

8215166: Remove unused G1PretouchAuxiliaryMemory option
Summary: Removed experimental option.
Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1_globals.hpp

Changeset: 8570f22b9b6a
Author:    joehw
Date:      2019-08-28 19:02 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/8570f22b9b6a

8230094: CCE in createXMLEventWriter(Result) over an arbitrary XMLStreamWriter
Reviewed-by: lancea

! src/java.xml/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java
! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java
+ test/jaxp/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/CustomImplTest.java

Changeset: 97257da4ac8d
Author:    amenkov
Date:      2019-08-28 13:34 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/97257da4ac8d

8228554: Accessibility errors in jdwp-protocol.html
Reviewed-by: dholmes, sspitsyn

! make/jdk/src/classes/build/tools/jdwpgen/AbstractTypeListNode.java
! make/jdk/src/classes/build/tools/jdwpgen/AbstractTypeNode.java
! make/jdk/src/classes/build/tools/jdwpgen/AltNode.java
! make/jdk/src/classes/build/tools/jdwpgen/ConstantNode.java
! make/jdk/src/classes/build/tools/jdwpgen/ConstantSetNode.java
! make/jdk/src/classes/build/tools/jdwpgen/ErrorNode.java
! make/jdk/src/classes/build/tools/jdwpgen/ErrorSetNode.java
! make/jdk/src/classes/build/tools/jdwpgen/Node.java
! make/jdk/src/classes/build/tools/jdwpgen/RepeatNode.java
! make/jdk/src/classes/build/tools/jdwpgen/RootNode.java

Changeset: da87424384eb
Author:    mseledtsov
Date:      2019-08-28 15:15 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/da87424384eb

8230115: Problemlist JFR TestNetworkUtilization test
Summary: Added test to the problem list
Reviewed-by: dcubed

! test/jdk/ProblemList.txt

Changeset: edc00278955d
Author:    jiefu
Date:      2019-08-28 08:47 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/edc00278955d

8230228: [TESTBUG] Several runtime/ErrorHandling tests may fail on some platforms
Reviewed-by: coleenp, stuefe, mseledtsov

! test/hotspot/jtreg/runtime/ErrorHandling/BadNativeStackInErrorHandlingTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileRedirectTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/TimeoutInErrorHandlingTest.java

Changeset: 339af8e17cb3
Author:    jwilhelm
Date:      2019-08-29 02:54 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/339af8e17cb3

Added tag jdk-14+12 for changeset 8570f22b9b6a

! .hgtags

Changeset: 3da1848cc39b
Author:    darcy
Date:      2019-08-28 22:30 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/3da1848cc39b

8230074: Improve specification for {Math, StrictMath}.negateExact
Reviewed-by: bpb

! src/java.base/share/classes/java/lang/Math.java
! src/java.base/share/classes/java/lang/StrictMath.java

Changeset: ce786c3f1f1c
Author:    psadhukhan
Date:      2019-07-22 11:08 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/ce786c3f1f1c

Merge

- src/hotspot/share/gc/z/zOopClosures.cpp
- src/hotspot/share/jfr/leakprofiler/emitEventOperation.cpp
- src/hotspot/share/jfr/leakprofiler/emitEventOperation.hpp
- src/java.base/share/classes/jdk/internal/access/JavaNetSocketAccess.java
- src/java.base/share/classes/jdk/internal/access/JavaNetURLClassLoaderAccess.java
! test/jdk/ProblemList.txt
- test/jdk/sun/misc/ClassLoaderUtil/test.jar
- test/jdk/sun/security/tools/keytool/DefaultSignatureAlgorithm.java
- test/jdk/sun/security/tools/keytool/pss/PSS.java
- test/jdk/sun/security/tools/keytool/pss/java.base/sun/security/rsa/RSAKeyPairGenerator.java

Changeset: e28ccaff2f84
Author:    psadhukhan
Date:      2019-07-24 12:21 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/e28ccaff2f84

Merge

- src/java.base/share/classes/jdk/internal/reflect/LangReflectAccess.java
- src/jdk.javadoc/share/legal/pako.md
! test/jdk/ProblemList.txt

Changeset: 70865ef2afc7
Author:    psadhukhan
Date:      2019-07-24 12:49 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/70865ef2afc7

Merge


Changeset: b0aaa82a1b03
Author:    psadhukhan
Date:      2019-07-25 12:23 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/b0aaa82a1b03

Merge

! test/jdk/ProblemList.txt

Changeset: f95327be136a
Author:    akolarkunnu
Date:      2019-08-06 00:16 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/f95327be136a

8221312: test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java failed
Reviewed-by: serb, psadhukhan

! src/demo/share/jfc/SwingSet2/BezierAnimationPanel.java
! test/jdk/ProblemList.txt
! test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/colorchooser/BezierAnimationPanel.java

Changeset: 13178f7e75d5
Author:    lbourges
Date:      2019-08-07 10:25 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/13178f7e75d5

8228711: Path rendered incorrectly when it goes outside the clipping region
Summary: fixed closePath() to preserve last position and its outcode in Stroker and TransformingPathConsumer2D.PathClipFilter
Reviewed-by: prr, kcr

! src/java.desktop/share/classes/sun/java2d/marlin/DDasher.java
! src/java.desktop/share/classes/sun/java2d/marlin/DHelpers.java
! src/java.desktop/share/classes/sun/java2d/marlin/DStroker.java
! src/java.desktop/share/classes/sun/java2d/marlin/DTransformingPathConsumer2D.java
! src/java.desktop/share/classes/sun/java2d/marlin/Dasher.java
! src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java
! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java
! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java
! src/java.desktop/share/classes/sun/java2d/marlin/Version.java
! test/jdk/sun/java2d/marlin/ClipShapeTest.java

Changeset: 020f8fab32e2
Author:    aivanov
Date:      2019-08-18 21:36 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/020f8fab32e2

8222108: Reduce minRefreshTime for updating remote printer list on Windows
Reviewed-by: prr, serb

! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java
! test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java

Changeset: 39f133168348
Author:    psadhukhan
Date:      2019-08-19 12:13 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/39f133168348

8226513: JEditorPane is shown with incorrect size
Reviewed-by: prr, psadhukhan
Contributed-by: semyon.sadetsky at oracle.com

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java
+ test/jdk/javax/swing/JEditorPane/8226513/JEditorPaneLayoutTest.java

Changeset: e00a2d8a1016
Author:    dmarkov
Date:      2019-08-23 14:25 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/e00a2d8a1016

8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems)
Reviewed-by: psadhukhan, serb

! src/java.desktop/share/classes/javax/swing/ToolTipManager.java
+ test/jdk/javax/swing/ToolTipManager/JMenuItemToolTipKeyBindingsTest/JMenuItemToolTipKeyBindingsTest.java

Changeset: c16208de74da
Author:    psadhukhan
Date:      2019-08-29 15:09 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/c16208de74da

Merge

- make/jdk/src/classes/build/tools/tzdb/ZoneRules.java
- src/hotspot/cpu/aarch64/aarch64_call.cpp
- src/hotspot/cpu/aarch64/aarch64_linkage.S
- src/hotspot/cpu/aarch64/cpustate_aarch64.hpp
- src/hotspot/cpu/aarch64/decode_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/linux_aarch64.S
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.hpp
- src/hotspot/share/gc/parallel/gcTaskManager.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.hpp
- src/hotspot/share/gc/parallel/gcTaskThread.cpp
- src/hotspot/share/gc/parallel/gcTaskThread.hpp
- src/hotspot/share/gc/parallel/pcTasks.cpp
- src/hotspot/share/gc/parallel/pcTasks.hpp
- src/hotspot/share/gc/parallel/psTasks.cpp
- src/hotspot/share/gc/parallel/psTasks.hpp
- src/hotspot/share/oops/markOop.cpp
- src/hotspot/share/oops/markOop.hpp
- src/hotspot/share/oops/markOop.inline.hpp
- src/java.base/share/classes/java/security/acl/Acl.java
- src/java.base/share/classes/java/security/acl/AclEntry.java
- src/java.base/share/classes/java/security/acl/AclNotFoundException.java
- src/java.base/share/classes/java/security/acl/Group.java
- src/java.base/share/classes/java/security/acl/LastOwnerException.java
- src/java.base/share/classes/java/security/acl/NotOwnerException.java
- src/java.base/share/classes/java/security/acl/Owner.java
- src/java.base/share/classes/java/security/acl/Permission.java
- src/java.base/share/classes/java/security/acl/package-info.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/ArchiveDoesNotExist.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/BootAppendTests.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentCompactStrings.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsSameObjectAlignment.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CheckDefaultArchiveFile.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CheckSharingWithDefaultArchive.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSharedDictionary.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSymbolAndStringTable.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/LoadClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/MaxMetaspaceSize.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/NonBootLoaderClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedBaseAddress.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStrings.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsDedup.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsRunAuto.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsWb.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedSymbolTableBucketSize.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SpaceUtilizationCheck.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/TestInterpreterMethodEntries.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/javax/annotation/processing/FilerException.jasm
- test/hotspot/jtreg/runtime/SharedArchiveFile/javax/sound/sampled/MyClass.jasm
- test/hotspot/jtreg/runtime/SharedArchiveFile/nonjdk/myPackage/MyClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClassesForSubgraphs.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/Implementor.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/Interface.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/SubClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/SuperClazz.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TestEntry.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformInterfaceAndImplementor.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformRelatedClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformSuperAndSubClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformSuperSubTwoPckgs.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformTestCommon.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/myPkg1/SuperClazz.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/myPkg2/SubClass.java
- test/hotspot/jtreg/runtime/appcds/AppCDSOptions.java
- test/hotspot/jtreg/runtime/appcds/AppendClasspath.java
- test/hotspot/jtreg/runtime/appcds/BootClassPathMismatch.java
- test/hotspot/jtreg/runtime/appcds/CDSandJFR.java
- test/hotspot/jtreg/runtime/appcds/CaseSensitiveClassPath.java
- test/hotspot/jtreg/runtime/appcds/ClassLoaderTest.java
- test/hotspot/jtreg/runtime/appcds/ClassPathAttr.java
- test/hotspot/jtreg/runtime/appcds/CommandLineFlagCombo.java
- test/hotspot/jtreg/runtime/appcds/CommandLineFlagComboNegative.java
- test/hotspot/jtreg/runtime/appcds/CompilerUtils.java
- test/hotspot/jtreg/runtime/appcds/DirClasspathTest.java
- test/hotspot/jtreg/runtime/appcds/DumpClassList.java
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_1.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_2.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_3.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.java
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.symbols.txt
- test/hotspot/jtreg/runtime/appcds/FieldAnnotationsTest.java
- test/hotspot/jtreg/runtime/appcds/FreeUnusedMetadata.java
- test/hotspot/jtreg/runtime/appcds/GraalWithLimitedMetaspace.java
- test/hotspot/jtreg/runtime/appcds/HelloExtTest.java
- test/hotspot/jtreg/runtime/appcds/HelloTest.java
- test/hotspot/jtreg/runtime/appcds/IgnoreEmptyClassPaths.java
- test/hotspot/jtreg/runtime/appcds/JarBuilder.java
- test/hotspot/jtreg/runtime/appcds/JvmtiAddPath.java
- test/hotspot/jtreg/runtime/appcds/LongClassListPath.java
- test/hotspot/jtreg/runtime/appcds/LotsOfClasses.java
- test/hotspot/jtreg/runtime/appcds/MissingSuperTest.java
- test/hotspot/jtreg/runtime/appcds/MoveJDKTest.java
- test/hotspot/jtreg/runtime/appcds/MultiProcessSharing.java
- test/hotspot/jtreg/runtime/appcds/MultiReleaseJars.java
- test/hotspot/jtreg/runtime/appcds/OldClassTest.java
- test/hotspot/jtreg/runtime/appcds/PackageSealing.java
- test/hotspot/jtreg/runtime/appcds/ParallelLoad2.java
- test/hotspot/jtreg/runtime/appcds/ParallelLoadTest.java
- test/hotspot/jtreg/runtime/appcds/PrintSharedArchiveAndExit.java
- test/hotspot/jtreg/runtime/appcds/ProhibitedPackage.java
- test/hotspot/jtreg/runtime/appcds/ProtectionDomain.java
- test/hotspot/jtreg/runtime/appcds/RelativePath.java
- test/hotspot/jtreg/runtime/appcds/RewriteBytecodesTest.java
- test/hotspot/jtreg/runtime/appcds/SharedArchiveConsistency.java
- test/hotspot/jtreg/runtime/appcds/SharedBaseAddress.java
- test/hotspot/jtreg/runtime/appcds/SharedPackages.java
- test/hotspot/jtreg/runtime/appcds/SignedJar.java
- test/hotspot/jtreg/runtime/appcds/SpecifySysLoaderProp.java
- test/hotspot/jtreg/runtime/appcds/TestCommon.java
- test/hotspot/jtreg/runtime/appcds/TestWithProfiler.java
- test/hotspot/jtreg/runtime/appcds/TraceLongClasspath.java
- test/hotspot/jtreg/runtime/appcds/UnusedCPDuringDump.java
- test/hotspot/jtreg/runtime/appcds/UseAppCDS_Test.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_0.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_1A.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_1B.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_2.java
- test/hotspot/jtreg/runtime/appcds/WideIloadTest.java
- test/hotspot/jtreg/runtime/appcds/WrongClasspath.java
- test/hotspot/jtreg/runtime/appcds/XShareAutoWithChangedJar.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedIntegerCacheTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleComboTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleCompareTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckArchivedModuleApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedMirrorApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedMirrorTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferences.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferencesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckIntegerCacheApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.config.txt
- test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStress.config.txt
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/InstrumentationAgent.mf
- test/hotspot/jtreg/runtime/appcds/cacheObject/MirrorWithReferenceFieldsApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MirrorWithReferenceFieldsTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MyException.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MyOuter.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/OpenArchiveRegion.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrimitiveTypesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrimitiveTypesTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrintSystemModulesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/src/test/jdk/test/Test.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/src/test/module-info.java
- test/hotspot/jtreg/runtime/appcds/cdsutils/DynamicDumpHelper.java
- test/hotspot/jtreg/runtime/appcds/condy/CondyHello.jasm
- test/hotspot/jtreg/runtime/appcds/condy/CondyHelloApp.java
- test/hotspot/jtreg/runtime/appcds/condy/CondyHelloTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatA.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatB.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatBase.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatC.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatD.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatE.java
- test/hotspot/jtreg/runtime/appcds/customLoader/CustomLoaderApp.java
- test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom.java
- test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom_JFR.java
- test/hotspot/jtreg/runtime/appcds/customLoader/LoaderSegregationTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestBase.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestMultiFP.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestSingleFP.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ProhibitedPackageNamesTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ProtectionDomain.java
- test/hotspot/jtreg/runtime/appcds/customLoader/SameNameInTwoLoadersTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnintendedLoadersTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnloadUnregisteredLoaderTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnsupportedPlatforms.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomInterface2_ia.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomInterface2_ib.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee2.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee3.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee3Child.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/Hello.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/HelloUnload.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/InProhibitedPkg.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/LoaderAPI.mf
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/LoaderSegregation.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/OnlyBuiltin.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/OnlyUnregistered.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/ProtDomain.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/SameNameUnrelatedLoaders.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/SimpleHello.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/UnintendedLoaders.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/UnloadUnregisteredLoader.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/AppendClasspath.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/ArchiveConsistency.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/ArrayKlasses.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/ClassResolutionFailure.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/DynamicArchiveTestBase.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/DynamicFlag.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/DynamicLotsOfClasses.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/ExcludedClasses.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/HelloDynamic.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/HelloDynamicCustom.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/HelloDynamicCustomUnload.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/JITInteraction.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/MainModuleOnly.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/MethodSorting.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/MissingArchive.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/NoClassToArchive.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/RelativePath.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/SharedArchiveFileOption.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/UnsupportedBaseArchive.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/UnusedCPDuringDump.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/WrongTopClasspath.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/ArrayKlassesApp.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/ExcludedClassesApp.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/LoadClasses.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/MethodSortingApp.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/MissingDependent.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/StrConcatApp.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/TestJIT.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTest.java
- test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTestHelper.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/javaldr/GCSharedStringsDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCSharedStringsDuringDumpWb.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/jigsaw/CheckUnsupportedDumpingOptions.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/JigsawOptionsCombo.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/AppClassInCP.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/CustomPackage.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/MismatchedPatchModule.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchDir.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchJavaBase.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchMain.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/Simple.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/SubClassOfPatchedClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/TwoJars.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/BootAppendTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/com/sun/tools/javac/Main.jasm
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/com/sun/tools/javac/MyMain.jasm
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/jdk/test/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/sun/nio/cs/ext/MyClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/sun/nio/cs/ext1/MyClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddModules.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddOpens.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddReads.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ExportModule.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/JvmtiAddPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/MainModuleOnly.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.greetings/com/greetings/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.greetings/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.hello/com/hello/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.hello/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.nomodule/com/nomodule/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.norequires/com/norequires/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.norequires/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.simple/com/simple/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.simple/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/org.astro/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/org.astro/org/astro/World.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/OverrideTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/java.net.http/java/net/http/HttpTimeoutException.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/java.net.http/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/jdk.compiler/com/sun/tools/javac/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/jdk.compiler/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/test/jdk/test/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/test/module-info.java
- test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHook.java
- test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHookTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationAgent.mf
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationApp.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationClassFileTransformer.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationRegisterClassFileTransformer.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/DumpingWithJvmtiAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/SimpleAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/SimpleAgent.mf
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/libAddToSystemCLSearchOnLoad.c
- test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelClassesTransform.java
- test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelLoadAndTransformTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformInterfaceImplementorAppCDS.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformRelatedClassesAppCDS.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformSuperSubAppCDS.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasic.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_SharedHelper.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/ExerciseGC.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/ExtraSharedInput.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/FlagCombo.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloString.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloStringGC.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloStringPlus.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InternSharedString.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InternStringTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InvalidFileFormat.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LargePages.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockSharedStrings.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockStringTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockStringValueTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasicPlus.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsHumongous.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsStress.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsUtils.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWb.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWbTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/CorruptDataLine.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidDataType.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidHeader.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidString.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidStringFormat.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidSymbol.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidSymbolFormat.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidVersion.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/LengthOverflow.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/OverflowPrefix.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/TruncatedString.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/UnrecognizedPrefix.txt
- test/hotspot/jtreg/runtime/appcds/test-classes/ArrayListTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/BootClassPathAppendHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/C1.java
- test/hotspot/jtreg/runtime/appcds/test-classes/C2.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Child.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr1.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr2.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr3.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr4.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr5.java
- test/hotspot/jtreg/runtime/appcds/test-classes/DummyClassHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/EmptyClassHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/FieldAnnotationsApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ForNameTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/GenericTestApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/GetFlightRecorder.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Greet.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Hello.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExt.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExtApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExtExt.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloMore.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloWB.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Hi.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Iloadw.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/IloadwMain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JimageClassPackage.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JimageClassProtDomain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JvmtiApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MethodNoReturn.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/MissingSuper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MultiProcClass.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MyAnnotation.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MyThread.java
- test/hotspot/jtreg/runtime/appcds/test-classes/PackageSealingTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/PackageTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ParallelClasses.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ParallelLoad.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Prohibited.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/ProhibitedHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ProtDomain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ProtDomainB.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ReportMyLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/RewriteBytecodes.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Super.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TestClassLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TestWithProfilerHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TrySwitchMyLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Util.java
- test/hotspot/jtreg/runtime/appcds/test-classes/VerifierTest0.java
- test/hotspot/jtreg/runtime/appcds/test-classes/com/sun/tools/javac/Main.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr1.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr1_long.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr2.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr3.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr4.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr5_extra_long.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/java/net/HttpCookie.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/javax/transaction/InvalidTransactionException.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/package_seal.mf
- test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeArray.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeStringArray.java
- test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java
! test/jdk/ProblemList.txt
- test/jdk/java/net/Socket/reset/Test.java
- test/jdk/javax/xml/jaxp/testng/validation/jdk8037819/BasicTest1.java
- test/jdk/sun/util/calendar/zi/tzdata/VERSION
- test/jdk/sun/util/calendar/zi/tzdata/africa
- test/jdk/sun/util/calendar/zi/tzdata/antarctica
- test/jdk/sun/util/calendar/zi/tzdata/asia
- test/jdk/sun/util/calendar/zi/tzdata/australasia
- test/jdk/sun/util/calendar/zi/tzdata/backward
- test/jdk/sun/util/calendar/zi/tzdata/etcetera
- test/jdk/sun/util/calendar/zi/tzdata/europe
- test/jdk/sun/util/calendar/zi/tzdata/factory
- test/jdk/sun/util/calendar/zi/tzdata/gmt
- test/jdk/sun/util/calendar/zi/tzdata/iso3166.tab
- test/jdk/sun/util/calendar/zi/tzdata/jdk11_backward
- test/jdk/sun/util/calendar/zi/tzdata/leapseconds
- test/jdk/sun/util/calendar/zi/tzdata/northamerica
- test/jdk/sun/util/calendar/zi/tzdata/pacificnew
- test/jdk/sun/util/calendar/zi/tzdata/solar87
- test/jdk/sun/util/calendar/zi/tzdata/solar88
- test/jdk/sun/util/calendar/zi/tzdata/solar89
- test/jdk/sun/util/calendar/zi/tzdata/southamerica
- test/jdk/sun/util/calendar/zi/tzdata/systemv
- test/jdk/sun/util/calendar/zi/tzdata/zone.tab
- test/jdk/sun/util/calendar/zi/tzdata_jdk/gmt
- test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward

Changeset: 8ec5ad4f5cc3
Author:    coleenp
Date:      2019-08-29 08:52 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/8ec5ad4f5cc3

8216977: ShowHiddenFrames use in java_lang_StackTraceElement::fill_in appears broken
Summary: Return NULL source file and negative line number for hidden frames.
Reviewed-by: dholmes, hseigel

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.inline.hpp
+ test/hotspot/jtreg/runtime/StackTrace/HiddenFrameTest.java

Changeset: e8ba7e4f4190
Author:    redestad
Date:      2019-08-29 15:59 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/e8ba7e4f4190

8230302: GenerateJLIClassesPlugin can generate invalid DirectMethodHandle methods
Reviewed-by: mchung

! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java
! test/jdk/tools/jlink/plugins/GenerateJLIClassesPluginTest.java

Changeset: a1a8f8fae7d9
Author:    igerasim
Date:      2019-08-29 07:39 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/a1a8f8fae7d9

8230338: Accurate error message about bad Unicode block name
Reviewed-by: rriggs

! src/java.base/share/classes/java/util/regex/Pattern.java

Changeset: e29b6ddfd9f4
Author:    mseledtsov
Date:      2019-08-29 08:35 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/e29b6ddfd9f4

8229210: [TESTBUG] Move gc stress tests from JFR directory tree to gc/stress
Summary: moved the tests
Reviewed-by: egahlin

+ test/hotspot/jtreg/gc/stress/jfr/TestStressAllocationGCEventsWithCMS.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressAllocationGCEventsWithDefNew.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressAllocationGCEventsWithG1.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressAllocationGCEventsWithParNew.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressAllocationGCEventsWithParallel.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithCMS.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithDefNew.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithG1.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithParNew.java
+ test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithParallel.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java

Changeset: 72bc9a29fd7e
Author:    mbaesken
Date:      2019-08-28 14:22 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/72bc9a29fd7e

8229284: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage
Reviewed-by: mseledtsov, sgehwolf

! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java

Changeset: e09c993ac476
Author:    dtitov
Date:      2019-08-29 10:09 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/e09c993ac476

8182119: jdk.hotspot.agent's META-INF/services/com.sun.jdi.connect.Connector no longer needed
Reviewed-by: sspitsyn, amenkov, alanb

- src/jdk.hotspot.agent/share/classes/META-INF/services/com.sun.jdi.connect.Connector

Changeset: 4612a3cfb927
Author:    darcy
Date:      2019-08-29 10:52 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/4612a3cfb927

8229999: Apply java.io.Serial annotations to security types in java.base
Reviewed-by: rriggs, mullan

! src/java.base/share/classes/com/sun/crypto/provider/DESKey.java
! src/java.base/share/classes/com/sun/crypto/provider/DESedeKey.java
! src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java
! src/java.base/share/classes/com/sun/crypto/provider/DHPublicKey.java
! src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java
! src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
! src/java.base/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java
! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java
! src/java.base/share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
! src/java.base/share/classes/com/sun/security/cert/internal/x509/X509V1CertImpl.java
! src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java
! src/java.base/share/classes/java/security/AccessControlException.java
! src/java.base/share/classes/java/security/AllPermission.java
! src/java.base/share/classes/java/security/AuthProvider.java
! src/java.base/share/classes/java/security/BasicPermission.java
! src/java.base/share/classes/java/security/CodeSigner.java
! src/java.base/share/classes/java/security/CodeSource.java
! src/java.base/share/classes/java/security/DigestException.java
! src/java.base/share/classes/java/security/GeneralSecurityException.java
! src/java.base/share/classes/java/security/GuardedObject.java
! src/java.base/share/classes/java/security/Identity.java
! src/java.base/share/classes/java/security/IdentityScope.java
! src/java.base/share/classes/java/security/InvalidAlgorithmParameterException.java
! src/java.base/share/classes/java/security/InvalidKeyException.java
! src/java.base/share/classes/java/security/InvalidParameterException.java
! src/java.base/share/classes/java/security/Key.java
! src/java.base/share/classes/java/security/KeyException.java
! src/java.base/share/classes/java/security/KeyManagementException.java
! src/java.base/share/classes/java/security/KeyPair.java
! src/java.base/share/classes/java/security/KeyRep.java
! src/java.base/share/classes/java/security/KeyStoreException.java
! src/java.base/share/classes/java/security/NoSuchAlgorithmException.java
! src/java.base/share/classes/java/security/NoSuchProviderException.java
! src/java.base/share/classes/java/security/Permission.java
! src/java.base/share/classes/java/security/PermissionCollection.java
! src/java.base/share/classes/java/security/Permissions.java
! src/java.base/share/classes/java/security/Policy.java
! src/java.base/share/classes/java/security/PrivateKey.java
! src/java.base/share/classes/java/security/PrivilegedActionException.java
! src/java.base/share/classes/java/security/Provider.java
! src/java.base/share/classes/java/security/ProviderException.java
! src/java.base/share/classes/java/security/PublicKey.java
! src/java.base/share/classes/java/security/SecureRandom.java
! src/java.base/share/classes/java/security/SecureRandomSpi.java
! src/java.base/share/classes/java/security/SecurityPermission.java
! src/java.base/share/classes/java/security/SignatureException.java
! src/java.base/share/classes/java/security/SignedObject.java
! src/java.base/share/classes/java/security/Signer.java
! src/java.base/share/classes/java/security/Timestamp.java
! src/java.base/share/classes/java/security/UnrecoverableEntryException.java
! src/java.base/share/classes/java/security/UnrecoverableKeyException.java
! src/java.base/share/classes/java/security/UnresolvedPermission.java
! src/java.base/share/classes/java/security/UnresolvedPermissionCollection.java
! src/java.base/share/classes/java/security/cert/CRLException.java
! src/java.base/share/classes/java/security/cert/CertPath.java
! src/java.base/share/classes/java/security/cert/CertPathBuilderException.java
! src/java.base/share/classes/java/security/cert/CertPathValidatorException.java
! src/java.base/share/classes/java/security/cert/CertStoreException.java
! src/java.base/share/classes/java/security/cert/Certificate.java
! src/java.base/share/classes/java/security/cert/CertificateEncodingException.java
! src/java.base/share/classes/java/security/cert/CertificateException.java
! src/java.base/share/classes/java/security/cert/CertificateExpiredException.java
! src/java.base/share/classes/java/security/cert/CertificateNotYetValidException.java
! src/java.base/share/classes/java/security/cert/CertificateParsingException.java
! src/java.base/share/classes/java/security/cert/CertificateRevokedException.java
! src/java.base/share/classes/java/security/cert/X509Certificate.java
! src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java
! src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java
! src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java
! src/java.base/share/classes/java/security/interfaces/ECPublicKey.java
! src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java
! src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java
! src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java
! src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java
! src/java.base/share/classes/java/security/spec/InvalidKeySpecException.java
! src/java.base/share/classes/java/security/spec/InvalidParameterSpecException.java
! src/java.base/share/classes/javax/crypto/AEADBadTagException.java
! src/java.base/share/classes/javax/crypto/BadPaddingException.java
! src/java.base/share/classes/javax/crypto/CryptoAllPermission.java
! src/java.base/share/classes/javax/crypto/CryptoPermission.java
! src/java.base/share/classes/javax/crypto/CryptoPermissions.java
! src/java.base/share/classes/javax/crypto/CryptoPolicyParser.java
! src/java.base/share/classes/javax/crypto/ExemptionMechanismException.java
! src/java.base/share/classes/javax/crypto/IllegalBlockSizeException.java
! src/java.base/share/classes/javax/crypto/NoSuchPaddingException.java
! src/java.base/share/classes/javax/crypto/SealedObject.java
! src/java.base/share/classes/javax/crypto/ShortBufferException.java
! src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java
! src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java
! src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java
! src/java.base/share/classes/javax/crypto/spec/SecretKeySpec.java
! src/java.base/share/classes/javax/security/auth/AuthPermission.java
! src/java.base/share/classes/javax/security/auth/DestroyFailedException.java
! src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java
! src/java.base/share/classes/javax/security/auth/RefreshFailedException.java
! src/java.base/share/classes/javax/security/auth/Subject.java
! src/java.base/share/classes/javax/security/auth/callback/ChoiceCallback.java
! src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java
! src/java.base/share/classes/javax/security/auth/callback/LanguageCallback.java
! src/java.base/share/classes/javax/security/auth/callback/NameCallback.java
! src/java.base/share/classes/javax/security/auth/callback/PasswordCallback.java
! src/java.base/share/classes/javax/security/auth/callback/TextInputCallback.java
! src/java.base/share/classes/javax/security/auth/callback/TextOutputCallback.java
! src/java.base/share/classes/javax/security/auth/callback/UnsupportedCallbackException.java
! src/java.base/share/classes/javax/security/auth/login/AccountException.java
! src/java.base/share/classes/javax/security/auth/login/AccountExpiredException.java
! src/java.base/share/classes/javax/security/auth/login/AccountLockedException.java
! src/java.base/share/classes/javax/security/auth/login/AccountNotFoundException.java
! src/java.base/share/classes/javax/security/auth/login/CredentialException.java
! src/java.base/share/classes/javax/security/auth/login/CredentialExpiredException.java
! src/java.base/share/classes/javax/security/auth/login/CredentialNotFoundException.java
! src/java.base/share/classes/javax/security/auth/login/FailedLoginException.java
! src/java.base/share/classes/javax/security/auth/login/LoginException.java
! src/java.base/share/classes/javax/security/auth/x500/X500Principal.java
! src/java.base/share/classes/javax/security/cert/CertificateEncodingException.java
! src/java.base/share/classes/javax/security/cert/CertificateException.java
! src/java.base/share/classes/javax/security/cert/CertificateExpiredException.java
! src/java.base/share/classes/javax/security/cert/CertificateNotYetValidException.java
! src/java.base/share/classes/javax/security/cert/CertificateParsingException.java
! src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java
! src/java.base/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java
! src/java.base/share/classes/sun/security/jca/ProviderList.java
! src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java
! src/java.base/share/classes/sun/security/pkcs/ParsingException.java
! src/java.base/share/classes/sun/security/provider/DRBG.java
! src/java.base/share/classes/sun/security/provider/DSAPrivateKey.java
! src/java.base/share/classes/sun/security/provider/DSAPublicKey.java
! src/java.base/share/classes/sun/security/provider/DSAPublicKeyImpl.java
! src/java.base/share/classes/sun/security/provider/MD4.java
! src/java.base/share/classes/sun/security/provider/MoreDrbgParameters.java
! src/java.base/share/classes/sun/security/provider/PolicyFile.java
! src/java.base/share/classes/sun/security/provider/PolicyParser.java
! src/java.base/share/classes/sun/security/provider/SecureRandom.java
! src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
! src/java.base/share/classes/sun/security/provider/Sun.java
! src/java.base/share/classes/sun/security/provider/VerificationProvider.java
! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java
! src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilderException.java
! src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java
! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java
! src/java.base/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java
! src/java.base/share/classes/sun/security/rsa/RSAPublicKeyImpl.java
! src/java.base/share/classes/sun/security/rsa/SunRsaSign.java
! src/java.base/share/classes/sun/security/ssl/SunJSSE.java
! src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/java.base/share/classes/sun/security/timestamp/TSResponse.java
! src/java.base/share/classes/sun/security/util/LazyCodeSourcePermissionCollection.java
! src/java.base/share/classes/sun/security/util/ObjectIdentifier.java
! src/java.base/share/classes/sun/security/util/PendingException.java
! src/java.base/share/classes/sun/security/util/PropertyExpander.java
! src/java.base/share/classes/sun/security/validator/ValidatorException.java
! src/java.base/share/classes/sun/security/x509/AlgIdDSA.java
! src/java.base/share/classes/sun/security/x509/AlgorithmId.java
! src/java.base/share/classes/sun/security/x509/AttributeNameEnumeration.java
! src/java.base/share/classes/sun/security/x509/CertException.java
! src/java.base/share/classes/sun/security/x509/CertParseError.java
! src/java.base/share/classes/sun/security/x509/X509CertImpl.java
! src/java.base/share/classes/sun/security/x509/X509Key.java

Changeset: 5021d91ba9bd
Author:    jiefu
Date:      2019-08-30 00:03 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/5021d91ba9bd

8230037: Confused MetaData dumped by PrintOptoAssembly
Reviewed-by: kvn, bsrbnd

! src/hotspot/share/opto/output.cpp

Changeset: d78c910f9069
Author:    kbarrett
Date:      2019-08-29 18:35 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/d78c910f9069

8230109: G1DirtyCardQueueSet should use card counts rather than buffer counts
Summary: Consistently use card counts
Reviewed-by: sjohanss, sangheki

! src/hotspot/share/gc/g1/g1Analytics.cpp
! src/hotspot/share/gc/g1/g1Analytics.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1Policy.hpp

Changeset: fd09c637dedb
Author:    mseledtsov
Date:      2019-08-29 15:50 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/fd09c637dedb

8228960: [TESTBUG] containers/docker/TestJcmdWithSideCar.java: jcmd reports main class as Unknown
Summary: waiting for child output to start main() before running jcmd
Reviewed-by: dholmes, bobv

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/containers/docker/EventGeneratorLoop.java
! test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java

Changeset: 18863bf3501f
Author:    kbarrett
Date:      2019-08-29 18:52 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/18863bf3501f

8230332: G1DirtyCardQueueSet _notify_when_complete is always true
Summary: Removed _notify_when_complete, assume true value where formerly used.
Reviewed-by: sjohanss, tschatzl

! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp

Changeset: e0b8b019d2f5
Author:    darcy
Date:      2019-08-29 16:31 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/e0b8b019d2f5

8229997: Apply java.io.Serial annotations in java.base
Reviewed-by: alanb, rriggs

! src/java.base/share/classes/com/sun/java/util/jar/pack/Attribute.java
! src/java.base/share/classes/com/sun/java/util/jar/pack/ClassReader.java
! src/java.base/share/classes/com/sun/java/util/jar/pack/Instruction.java
! src/java.base/share/classes/java/io/CharConversionException.java
! src/java.base/share/classes/java/io/EOFException.java
! src/java.base/share/classes/java/io/File.java
! src/java.base/share/classes/java/io/FileNotFoundException.java
! src/java.base/share/classes/java/io/FilePermission.java
! src/java.base/share/classes/java/io/IOError.java
! src/java.base/share/classes/java/io/IOException.java
! src/java.base/share/classes/java/io/InterruptedIOException.java
! src/java.base/share/classes/java/io/InvalidClassException.java
! src/java.base/share/classes/java/io/InvalidObjectException.java
! src/java.base/share/classes/java/io/NotActiveException.java
! src/java.base/share/classes/java/io/NotSerializableException.java
! src/java.base/share/classes/java/io/ObjectStreamClass.java
! src/java.base/share/classes/java/io/ObjectStreamException.java
! src/java.base/share/classes/java/io/OptionalDataException.java
! src/java.base/share/classes/java/io/SerializablePermission.java
! src/java.base/share/classes/java/io/StreamCorruptedException.java
! src/java.base/share/classes/java/io/SyncFailedException.java
! src/java.base/share/classes/java/io/UTFDataFormatException.java
! src/java.base/share/classes/java/io/UncheckedIOException.java
! src/java.base/share/classes/java/io/UnsupportedEncodingException.java
! src/java.base/share/classes/java/io/WriteAbortedException.java
! src/java.base/share/classes/java/lang/AbstractMethodError.java
! src/java.base/share/classes/java/lang/ArithmeticException.java
! src/java.base/share/classes/java/lang/ArrayIndexOutOfBoundsException.java
! src/java.base/share/classes/java/lang/ArrayStoreException.java
! src/java.base/share/classes/java/lang/AssertionError.java
! src/java.base/share/classes/java/lang/Boolean.java
! src/java.base/share/classes/java/lang/BootstrapMethodError.java
! src/java.base/share/classes/java/lang/Byte.java
! src/java.base/share/classes/java/lang/Character.java
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassCastException.java
! src/java.base/share/classes/java/lang/ClassCircularityError.java
! src/java.base/share/classes/java/lang/ClassFormatError.java
! src/java.base/share/classes/java/lang/ClassNotFoundException.java
! src/java.base/share/classes/java/lang/CloneNotSupportedException.java
! src/java.base/share/classes/java/lang/Double.java
! src/java.base/share/classes/java/lang/Enum.java
! src/java.base/share/classes/java/lang/EnumConstantNotPresentException.java
! src/java.base/share/classes/java/lang/Error.java
! src/java.base/share/classes/java/lang/Exception.java
! src/java.base/share/classes/java/lang/ExceptionInInitializerError.java
! src/java.base/share/classes/java/lang/Float.java
! src/java.base/share/classes/java/lang/IllegalAccessError.java
! src/java.base/share/classes/java/lang/IllegalArgumentException.java
! src/java.base/share/classes/java/lang/IllegalCallerException.java
! src/java.base/share/classes/java/lang/IllegalMonitorStateException.java
! src/java.base/share/classes/java/lang/IllegalStateException.java
! src/java.base/share/classes/java/lang/IllegalThreadStateException.java
! src/java.base/share/classes/java/lang/IncompatibleClassChangeError.java
! src/java.base/share/classes/java/lang/IndexOutOfBoundsException.java
! src/java.base/share/classes/java/lang/InstantiationError.java
! src/java.base/share/classes/java/lang/InstantiationException.java
! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/InterruptedException.java
! src/java.base/share/classes/java/lang/LayerInstantiationException.java
! src/java.base/share/classes/java/lang/LinkageError.java
! src/java.base/share/classes/java/lang/Long.java
! src/java.base/share/classes/java/lang/NegativeArraySizeException.java
! src/java.base/share/classes/java/lang/NoClassDefFoundError.java
! src/java.base/share/classes/java/lang/NoSuchFieldError.java
! src/java.base/share/classes/java/lang/NoSuchFieldException.java
! src/java.base/share/classes/java/lang/NoSuchMethodError.java
! src/java.base/share/classes/java/lang/NoSuchMethodException.java
! src/java.base/share/classes/java/lang/NullPointerException.java
! src/java.base/share/classes/java/lang/Number.java
! src/java.base/share/classes/java/lang/NumberFormatException.java
! src/java.base/share/classes/java/lang/OutOfMemoryError.java
! src/java.base/share/classes/java/lang/ReflectiveOperationException.java
! src/java.base/share/classes/java/lang/RuntimeException.java
! src/java.base/share/classes/java/lang/RuntimePermission.java
! src/java.base/share/classes/java/lang/SecurityException.java
! src/java.base/share/classes/java/lang/Short.java
! src/java.base/share/classes/java/lang/StackOverflowError.java
! src/java.base/share/classes/java/lang/StackTraceElement.java
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/StringBuffer.java
! src/java.base/share/classes/java/lang/StringBuilder.java
! src/java.base/share/classes/java/lang/StringIndexOutOfBoundsException.java
! src/java.base/share/classes/java/lang/ThreadDeath.java
! src/java.base/share/classes/java/lang/Throwable.java
! src/java.base/share/classes/java/lang/TypeNotPresentException.java
! src/java.base/share/classes/java/lang/UnknownError.java
! src/java.base/share/classes/java/lang/UnsatisfiedLinkError.java
! src/java.base/share/classes/java/lang/UnsupportedClassVersionError.java
! src/java.base/share/classes/java/lang/UnsupportedOperationException.java
! src/java.base/share/classes/java/lang/VerifyError.java
! src/java.base/share/classes/java/lang/VirtualMachineError.java
! src/java.base/share/classes/java/lang/annotation/AnnotationFormatError.java
! src/java.base/share/classes/java/lang/annotation/AnnotationTypeMismatchException.java
! src/java.base/share/classes/java/lang/annotation/IncompleteAnnotationException.java
! src/java.base/share/classes/java/lang/invoke/LambdaConversionException.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/SerializedLambda.java
! src/java.base/share/classes/java/lang/invoke/StringConcatException.java
! src/java.base/share/classes/java/lang/invoke/WrongMethodTypeException.java
! src/java.base/share/classes/java/lang/module/FindException.java
! src/java.base/share/classes/java/lang/module/InvalidModuleDescriptorException.java
! src/java.base/share/classes/java/lang/module/ResolutionException.java
! src/java.base/share/classes/java/lang/reflect/GenericSignatureFormatError.java
! src/java.base/share/classes/java/lang/reflect/InaccessibleObjectException.java
! src/java.base/share/classes/java/lang/reflect/InvocationTargetException.java
! src/java.base/share/classes/java/lang/reflect/MalformedParameterizedTypeException.java
! src/java.base/share/classes/java/lang/reflect/MalformedParametersException.java
! src/java.base/share/classes/java/lang/reflect/Proxy.java
! src/java.base/share/classes/java/lang/reflect/ReflectPermission.java
! src/java.base/share/classes/java/lang/reflect/UndeclaredThrowableException.java
! src/java.base/share/classes/java/math/BigDecimal.java
! src/java.base/share/classes/java/math/BigInteger.java
! src/java.base/share/classes/java/math/MathContext.java
! src/java.base/share/classes/java/net/BindException.java
! src/java.base/share/classes/java/net/ConnectException.java
! src/java.base/share/classes/java/net/HttpRetryException.java
! src/java.base/share/classes/java/net/Inet4Address.java
! src/java.base/share/classes/java/net/Inet6Address.java
! src/java.base/share/classes/java/net/InetAddress.java
! src/java.base/share/classes/java/net/InetSocketAddress.java
! src/java.base/share/classes/java/net/MalformedURLException.java
! src/java.base/share/classes/java/net/NetPermission.java
! src/java.base/share/classes/java/net/NoRouteToHostException.java
! src/java.base/share/classes/java/net/PortUnreachableException.java
! src/java.base/share/classes/java/net/ProtocolException.java
! src/java.base/share/classes/java/net/SocketAddress.java
! src/java.base/share/classes/java/net/SocketException.java
! src/java.base/share/classes/java/net/SocketPermission.java
! src/java.base/share/classes/java/net/SocketTimeoutException.java
! src/java.base/share/classes/java/net/URI.java
! src/java.base/share/classes/java/net/URISyntaxException.java
! src/java.base/share/classes/java/net/URL.java
! src/java.base/share/classes/java/net/URLPermission.java
! src/java.base/share/classes/java/net/UnknownHostException.java
! src/java.base/share/classes/java/net/UnknownServiceException.java
! src/java.base/share/classes/java/nio/charset/CoderMalfunctionError.java
! src/java.base/share/classes/java/nio/charset/MalformedInputException.java
! src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java
! src/java.base/share/classes/java/nio/file/AccessDeniedException.java
! src/java.base/share/classes/java/nio/file/AtomicMoveNotSupportedException.java
! src/java.base/share/classes/java/nio/file/ClosedDirectoryStreamException.java
! src/java.base/share/classes/java/nio/file/ClosedFileSystemException.java
! src/java.base/share/classes/java/nio/file/ClosedWatchServiceException.java
! src/java.base/share/classes/java/nio/file/DirectoryIteratorException.java
! src/java.base/share/classes/java/nio/file/DirectoryNotEmptyException.java
! src/java.base/share/classes/java/nio/file/FileAlreadyExistsException.java
! src/java.base/share/classes/java/nio/file/FileSystemAlreadyExistsException.java
! src/java.base/share/classes/java/nio/file/FileSystemException.java
! src/java.base/share/classes/java/nio/file/FileSystemLoopException.java
! src/java.base/share/classes/java/nio/file/FileSystemNotFoundException.java
! src/java.base/share/classes/java/nio/file/InvalidPathException.java
! src/java.base/share/classes/java/nio/file/LinkPermission.java
! src/java.base/share/classes/java/nio/file/NoSuchFileException.java
! src/java.base/share/classes/java/nio/file/NotDirectoryException.java
! src/java.base/share/classes/java/nio/file/NotLinkException.java
! src/java.base/share/classes/java/nio/file/ProviderMismatchException.java
! src/java.base/share/classes/java/nio/file/ProviderNotFoundException.java
! src/java.base/share/classes/java/nio/file/ReadOnlyFileSystemException.java
! src/java.base/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java
! src/java.base/share/classes/java/text/AttributedCharacterIterator.java
! src/java.base/share/classes/java/text/ChoiceFormat.java
! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DateFormat.java
! src/java.base/share/classes/java/text/DateFormatSymbols.java
! src/java.base/share/classes/java/text/DecimalFormat.java
! src/java.base/share/classes/java/text/DecimalFormatSymbols.java
! src/java.base/share/classes/java/text/Format.java
! src/java.base/share/classes/java/text/MessageFormat.java
! src/java.base/share/classes/java/text/NumberFormat.java
! src/java.base/share/classes/java/text/ParseException.java
! src/java.base/share/classes/java/text/SimpleDateFormat.java
! src/java.base/share/classes/java/time/Clock.java
! src/java.base/share/classes/java/time/DateTimeException.java
! src/java.base/share/classes/java/time/Duration.java
! src/java.base/share/classes/java/time/Instant.java
! src/java.base/share/classes/java/time/LocalDate.java
! src/java.base/share/classes/java/time/LocalDateTime.java
! src/java.base/share/classes/java/time/LocalTime.java
! src/java.base/share/classes/java/time/MonthDay.java
! src/java.base/share/classes/java/time/OffsetDateTime.java
! src/java.base/share/classes/java/time/OffsetTime.java
! src/java.base/share/classes/java/time/Period.java
! src/java.base/share/classes/java/time/Ser.java
! src/java.base/share/classes/java/time/Year.java
! src/java.base/share/classes/java/time/YearMonth.java
! src/java.base/share/classes/java/time/ZoneId.java
! src/java.base/share/classes/java/time/ZoneOffset.java
! src/java.base/share/classes/java/time/ZoneRegion.java
! src/java.base/share/classes/java/time/ZonedDateTime.java
! src/java.base/share/classes/java/time/chrono/AbstractChronology.java
! src/java.base/share/classes/java/time/chrono/ChronoLocalDateImpl.java
! src/java.base/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/java.base/share/classes/java/time/chrono/ChronoPeriodImpl.java
! src/java.base/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/java.base/share/classes/java/time/chrono/HijrahChronology.java
! src/java.base/share/classes/java/time/chrono/HijrahDate.java
! src/java.base/share/classes/java/time/chrono/IsoChronology.java
! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java
! src/java.base/share/classes/java/time/chrono/JapaneseDate.java
! src/java.base/share/classes/java/time/chrono/JapaneseEra.java
! src/java.base/share/classes/java/time/chrono/MinguoChronology.java
! src/java.base/share/classes/java/time/chrono/MinguoDate.java
! src/java.base/share/classes/java/time/chrono/Ser.java
! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/java.base/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/java.base/share/classes/java/time/format/DateTimeParseException.java
! src/java.base/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java
! src/java.base/share/classes/java/time/temporal/ValueRange.java
! src/java.base/share/classes/java/time/temporal/WeekFields.java
! src/java.base/share/classes/java/util/AbstractMap.java
! src/java.base/share/classes/java/util/ArrayDeque.java
! src/java.base/share/classes/java/util/ArrayList.java
! src/java.base/share/classes/java/util/ArrayPrefixHelpers.java
! src/java.base/share/classes/java/util/Arrays.java
! src/java.base/share/classes/java/util/ArraysParallelSortHelpers.java
! src/java.base/share/classes/java/util/BitSet.java
! src/java.base/share/classes/java/util/Calendar.java
! src/java.base/share/classes/java/util/Collections.java
! src/java.base/share/classes/java/util/Comparators.java
! src/java.base/share/classes/java/util/ConcurrentModificationException.java
! src/java.base/share/classes/java/util/Currency.java
! src/java.base/share/classes/java/util/Date.java
! src/java.base/share/classes/java/util/DuplicateFormatFlagsException.java
! src/java.base/share/classes/java/util/EmptyStackException.java
! src/java.base/share/classes/java/util/EnumMap.java
! src/java.base/share/classes/java/util/EnumSet.java
! src/java.base/share/classes/java/util/EventObject.java
! src/java.base/share/classes/java/util/FormatFlagsConversionMismatchException.java
! src/java.base/share/classes/java/util/FormatterClosedException.java
! src/java.base/share/classes/java/util/GregorianCalendar.java
! src/java.base/share/classes/java/util/HashMap.java
! src/java.base/share/classes/java/util/HashSet.java
! src/java.base/share/classes/java/util/Hashtable.java
! src/java.base/share/classes/java/util/IdentityHashMap.java
! src/java.base/share/classes/java/util/IllegalFormatCodePointException.java
! src/java.base/share/classes/java/util/IllegalFormatConversionException.java
! src/java.base/share/classes/java/util/IllegalFormatException.java
! src/java.base/share/classes/java/util/IllegalFormatFlagsException.java
! src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java
! src/java.base/share/classes/java/util/IllegalFormatWidthException.java
! src/java.base/share/classes/java/util/IllformedLocaleException.java
! src/java.base/share/classes/java/util/ImmutableCollections.java
! src/java.base/share/classes/java/util/InputMismatchException.java
! src/java.base/share/classes/java/util/InvalidPropertiesFormatException.java
! src/java.base/share/classes/java/util/JapaneseImperialCalendar.java
! src/java.base/share/classes/java/util/JumboEnumSet.java
! src/java.base/share/classes/java/util/LinkedHashMap.java
! src/java.base/share/classes/java/util/LinkedHashSet.java
! src/java.base/share/classes/java/util/LinkedList.java
! src/java.base/share/classes/java/util/Locale.java
! src/java.base/share/classes/java/util/MissingFormatArgumentException.java
! src/java.base/share/classes/java/util/MissingFormatWidthException.java
! src/java.base/share/classes/java/util/MissingResourceException.java
! src/java.base/share/classes/java/util/NoSuchElementException.java
! src/java.base/share/classes/java/util/PriorityQueue.java
! src/java.base/share/classes/java/util/Properties.java
! src/java.base/share/classes/java/util/PropertyPermission.java
! src/java.base/share/classes/java/util/Random.java
! src/java.base/share/classes/java/util/RegularEnumSet.java
! src/java.base/share/classes/java/util/ServiceConfigurationError.java
! src/java.base/share/classes/java/util/SimpleTimeZone.java
! src/java.base/share/classes/java/util/Stack.java
! src/java.base/share/classes/java/util/TimeZone.java
! src/java.base/share/classes/java/util/TooManyListenersException.java
! src/java.base/share/classes/java/util/TreeMap.java
! src/java.base/share/classes/java/util/TreeSet.java
! src/java.base/share/classes/java/util/UUID.java
! src/java.base/share/classes/java/util/UnknownFormatConversionException.java
! src/java.base/share/classes/java/util/UnknownFormatFlagsException.java
! src/java.base/share/classes/java/util/Vector.java
! src/java.base/share/classes/java/util/jar/JarException.java
! src/java.base/share/classes/java/util/jar/JarVerifier.java
! src/java.base/share/classes/java/util/regex/Pattern.java
! src/java.base/share/classes/java/util/regex/PatternSyntaxException.java
! src/java.base/share/classes/java/util/zip/DataFormatException.java
! src/java.base/share/classes/java/util/zip/ZipError.java
! src/java.base/share/classes/java/util/zip/ZipException.java
! src/java.base/share/classes/javax/net/ssl/HandshakeCompletedEvent.java
! src/java.base/share/classes/javax/net/ssl/SSLException.java
! src/java.base/share/classes/javax/net/ssl/SSLHandshakeException.java
! src/java.base/share/classes/javax/net/ssl/SSLKeyException.java
! src/java.base/share/classes/javax/net/ssl/SSLPeerUnverifiedException.java
! src/java.base/share/classes/javax/net/ssl/SSLPermission.java
! src/java.base/share/classes/javax/net/ssl/SSLProtocolException.java
! src/java.base/share/classes/javax/net/ssl/SSLSessionBindingEvent.java
! src/java.base/share/classes/jdk/internal/loader/AbstractClassLoaderValue.java
! src/java.base/share/classes/jdk/internal/org/xml/sax/SAXException.java
! src/java.base/share/classes/jdk/internal/org/xml/sax/SAXNotRecognizedException.java
! src/java.base/share/classes/jdk/internal/org/xml/sax/SAXNotSupportedException.java
! src/java.base/share/classes/jdk/internal/org/xml/sax/SAXParseException.java
! src/java.base/share/classes/jdk/internal/util/jar/InvalidJarIndexError.java
! src/java.base/share/classes/jdk/internal/util/xml/XMLStreamException.java
! src/java.base/share/classes/sun/net/ConnectionResetException.java
! src/java.base/share/classes/sun/net/TelnetProtocolException.java
! src/java.base/share/classes/sun/net/ftp/FtpLoginException.java
! src/java.base/share/classes/sun/net/ftp/FtpProtocolException.java
! src/java.base/share/classes/sun/net/smtp/SmtpProtocolException.java
! src/java.base/share/classes/sun/net/www/ApplicationLaunchException.java
! src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java
! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheValue.java
! src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java
! src/java.base/share/classes/sun/net/www/protocol/http/BasicAuthentication.java
! src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
! src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java
! src/java.base/share/classes/sun/nio/ch/Reflect.java
! src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
! src/java.base/share/classes/sun/reflect/annotation/AnnotationTypeMismatchExceptionProxy.java
! src/java.base/share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java
! src/java.base/share/classes/sun/reflect/annotation/ExceptionProxy.java
! src/java.base/share/classes/sun/reflect/annotation/TypeNotPresentExceptionProxy.java
! src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/NotImplementedException.java
! src/java.base/share/classes/sun/util/BuddhistCalendar.java
! src/java.base/share/classes/sun/util/calendar/ZoneInfo.java
! src/java.base/share/classes/sun/util/locale/LocaleSyntaxException.java

Changeset: 4364524f8cac
Author:    pli
Date:      2019-08-30 09:38 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/4364524f8cac

8229797: [JVMCI] Clean up no longer used JVMCI::dependencies_invalid value
Reviewed-by: dlong, coleenp
Contributed-by: doug.simon at oracle.com, xiaohong.gong at arm.com

! src/hotspot/share/jvmci/jvmci.hpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCodeCacheProvider.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java

Changeset: bfb76c34e5c5
Author:    jiefu
Date:      2019-08-30 01:21 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/bfb76c34e5c5

8230376: [TESTBUG] runtime/StackTrace/HiddenFrameTest.java fails with release VM
Reviewed-by: dholmes

! test/hotspot/jtreg/runtime/StackTrace/HiddenFrameTest.java

Changeset: 6b539901e79e
Author:    stefank
Date:      2019-08-30 09:06 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/6b539901e79e

8230203: Replace markWord enums with typed constants
Reviewed-by: kbarrett, dholmes

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/arm/macroAssembler_arm.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/share/interpreter/bytecodeInterpreter.cpp
! src/hotspot/share/oops/markWord.hpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/runtime/thread.cpp

Changeset: 28915ebc6510
Author:    amlu
Date:      2019-08-30 16:44 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/28915ebc6510

8230004: jdk/internal/jimage/JImageOpenTest.java runs no test
Reviewed-by: alanb

! test/jdk/jdk/internal/jimage/JImageOpenTest.java
! test/jdk/jdk/internal/jimage/JImageReadTest.java
! test/jdk/jdk/internal/jimage/TEST.properties

Changeset: 421cc7c347cf
Author:    thartmann
Date:      2019-08-30 11:11 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/421cc7c347cf

8230388: Problemlist additional compiler/rtm tests
Summary: Putting tests on the problem list.
Reviewed-by: roland

! test/hotspot/jtreg/ProblemList.txt

Changeset: 4b436b5d1630
Author:    eosterlund
Date:      2019-08-30 10:44 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/4b436b5d1630

8230307: ZGC: Make zGlobals and zArguments OS agnostic
Reviewed-by: pliden, smonteith

+ src/hotspot/cpu/aarch64/gc/z/zArguments_aarch64.cpp
+ src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp
+ src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.hpp
+ src/hotspot/cpu/x86/gc/z/zArguments_x86.cpp
+ src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp
+ src/hotspot/cpu/x86/gc/z/zGlobals_x86.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zArguments_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.hpp
! src/hotspot/share/gc/z/zGlobals.hpp

Changeset: ed7eb20871c5
Author:    jlahoda
Date:      2019-08-30 12:24 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/ed7eb20871c5

8230105: -XDfind=diamond crashes
Summary: Avoiding side-effects in Analyzer's speculative attribution.
Reviewed-by: mcimadamore, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Analyzer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrContext.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/langtools/tools/javac/analyzer/AnalyzerMandatoryWarnings.java
+ test/langtools/tools/javac/analyzer/AnalyzerMandatoryWarnings.out
+ test/langtools/tools/javac/analyzer/AnalyzerNotQuiteSpeculative.java
+ test/langtools/tools/javac/analyzer/AnalyzerNotQuiteSpeculative.out
+ test/langtools/tools/javac/analyzer/DoNoRunAnalyzersWhenException.java
+ test/langtools/tools/javac/analyzer/StuckLambdas.java
+ test/langtools/tools/javac/analyzer/StuckLambdas.out

Changeset: 6bee0a3d2a3a
Author:    jpai
Date:      2019-08-28 20:05 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/6bee0a3d2a3a

8230310: SocksSocketImpl should handle the IllegalArgumentException thrown by ProxySelector.select usage
Summary: Catch the IAE thrown by ProxySelector.select and wrap it into a IOException
Reviewed-by: dfuchs

! src/java.base/share/classes/java/net/SocksSocketImpl.java
+ test/jdk/java/net/Socks/SocksSocketImplTest.java

Changeset: ef15850629cd
Author:    dfuchs
Date:      2019-08-30 12:44 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/ef15850629cd

8193596: java/net/DatagramPacket/ReuseBuf.java failed due to timeout
Summary: The test is changed to bind to InetAddress.getLocalHost() instead of binding to the wildcard.
Reviewed-by: alanb, dfuchs, msheppar
Contributed-by: Patrick Concannon <catrick.concannon at oracle.com>

! test/jdk/java/net/DatagramPacket/ReuseBuf.java

Changeset: 481a6a3449c8
Author:    thartmann
Date:      2019-08-30 16:17 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/481a6a3449c8

8230390: Problemlist SA tests with AOT
Summary: Putting tests on the problem list.
Reviewed-by: roland

! test/hotspot/jtreg/ProblemList-aot.txt

Changeset: 6f0215981777
Author:    kbarrett
Date:      2019-08-30 14:05 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/6f0215981777

8230327: Make G1DirtyCardQueueSet free-id init unconditional
Summary: Remove conditional init and make the set an inline member.
Reviewed-by: sjohanss, lkorinth, tschatzl

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
! src/hotspot/share/gc/g1/g1FreeIdSet.hpp

Changeset: f249fc6665d5
Author:    darcy
Date:      2019-08-30 11:26 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/f249fc6665d5

8230337: Clarify intention of Elements.{getPackageOf, getModuleOf}
Reviewed-by: jjg

! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
+ test/langtools/tools/javac/processing/model/util/elements/TestGetModuleOf.java
! test/langtools/tools/javac/processing/model/util/elements/TestGetPackageOf.java

Changeset: 374f3f9dda6f
Author:    tonyp
Date:      2019-08-30 14:58 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/374f3f9dda6f

8227224: GenCollectedHeap: add subspace transitions for young gen for gc+heap=info log lines
Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.hpp

Changeset: e9a0224b45a1
Author:    kbarrett
Date:      2019-08-30 15:36 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/e9a0224b45a1

8230372: Remove G1GCPhaseTimes::MergeLBProcessedBuffers
Summary: Removed no longer needed phase time.
Reviewed-by: sjohanss, tschatzl

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java

Changeset: 1262b3ddd7e4
Author:    darcy
Date:      2019-08-31 09:18 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/1262b3ddd7e4

8230373: Use java.io.Serial in generated exception types
Reviewed-by: erikj, alanb

! make/scripts/genExceptions.sh

Changeset: a333fdeb8de0
Author:    mbaesken
Date:      2019-08-30 09:37 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/a333fdeb8de0

8224214: [AIX] Remove support for legacy xlc compiler
Reviewed-by: erikj, kbarrett, mdoerr, dholmes

! make/autoconf/flags-cflags.m4
! make/autoconf/toolchain.m4
! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/share/gc/shared/oopStorage.hpp
! src/hotspot/share/gc/shared/ptrQueue.hpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/runtime/vm_version.cpp
! src/hotspot/share/utilities/globalDefinitions_xlc.hpp

Changeset: 47ce198d5cf1
Author:    shade
Date:      2019-09-02 11:31 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/47ce198d5cf1

8230238: Add another regression test for JDK-8134739
Reviewed-by: kvn

+ test/hotspot/jtreg/compiler/loopopts/superword/TestFuzzPreLoop.java

Changeset: 42a13b4e9553
Author:    shade
Date:      2019-09-02 12:10 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/42a13b4e9553

8230425: Shenandoah forces +UseNUMAInterleaving even after explicitly disabled
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp

Changeset: be5865bda5b9
Author:    mdoerr
Date:      2019-08-12 19:20 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/be5865bda5b9

8229422: Taskqueue: Outdated selection of weak memory model platforms
Reviewed-by: tschatzl, dholmes, drwhite

! src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp
! src/hotspot/cpu/arm/globalDefinitions_arm.hpp
! src/hotspot/cpu/ppc/globalDefinitions_ppc.hpp
! src/hotspot/cpu/s390/globalDefinitions_s390.hpp
! src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp
! src/hotspot/cpu/x86/globalDefinitions_x86.hpp
! src/hotspot/share/gc/shared/taskqueue.inline.hpp
! src/hotspot/share/utilities/globalDefinitions.hpp

Changeset: 94481c2b9388
Author:    mgronlun
Date:      2019-09-02 13:57 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/94481c2b9388

8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant
Reviewed-by: egahlin

! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp
! src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp

Changeset: ca9e3b68a969
Author:    mgronlun
Date:      2019-09-02 15:04 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/ca9e3b68a969

8227411: TestTimeMultiple.java failed "assert(!lease()) failed: invariant"
Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp

Changeset: c4ec55644b4b
Author:    michaelm
Date:      2019-09-02 15:58 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/c4ec55644b4b

8229235: com.sun.net.httpserver.HttpExchange should implement AutoCloseable
Reviewed-by: dfuchs, michaelm
Contributed-by: patrick.concannon at oracle.com

! src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
+ test/jdk/com/sun/net/httpserver/bugs/HttpExchange/AutoCloseableHttpExchange.java
+ test/jdk/com/sun/net/httpserver/bugs/HttpExchange/jdk.httpserver/sun/net/httpserver/HttpExchangeAccess.java

Changeset: f571cc16478a
Author:    michaelm
Date:      2019-09-02 15:59 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/f571cc16478a

Merge


Changeset: 2172fd713350
Author:    thartmann
Date:      2019-09-03 10:03 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/2172fd713350

8230428: Cleanup dead CastIP node code in formssel.cpp
Summary: Removed dead code.
Reviewed-by: roland

! src/hotspot/share/adlc/formssel.cpp

Changeset: 197f36af94f3
Author:    jpai
Date:      2019-08-30 17:22 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/197f36af94f3

8223714: HTTPSetAuthenticatorTest could be made more resilient
Summary: HTTPTestServer (in the test infrastructure) will no longer stop accepting requests if a previous request processing failed
Reviewed-by: dfuchs

! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTestServer.java

Changeset: d8f22418ca99
Author:    zgu
Date:      2019-09-03 13:55 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/d8f22418ca99

8230483: Shenandoah: consistently disable concurrent roots for Traversal mode
Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentRoots.cpp

Changeset: bf3fb5465543
Author:    vlivanov
Date:      2019-09-03 17:45 +0300
URL:       https://hg.openjdk.java.net/panama/dev/rev/bf3fb5465543

8227236: assert(singleton != __null && singleton != declared_interface) failed
Reviewed-by: dlong

! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciInstanceKlass.hpp
! src/hotspot/share/opto/doCall.cpp

Changeset: 849acc346a1d
Author:    dholmes
Date:      2019-09-03 23:42 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/849acc346a1d

6313903: Thread.sleep(3) might wake up immediately on windows
Reviewed-by: rehn, dcubed, rriggs

! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/runtime/os.cpp

Changeset: b7afd4b040d3
Author:    jjiang
Date:      2019-09-04 12:47 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/b7afd4b040d3

8226221: Update PKCS11 tests to use NSS 3.46 libs
Reviewed-by: xuelei

! test/jdk/sun/security/pkcs11/PKCS11Test.java

Changeset: 62926eb5e40e
Author:    mbaesken
Date:      2019-09-03 16:52 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/62926eb5e40e

8230485: add handling of aix tar in configure
Reviewed-by: erikj

! make/autoconf/basics.m4

Changeset: 0437b0f20312
Author:    mbaesken
Date:      2019-09-03 17:52 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/0437b0f20312

8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12
Reviewed-by: clanger, mseledtsov

! test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
! test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java
! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java

Changeset: 01d31583f25c
Author:    sjohanss
Date:      2019-09-04 09:47 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/01d31583f25c

8230431: Move G1 trace code from gcTrace* to G1 directory
Reviewed-by: kbarrett, lkorinth

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp
! src/hotspot/share/gc/g1/g1FullGCScope.hpp
! src/hotspot/share/gc/g1/g1IHOPControl.cpp
! src/hotspot/share/gc/g1/g1MMUTracker.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
+ src/hotspot/share/gc/g1/g1Trace.cpp
+ src/hotspot/share/gc/g1/g1Trace.hpp
! src/hotspot/share/gc/shared/gcTrace.cpp
! src/hotspot/share/gc/shared/gcTrace.hpp
! src/hotspot/share/gc/shared/gcTraceSend.cpp

Changeset: a645b2f7bece
Author:    sjohanss
Date:      2019-09-04 09:47 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/a645b2f7bece

8209802: Garbage collectors should register JFR types themselves to avoid build errors.
Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1HeapRegionEventSender.cpp
! src/hotspot/share/gc/g1/g1Trace.cpp
! src/hotspot/share/gc/g1/g1Trace.hpp
! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp

Changeset: dee322336e17
Author:    mdoerr
Date:      2019-09-04 14:21 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/dee322336e17

8230434: [C1, C2] Release barrier for volatile field stores in constructors implemented inconsistently
Reviewed-by: shade, lucy

! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/opto/parse1.cpp

Changeset: 9ee010450e84
Author:    eosterlund
Date:      2019-09-04 15:05 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9ee010450e84

8230401: ClassLoaderData::_keep_alive is read with wrong type in c2i entry barrier
Reviewed-by: zgu, tschatzl, iklam

! src/hotspot/share/classfile/classLoaderData.hpp

Changeset: cf8164854fda
Author:    xliu
Date:      2019-09-04 16:39 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/cf8164854fda

8229450: C2 compilation fails with assert(found_sfpt) failed
Reviewed-by: roland, thartmann

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopstripmining/LoadDependsOnIfIdenticalToLoopExit.java

Changeset: fbbe6672ae15
Author:    dfuchs
Date:      2019-09-04 16:42 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/fbbe6672ae15

8230159: Add test to verify that com.sun.net.httpserver.BasicAuthenticator constructors throw expected exceptions
Summary: new BasicAuthenticatorExceptionCheck.java test added
Reviewed-by: chegar, dfuchs, vtewari
Contributed-by: Patrick Concannon <patrick.concannon at oracle.com>

+ test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java

Changeset: 9ae63aa9fc22
Author:    dfuchs
Date:      2019-09-04 17:36 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/9ae63aa9fc22

8171405: java/net/URLConnection/ResendPostBody.java failed with "Error while cleaning up threads after test"
Summary: test cleaned up to improve safe termination
Reviewed-by: michaelm, vtewari, dfuchs
Contributed-by: Julia Boes <julia.boes at oracle.com>

! test/jdk/java/net/URLConnection/ResendPostBody.java

Changeset: 0daf32316b47
Author:    dfuchs
Date:      2019-09-04 18:10 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/0daf32316b47

8230435: Replace wildcard address with loopback or local host in tests - part 22
Summary: fixes tests to use the loopback address whenever possible. It also fixes some safe publishing issues, or add diagnostics in some of the tests.
Reviewed-by: michaelm

! test/jdk/com/sun/net/httpserver/bugs/8199849/BasicAuthenticatorCharset.java
! test/jdk/java/net/Authenticator/B4678055.java
! test/jdk/java/net/DatagramSocket/PortUnreachable.java
! test/jdk/java/net/URLConnection/RedirectLimit.java
! test/jdk/java/net/URLConnection/Responses.java
! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java
! test/jdk/sun/net/InetAddress/nameservice/simple/DefaultCaching.java
! test/jdk/sun/net/www/AuthHeaderTest.java
! test/jdk/sun/net/www/http/HttpClient/RetryPost.java
! test/jdk/sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java
! test/jdk/sun/net/www/protocol/https/HttpsClient/ProxyTunnelServer.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/TunnelProxy.java

Changeset: ef055f777569
Author:    mseledtsov
Date:      2019-09-04 13:57 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/ef055f777569

8230624: [TESTBUG] Problemlist JFR compiler/TestCodeSweeper.java
Summary: Added the test to the problem list
Reviewed-by: egahlin

! test/jdk/ProblemList.txt

Changeset: f016cc0874f0
Author:    darcy
Date:      2019-09-04 15:49 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/f016cc0874f0

8230626: Make UnknownFooException strings more informative
Reviewed-by: jjg, mr

! src/java.compiler/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java
! src/java.compiler/share/classes/javax/lang/model/element/UnknownElementException.java
! src/java.compiler/share/classes/javax/lang/model/type/UnknownTypeException.java

Changeset: 70cb43a67409
Author:    jwilhelm
Date:      2019-09-05 02:13 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/70cb43a67409

Added tag jdk-14+13 for changeset fbbe6672ae15

! .hgtags

Changeset: d80e4bce4588
Author:    jjiang
Date:      2019-09-05 14:55 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/d80e4bce4588

8228967: Trust/Key store and SSL context utilities for tests
Reviewed-by: xuelei

! test/jdk/java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java
! test/jdk/java/security/cert/X509CRL/VerifyDefault.java
! test/jdk/java/security/cert/X509Certificate/VerifyDefault.java
- test/jdk/java/security/testlibrary/CertUtils.java
! test/jdk/javax/net/ssl/DTLS/CipherSuite.java
! test/jdk/javax/net/ssl/DTLS/ClientAuth.java
! test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java
! test/jdk/javax/net/ssl/DTLS/InvalidCookie.java
! test/jdk/javax/net/ssl/DTLS/InvalidRecords.java
! test/jdk/javax/net/ssl/DTLS/NoMacInitialClientHello.java
! test/jdk/javax/net/ssl/DTLS/PacketLossRetransmission.java
! test/jdk/javax/net/ssl/DTLS/Reordered.java
! test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
! test/jdk/javax/net/ssl/DTLS/Retransmission.java
! test/jdk/javax/net/ssl/DTLS/WeakCipherSuite.java
! test/jdk/sun/security/mscapi/KeytoolChangeAlias.java
! test/jdk/sun/security/util/HostnameMatcher/NullHostnameCheck.java
! test/jdk/sun/security/util/HostnameMatcher/TestHostnameChecker.java
+ test/lib/jdk/test/lib/security/CertUtils.java
+ test/lib/jdk/test/lib/security/KeyEntry.java
+ test/lib/jdk/test/lib/security/KeyStoreUtils.java
+ test/lib/jdk/test/lib/security/SSLContextBuilder.java

Changeset: aba258cd7df8
Author:    eosterlund
Date:      2019-09-05 08:26 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/aba258cd7df8

8229189: Improve JFR leak profiler tracing to deal with discontiguous heaps
Reviewed-by: mgronlun, egahlin

! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp
! src/hotspot/share/jfr/leakprofiler/chains/bitset.cpp
! src/hotspot/share/jfr/leakprofiler/chains/bitset.hpp
+ src/hotspot/share/jfr/leakprofiler/chains/bitset.inline.hpp
! src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.cpp
! src/hotspot/share/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp
! src/hotspot/share/utilities/hashtable.cpp

Changeset: dd84de796f2c
Author:    eosterlund
Date:      2019-09-05 08:26 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/dd84de796f2c

8224815: Remove non-GC uses of CollectedHeap::is_in_reserved()
Reviewed-by: stefank, coleenp

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp
! src/hotspot/cpu/sparc/macroAssembler_sparc.cpp
! src/hotspot/cpu/x86/relocInfo_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/code/debugInfo.cpp
! src/hotspot/share/gc/cms/cmsHeap.hpp
! src/hotspot/share/gc/cms/jvmFlagConstraintsCMS.cpp
! src/hotspot/share/gc/epsilon/epsilonHeap.cpp
! src/hotspot/share/gc/epsilon/epsilonHeap.hpp
! src/hotspot/share/gc/g1/g1Allocator.inline.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
! src/hotspot/share/gc/serial/markSweep.cpp
! src/hotspot/share/gc/serial/markSweep.inline.hpp
! src/hotspot/share/gc/shared/blockOffsetTable.cpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shared/gcVMOperations.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.hpp
! src/hotspot/share/gc/shared/markBitMap.cpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zCollectedHeap.hpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/filemap.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/memory/universe.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/memory/virtualspace.hpp
! src/hotspot/share/oops/compressedOops.cpp
! src/hotspot/share/oops/compressedOops.hpp
! src/hotspot/share/oops/compressedOops.inline.hpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/oops/oopsHierarchy.hpp
! src/hotspot/share/oops/symbol.cpp
! src/hotspot/share/opto/machnode.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/runtime/jniHandles.cpp
! test/hotspot/gtest/gc/shared/test_collectedHeap.cpp
! test/hotspot/jtreg/gc/g1/TestLargePageUseForHeap.java

Changeset: c8bc506106e3
Author:    stuefe
Date:      2019-09-05 11:09 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/c8bc506106e3

8230642: 8224815 broke Shenandoah build
Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp

Changeset: 9726449d2644
Author:    mbaesken
Date:      2019-09-05 09:59 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9726449d2644

8230466: check malloc/calloc results in jdk.hotspot.agent
Reviewed-by: cjplummer, ysuenaga, sspitsyn

! src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c
! src/jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m
! src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c

Changeset: a3c63a9dfb2c
Author:    jlahoda
Date:      2019-09-05 12:39 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/a3c63a9dfb2c

8177068: incomplete classpath causes NPE in Flow
Summary: Undo completions that failed during speculative attribution, so that the appropriate CompletionFailures are thrown again and properly reported.
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/DeferredCompletionFailureHandler.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/langtools/tools/javac/T8177068/NoCompletionFailureSkipOnSpeculativeAttribution.java

Changeset: 86b95fc6ca32
Author:    thartmann
Date:      2019-09-05 13:56 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/86b95fc6ca32

8229496: SIGFPE (division by zero) in C2 OSR compiled method
Summary: Adding a CastNode to keep the dependency between the div/mod operation and the zero check.
Reviewed-by: roland, mdoerr

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/sparc/sparc.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/opto/castnode.cpp
! src/hotspot/share/opto/castnode.hpp
! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/runtime/vmStructs.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestDivZeroCheckControl.java

Changeset: 5f5ca2e02f6e
Author:    shade
Date:      2019-09-05 19:24 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/5f5ca2e02f6e

8230646: Epsilon does not extend TLABs to max size
Reviewed-by: tschatzl, zgu

! src/hotspot/share/gc/epsilon/epsilonHeap.cpp

Changeset: 12885822f0c5
Author:    joehw
Date:      2019-09-05 17:26 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/12885822f0c5

8228854: Default ErrorListener reports warnings and errors to the console
Reviewed-by: lancea

! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/MessageHandler.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/TransletOutputHandlerFactory.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToTextStream.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToUnknownStream.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToXMLStream.java
! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java
! src/java.xml/share/classes/javax/xml/transform/ErrorListener.java
! src/java.xml/share/classes/javax/xml/transform/package-info.java
+ src/java.xml/share/classes/jdk/xml/internal/TransformErrorListener.java
! test/jaxp/javax/xml/jaxp/unittest/transform/ErrorListenerTest.java

Changeset: 06f3d5092832
Author:    ccheung
Date:      2019-09-05 11:12 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/06f3d5092832

8230632: [TESTBUG] appcds/NonExistClasspath.java and ClassPathAttr.java failed when running in hotspot_appcds_dynamic test group
Summary: Exclude NonExistClasspath.java from the test group; increase timeout for ClassPathAttr.java.
Reviewed-by: dcubed, iklam

! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java

Changeset: 6eb44470aa98
Author:    bpb
Date:      2019-09-05 14:12 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/6eb44470aa98

8229280: Test failures on several linux hosts after JDK-8181493
Reviewed-by: alanb, clanger, dfuchs

! test/jdk/java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java

Changeset: cfd0f43fdf5f
Author:    dholmes
Date:      2019-09-05 18:39 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/cfd0f43fdf5f

8227563: jvmti/scenarios/contention/TC05/tc05t001 fails due to "ERROR: tc05t001.cpp, 278: (waitedThreadCpuTime - waitThreadCpuTime) < (EXPECTED_ACCURACY * 1000000)"
Reviewed-by: amenkov, cjplummer, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp

Changeset: 1e3f58d409f7
Author:    darcy
Date:      2019-09-05 15:55 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/1e3f58d409f7

8230681: Add @since tag to java.io.Serial
Reviewed-by: lancea, bpb

! src/java.base/share/classes/java/io/Serial.java

Changeset: 930551e8ac62
Author:    bpb
Date:      2019-09-05 16:26 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/930551e8ac62

8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause
Reviewed-by: alanb, rriggs, lancea, darcy

! src/java.base/share/classes/java/io/PrintStream.java
+ test/jdk/java/io/PrintStream/WriteBytes.java

Changeset: 7ac4273bb49b
Author:    naoto
Date:      2019-09-05 17:38 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/7ac4273bb49b

8229831: Upgrade Character.isUnicodeIdentifierStart/Part() methods to the latest standard
Reviewed-by: rriggs

! make/data/characterdata/CharacterData00.java.template
! make/data/characterdata/CharacterData01.java.template
! make/data/characterdata/CharacterData02.java.template
! make/data/characterdata/CharacterData0E.java.template
! make/data/characterdata/CharacterDataLatin1.java.template
+ make/data/unicodedata/DerivedCoreProperties.txt
! make/gensrc/GensrcCharacterData.gmk
! make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java
! make/jdk/src/classes/build/tools/generatecharacter/PropList.java
! src/java.base/share/classes/java/lang/Character.java
! test/jdk/java/lang/Character/CharPropTest.java
! test/jdk/java/lang/Character/CheckProp.java
! test/jdk/lib/testlibrary/java/lang/UCDFiles.java

Changeset: 66c880e5d21d
Author:    shade
Date:      2019-09-06 09:26 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/66c880e5d21d

8230671: x86_32 build failures after JDK-8229496
Reviewed-by: thartmann

! src/hotspot/cpu/x86/x86_32.ad

Changeset: d6e2dbf20eaa
Author:    rrich
Date:      2019-08-30 09:24 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/d6e2dbf20eaa

8230363: C2: Let ConnectionGraph::not_global_escape(Node* n) return false if n is not in the CG
Reviewed-by: thartmann, mdoerr

! src/hotspot/share/opto/escape.cpp

Changeset: 5aaf53d4fe63
Author:    dfuchs
Date:      2019-09-06 14:04 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/5aaf53d4fe63

8230694: http.keepAlive system property is inconsistently/incorrectly documented
Summary: trivially fixed the net-properties.html file
Reviewed-by: alanb

! src/java.base/share/classes/java/net/doc-files/net-properties.html

Changeset: 1ebc2f316e45
Author:    clanger
Date:      2019-09-06 15:13 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/1ebc2f316e45

8230666: Exclude serviceability/sa/TestInstanceKlassSize.java on linuxppc64 and linuxppc64le
Reviewed-by: dcubed

! test/hotspot/jtreg/ProblemList.txt

Changeset: 9162feb63c42
Author:    kbarrett
Date:      2019-09-06 13:38 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/9162feb63c42

8230404: Refactor logged card refinement support in G1DirtyCardQueueSet
Summary: Separate concurrent refinement from STW refinement.
Reviewed-by: sjohanss, tschatzl

! src/hotspot/share/gc/g1/g1CardTableEntryClosure.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
! src/hotspot/share/gc/g1/g1HotCardCache.cpp
! src/hotspot/share/gc/g1/g1RemSet.cpp

Changeset: 318cd16cc202
Author:    dlong
Date:      2019-09-06 14:54 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/318cd16cc202

8230680: latest Graal unittests depend on jdk.internal.module
Reviewed-by: iignatyev

! make/test/JtregGraalUnit.gmk

Changeset: 378007c18687
Author:    erikj
Date:      2019-09-06 12:41 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/378007c18687

8230715: Baseline compare build on Windows fails intermittently in file type for jvm.pdb
Reviewed-by: mikael

! make/scripts/compare.sh

Changeset: aa3715655834
Author:    redestad
Date:      2019-09-07 15:44 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/aa3715655834

8230662: Remove dead code from MethodTypeForm
Reviewed-by: vlivanov, mchung

! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java

Changeset: c7374ff3f3a3
Author:    zgu
Date:      2019-09-07 10:04 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/c7374ff3f3a3

8230730: UseCompressedOops test crash with assertion failure
Reviewed-by: stefank, eosterlund

! src/hotspot/share/oops/compressedOops.cpp

Changeset: d99af76d7689
Author:    iveresov
Date:      2019-09-07 10:05 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/d99af76d7689

8226953: AOT: assert(oopDesc::is_oop(obj)) failed: not an oop
Reviewed-by: dlong

! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotForeignCallLinkage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotForeignCallLinkageImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotHostForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ThreadSubstitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/ForeignCallStub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/MethodSubstitutionTest.java

Changeset: d8902e9c307c
Author:    dholmes
Date:      2019-09-07 18:48 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/d8902e9c307c

8230422: Convert uninterruptible os::sleep calls to os::naked_short_sleep
Reviewed-by: kbarrett, dcubed, shade

! src/hotspot/cpu/x86/rdtsc_x86.cpp
! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp
! src/hotspot/share/gc/cms/parNewGeneration.cpp
! src/hotspot/share/gc/parallel/psCardTable.cpp
! src/hotspot/share/gc/parallel/psOldGen.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.cpp
! src/hotspot/share/gc/shared/taskqueue.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
! src/hotspot/share/jvmci/jvmciCompiler.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/safepoint.cpp
! test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp
! test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp
! test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp

Changeset: 95c206a3e53c
Author:    xgong
Date:      2019-09-09 11:19 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/95c206a3e53c

8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to graal problem list.
Reviewed-by: dlong, thartmann

! test/hotspot/jtreg/ProblemList-graal.txt

Changeset: 647d623650d3
Author:    rehn
Date:      2019-09-09 09:05 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/647d623650d3

8228758: assert(_no_handle_mark_nesting == 0) failed: allocating handle inside NoHandleMark
Reviewed-by: coleenp, dcubed, dholmes

! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp

Changeset: 3277a7454dc5
Author:    stefank
Date:      2019-09-04 11:05 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/3277a7454dc5

8224599: Remove globals_ext.hpp
Reviewed-by: coleenp, kvn, gziemski, ehelin

! src/hotspot/share/gc/cms/jvmFlagConstraintsCMS.hpp
! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.hpp
! src/hotspot/share/gc/parallel/jvmFlagConstraintsParallel.hpp
! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.hpp
! src/hotspot/share/runtime/flags/jvmFlag.cpp
! src/hotspot/share/runtime/flags/jvmFlag.hpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintList.cpp
! src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp
! src/hotspot/share/runtime/flags/jvmFlagWriteableList.cpp
! src/hotspot/share/runtime/globals.cpp
! src/hotspot/share/runtime/globals.hpp
- src/hotspot/share/runtime/globals_ext.hpp
! src/hotspot/share/runtime/globals_extension.hpp
! src/hotspot/share/runtime/os_ext.hpp
! test/hotspot/gtest/runtime/test_globals.cpp

Changeset: a0a67b6b8183
Author:    stefank
Date:      2019-09-04 11:38 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/a0a67b6b8183

8230561: Remove logTag_ext.hpp
Reviewed-by: dholmes, coleenp

! src/hotspot/share/logging/logTag.hpp
- src/hotspot/share/logging/logTag_ext.hpp

Changeset: 7efe5923cfdc
Author:    stefank
Date:      2019-09-04 13:06 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/7efe5923cfdc

8230562: Remove g1HeapSizingPolicy_ext.cpp
Reviewed-by: dholmes, sjohanss

! src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp
- src/hotspot/share/gc/g1/g1HeapSizingPolicy_ext.cpp

Changeset: 01905d6a828b
Author:    stefank
Date:      2019-09-04 13:06 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/01905d6a828b

8230563: Remove arguments_ext.cpp
Reviewed-by: dholmes, coleenp

! src/hotspot/share/runtime/arguments.cpp
- src/hotspot/share/runtime/arguments_ext.cpp

Changeset: 8009a9c36251
Author:    stefank
Date:      2019-09-04 13:07 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8009a9c36251

8230564: Remove os_ext.hpp
Reviewed-by: coleenp, dholmes

! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
- src/hotspot/share/runtime/os_ext.hpp

Changeset: 9fba708740d6
Author:    glaubitz
Date:      2019-09-09 15:14 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9fba708740d6

8230708: Hotspot fails to build on linux-sparc with gcc-9
Reviewed-by: dholmes, phh

! src/hotspot/cpu/sparc/nativeInst_sparc.hpp

Changeset: 505e28fe1769
Author:    mdoerr
Date:      2019-09-09 15:42 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/505e28fe1769

8230669: [s390] C1: assert(is_bound() || is_unused()) failed: Label was never bound to a location, but it was used as a jmp target
Reviewed-by: phh, xliu

! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/share/c1/c1_Compilation.hpp

Changeset: bc4e7a84e89d
Author:    dfuchs
Date:      2019-09-09 16:13 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/bc4e7a84e89d

8230132: java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java to skip Teredo Tunneling Pseudo-Interface
Summary: The test is updated to skip Teredo pseudo interfaces on windows.
Reviewed-by: michaelm, vtewari, aefimov
Contributed-by: patrick.concannon at oracle.com

! test/jdk/java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java

Changeset: 1a296c9064dc
Author:    jpai
Date:      2019-08-24 09:31 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/1a296c9064dc

8177389: Hyphen "-" should be removed in URL class documentation
Summary: javadoc of java.net.URL constructor updated to remove an unnecessary hyphen
Reviewed-by: dfuchs

! src/java.base/share/classes/java/net/URL.java

Changeset: ee230ad8cfef
Author:    darcy
Date:      2019-09-09 10:13 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/ee230ad8cfef

8230723: Remove default constructors from java.lang and java.io
Reviewed-by: bpb, rriggs

! src/java.base/share/classes/java/io/InputStream.java
! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/io/ObjectOutputStream.java
! src/java.base/share/classes/java/io/OutputStream.java
! src/java.base/share/classes/java/lang/InheritableThreadLocal.java
! src/java.base/share/classes/java/lang/LiveStackFrame.java
! src/java.base/share/classes/java/lang/ThreadDeath.java
! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java
! src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
! src/java.base/share/classes/java/lang/reflect/Modifier.java

Changeset: 734f7711f87c
Author:    dfuchs
Date:      2019-09-09 18:23 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/734f7711f87c

8230526: jdk.internal.net.http.PlainProxyConnection is never reused by HttpClient
Summary: fixed the PlainProxyConnection lookup key.
Reviewed-by: chegar

! src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java
+ test/jdk/java/net/httpclient/PlainProxyConnectionTest.java

Changeset: db92a157dd70
Author:    bchristi
Date:      2019-09-09 11:04 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/db92a157dd70

8212117: Class.forName may return a reference to a loaded but not linked Class
Reviewed-by: dholmes, mchung

! make/hotspot/symbols/symbols-unix
! src/hotspot/share/include/jvm.h
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvm_misc.hpp
! src/hotspot/share/runtime/globals.hpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/sun/launcher/LauncherHelper.java
! src/java.base/share/native/libjava/Class.c
! test/hotspot/jtreg/gc/logging/TestMetaSpaceLog.java
+ test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java
+ test/hotspot/jtreg/serviceability/jvmti/ClassStatus/libClassStatus.c

Changeset: f894baf8d871
Author:    amenkov
Date:      2019-09-09 12:00 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/f894baf8d871

8230516: invalid html in jdwp-protocol.html
Reviewed-by: dtitov, sspitsyn

! make/jdk/src/classes/build/tools/jdwpgen/ConstantNode.java
! make/jdk/src/classes/build/tools/jdwpgen/ConstantSetNode.java

Changeset: b553ad95acf0
Author:    naoto
Date:      2019-09-09 12:42 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/b553ad95acf0

8230284: Accounting currency format support does not cope with explicit number system
Reviewed-by: rriggs

! make/jdk/src/classes/build/tools/cldrconverter/Bundle.java
! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
! make/jdk/src/classes/build/tools/cldrconverter/LDMLParseHandler.java
! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java
! test/jdk/java/text/Format/NumberFormat/DFSMinusPerCentMill.java
! test/jdk/java/util/Locale/bcp47u/CurrencyFormatTests.java
! test/jdk/sun/text/resources/LocaleData.cldr
! test/jdk/sun/text/resources/LocaleDataTest.java

Changeset: baa4dd528de0
Author:    kbarrett
Date:      2019-09-09 16:54 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/baa4dd528de0

8221361: Eliminate two-phase initialization for PtrQueueSet classes
Summary: Move allocator and CBL monitor init to constructor.
Reviewed-by: tschatzl, shade

! src/hotspot/share/gc/g1/g1BarrierSet.cpp
! src/hotspot/share/gc/g1/g1BarrierSet.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.cpp
! src/hotspot/share/gc/g1/g1SATBMarkQueueSet.cpp
! src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp
! src/hotspot/share/gc/shared/ptrQueue.cpp
! src/hotspot/share/gc/shared/ptrQueue.hpp
! src/hotspot/share/gc/shared/satbMarkQueue.cpp
! src/hotspot/share/gc/shared/satbMarkQueue.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp

Changeset: 44f3609f46af
Author:    godin
Date:      2019-09-10 07:42 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/44f3609f46af

8207800: always_do_update_barrier is unused
Reviewed-by: shade, tschatzl
Contributed-by: Evgeny Mandrikov <mandrikov at gmail.com>

! src/hotspot/share/gc/cms/cmsHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/shared/genArguments.cpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/oop.hpp

Changeset: fafba5cf3546
Author:    chagedorn
Date:      2019-09-10 08:43 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/fafba5cf3546

8225653: Provide more information when hitting SIGILL from HaltNode
Summary: Add information string for each HaltNode which is printed if hit at runtime.
Reviewed-by: vlivanov, thartmann

! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/adlc/main.cpp
! src/hotspot/share/adlc/output_c.cpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/rootnode.cpp
! src/hotspot/share/opto/rootnode.hpp

Changeset: 65cad575ace3
Author:    xgong
Date:      2019-09-10 14:52 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/65cad575ace3

8230454: [Graal] Add "com/sun/crypto/provider/KeyFactory/TestProviderLeak.java" to Graal problem list.
Reviewed-by: dlong

! test/jdk/ProblemList-graal.txt

Changeset: d8f60e5bb4a6
Author:    mbaesken
Date:      2019-09-06 16:15 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/d8f60e5bb4a6

8230711: ConnectionGraph::unique_java_object(Node* N) return NULL if n is not in the CG
Reviewed-by: mdoerr

! src/hotspot/share/opto/escape.cpp

Changeset: 3fee0e6b54f5
Author:    mbaesken
Date:      2019-09-09 16:34 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/3fee0e6b54f5

8230769: BufImg_SetupICM add ReleasePrimitiveArrayCritical call in early return
Reviewed-by: prr, stuefe

! src/java.desktop/share/native/libawt/awt/image/BufImgSurfaceData.c

Changeset: 8407928b9fe5
Author:    pliden
Date:      2019-09-10 11:11 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8407928b9fe5

8230566: ZGC: Don't substitute klass pointer during array clearing
Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/z/zBarrier.cpp
! src/hotspot/share/gc/z/zBarrier.hpp
! src/hotspot/share/gc/z/zBarrier.inline.hpp
! src/hotspot/share/gc/z/zHeap.hpp
! src/hotspot/share/gc/z/zHeap.inline.hpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/gc/z/zMark.hpp
! src/hotspot/share/gc/z/zMark.inline.hpp
! src/hotspot/share/gc/z/zMarkStackEntry.hpp
! src/hotspot/share/gc/z/zObjArrayAllocator.cpp
! src/hotspot/share/gc/z/zObjArrayAllocator.hpp
! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRootsIterator.cpp
! src/hotspot/share/gc/z/zRootsIterator.hpp
! src/hotspot/share/gc/z/zThreadLocalData.hpp

Changeset: 8a066d872553
Author:    hannesw
Date:      2019-09-10 15:30 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8a066d872553

8230766: Changed message in IllegalMonitorStateException
Reviewed-by: attila, jlaskey

! test/nashorn/script/basic/javaexceptions.js.EXPECTED

Changeset: 336687518f92
Author:    hannesw
Date:      2019-09-10 15:35 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/336687518f92

8230709: Array index out of bounds in ES6 mode
Reviewed-by: attila

! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LexicalContext.java
+ test/nashorn/script/basic/es6/JDK-8230709.js

Changeset: 6eca527d3689
Author:    igerasim
Date:      2019-09-10 09:08 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/6eca527d3689

8230303: JDB hangs when running monitor command
Reviewed-by: sspitsyn

! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java
+ test/hotspot/jtreg/vmTestbase/nsk/jdb/monitor/monitor002/monitor002.java
+ test/hotspot/jtreg/vmTestbase/nsk/jdb/monitor/monitor002/monitor002a.java

Changeset: 6488adc963b8
Author:    lmesnik
Date:      2019-09-10 09:12 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/6488adc963b8

8230781: Add JTREG_FAILURE_HANDLER_TIMEOUT to control timeout handler timeout
Reviewed-by: erikj

! make/RunTests.gmk

Changeset: 874edfe72c3e
Author:    darcy
Date:      2019-09-10 10:24 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/874edfe72c3e

8225761: Update --release 13 symbol information after JDK 13 GA
Reviewed-by: jlahoda

! make/data/symbols/java.base-D.sym.txt
+ make/data/symbols/java.security.jgss-D.sym.txt
! make/data/symbols/jdk.compiler-D.sym.txt
+ make/data/symbols/jdk.jartool-D.sym.txt
! make/data/symbols/symbols

Changeset: 41f119856e7c
Author:    mchung
Date:      2019-09-10 10:35 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/41f119856e7c

8229785: MethodType::fromMethodDescriptorString should require security permission if loader is null
Reviewed-by: vromero

! src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java
+ test/jdk/java/lang/constant/methodTypeDesc/ResolveConstantDesc.java
+ test/jdk/java/lang/constant/methodTypeDesc/jdk.unsupported/sun/misc/Test.java
+ test/jdk/java/lang/constant/methodTypeDesc/test.policy
! test/jdk/java/lang/invoke/FindClassSecurityManager.java
+ test/jdk/java/lang/invoke/MethodTypeSecurityManager.java
- test/jdk/java/lang/invoke/findclass.security.policy
+ test/jdk/java/lang/invoke/getclassloader.policy

Changeset: 8db87a43a1ce
Author:    shade
Date:      2019-09-10 19:58 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8db87a43a1ce

8230813: Add JDK-8010500 to compiler/loopopts/superword/TestFuzzPreLoop.java bug list
Reviewed-by: zgu

! test/hotspot/jtreg/compiler/loopopts/superword/TestFuzzPreLoop.java

Changeset: 931799bfbc10
Author:    naoto
Date:      2019-09-10 12:51 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/931799bfbc10

8229960: Remove sun.nio.cs.map system property
Reviewed-by: alanb

! make/data/charsetmapping/charsets
! make/data/charsetmapping/stdcs-linux
! make/data/charsetmapping/stdcs-windows
! src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template
! src/java.base/share/lib/security/default.policy
! src/jdk.charsets/share/classes/sun/nio/cs/ext/ExtendedCharsets.java.template
! test/jdk/java/nio/charset/coders/Check.java
- test/jdk/java/nio/charset/coders/SJISMappingPropTest.java
- test/jdk/java/nio/charset/coders/SJISPropTest.java
- test/jdk/java/nio/charset/coders/ref.windows-31j
! test/jdk/java/nio/charset/spi/default-pol
! test/jdk/sun/nio/cs/TestMS5022X.java

Changeset: 8b08eaf9a0eb
Author:    tschatzl
Date:      2019-09-11 10:19 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8b08eaf9a0eb

8230794: Improve assert to get more information about the JDK-8227695 failure
Reviewed-by: kbarrett, sjohanss

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: 9046db64ca39
Author:    lkorinth
Date:      2019-09-11 14:16 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9046db64ca39

8227168: Cleanup usage of NEW_C_HEAP_ARRAY
Reviewed-by: coleenp, dholmes, kbarrett, tschatzl

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/aix/os_perf_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/linux/os_perf_linux.cpp
! src/hotspot/os/solaris/os_perf_solaris.cpp
! src/hotspot/os/solaris/os_solaris.cpp
! src/hotspot/os/windows/os_perf_windows.cpp
! src/hotspot/os/windows/perfMemory_windows.cpp
! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/compiler/oopMap.cpp
! src/hotspot/share/gc/cms/parNewGeneration.cpp
! src/hotspot/share/gc/parallel/psCompactionManager.cpp
! src/hotspot/share/gc/shared/cardTableRS.cpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/interpreter/oopMapCache.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/perfData.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/services/memoryManager.cpp

Changeset: cddef3bde924
Author:    lkorinth
Date:      2019-09-11 14:16 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/cddef3bde924

8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
Reviewed-by: dholmes, kbarrett, tschatzl

! src/hotspot/os/aix/perfMemory_aix.cpp
! src/hotspot/os/bsd/perfMemory_bsd.cpp
! src/hotspot/os/linux/perfMemory_linux.cpp
! src/hotspot/os/solaris/os_perf_solaris.cpp
! src/hotspot/os/solaris/os_solaris.cpp
! src/hotspot/os/solaris/perfMemory_solaris.cpp
! src/hotspot/os/windows/os_perf_windows.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/perfMemory_windows.cpp
! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/code/codeBlob.cpp
! src/hotspot/share/gc/cms/gSpaceCounters.cpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp
! src/hotspot/share/gc/g1/g1CollectionSet.cpp
! src/hotspot/share/gc/g1/g1RemSetSummary.cpp
! src/hotspot/share/gc/g1/heapRegionManager.cpp
! src/hotspot/share/gc/g1/sparsePRT.cpp
! src/hotspot/share/gc/parallel/spaceCounters.cpp
! src/hotspot/share/gc/serial/cSpaceCounters.cpp
! src/hotspot/share/gc/shared/cardTableRS.cpp
! src/hotspot/share/gc/shared/collectorCounters.cpp
! src/hotspot/share/gc/shared/generationCounters.cpp
! src/hotspot/share/gc/shared/hSpaceCounters.cpp
! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/gc/z/zArray.inline.hpp
! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
! src/hotspot/share/jfr/support/jfrThreadLocal.cpp
! src/hotspot/share/jfr/utilities/jfrHashtable.hpp
! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/os_perf.hpp
! src/hotspot/share/runtime/perfData.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/services/diagnosticArgument.cpp
! src/hotspot/share/utilities/hashtable.cpp

Changeset: d52f77f0acb5
Author:    naoto
Date:      2019-09-11 08:50 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/d52f77f0acb5

8230136: DateTimeFormatterBuilder.FractionPrinterParser#parse fails to verify minWidth
Reviewed-by: joehw, scolebourne, rriggs

! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java

Changeset: 03964761a23c
Author:    bobv
Date:      2019-09-11 17:30 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/03964761a23c

8229202: Docker reporting causes secondary crashes in error handling
Reviewed-by: coleenp, hseigel, mseledtsov

! src/hotspot/os/linux/osContainer_linux.hpp

Changeset: e2de6e166880
Author:    amenkov
Date:      2019-09-11 11:55 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/e2de6e166880

8192057: com/sun/jdi/BadHandshakeTest.java fails with java.net.ConnectException
Reviewed-by: sspitsyn, rrich

! test/jdk/com/sun/jdi/BadHandshakeTest.java

Changeset: e64fec9f1773
Author:    bpb
Date:      2019-09-11 12:32 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/e64fec9f1773

8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF
Reviewed-by: rriggs, dfuchs

! src/java.base/share/classes/java/io/BufferedReader.java
! src/java.base/share/classes/java/io/LineNumberReader.java
! test/jdk/java/io/LineNumberReader/Read.java

Changeset: 91bc4d6c4054
Author:    iklam
Date:      2019-09-11 13:28 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/91bc4d6c4054

8230674: Heap dumps should exclude dormant CDS archived objects of unloaded classes
Reviewed-by: dholmes, jiangli

! src/hotspot/share/services/heapDumper.cpp


From maurizio.cimadamore at oracle.com  Wed Sep 11 22:09:23 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 11 Sep 2019 22:09:23 +0000
Subject: hg: panama/dev: Automatic merge with default
Message-ID: <201909112209.x8BM9NeW022653@aojmv0008.oracle.com>

Changeset: 5ed257c4f7d9
Author:    mcimadamore
Date:      2019-09-11 22:09 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/5ed257c4f7d9

Automatic merge with default

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zArguments_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/classfile/javaClasses.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
- src/hotspot/share/gc/g1/g1HeapSizingPolicy_ext.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.hpp
- src/hotspot/share/gc/parallel/gcTaskThread.cpp
- src/hotspot/share/gc/parallel/gcTaskThread.hpp
- src/hotspot/share/gc/parallel/pcTasks.cpp
- src/hotspot/share/gc/parallel/pcTasks.hpp
- src/hotspot/share/gc/parallel/psTasks.cpp
- src/hotspot/share/gc/parallel/psTasks.hpp
! src/hotspot/share/logging/logTag.hpp
- src/hotspot/share/logging/logTag_ext.hpp
- src/hotspot/share/oops/markOop.cpp
- src/hotspot/share/oops/markOop.hpp
- src/hotspot/share/oops/markOop.inline.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/prims/unsafe.cpp
- src/hotspot/share/runtime/arguments_ext.cpp
- src/hotspot/share/runtime/globals_ext.hpp
- src/hotspot/share/runtime/os_ext.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
- src/jdk.hotspot.agent/share/classes/META-INF/services/com.sun.jdi.connect.Connector
- test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeArray.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeStringArray.java
- test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java
- test/jdk/java/lang/invoke/findclass.security.policy
- test/jdk/java/net/Socket/reset/Test.java
- test/jdk/java/nio/charset/coders/SJISMappingPropTest.java
- test/jdk/java/nio/charset/coders/SJISPropTest.java
- test/jdk/java/nio/charset/coders/ref.windows-31j
- test/jdk/java/security/testlibrary/CertUtils.java
- test/jdk/javax/xml/jaxp/testng/validation/jdk8037819/BasicTest1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java


From maurizio.cimadamore at oracle.com  Wed Sep 11 22:09:46 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 11 Sep 2019 22:09:46 +0000
Subject: hg: panama/dev: Automatic merge with default
Message-ID: <201909112209.x8BM9l05023068@aojmv0008.oracle.com>

Changeset: ba9eb8cb123f
Author:    mcimadamore
Date:      2019-09-11 22:09 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/ba9eb8cb123f

Automatic merge with default

! make/RunTests.gmk
! make/autoconf/basics.m4
! make/common/Modules.gmk
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zArguments_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.hpp
- src/hotspot/share/gc/g1/g1HeapSizingPolicy_ext.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.hpp
- src/hotspot/share/gc/parallel/gcTaskThread.cpp
- src/hotspot/share/gc/parallel/gcTaskThread.hpp
- src/hotspot/share/gc/parallel/pcTasks.cpp
- src/hotspot/share/gc/parallel/pcTasks.hpp
- src/hotspot/share/gc/parallel/psTasks.cpp
- src/hotspot/share/gc/parallel/psTasks.hpp
! src/hotspot/share/logging/logTag.hpp
- src/hotspot/share/logging/logTag_ext.hpp
- src/hotspot/share/oops/markOop.cpp
- src/hotspot/share/oops/markOop.hpp
- src/hotspot/share/oops/markOop.inline.hpp
! src/hotspot/share/prims/nativeLookup.cpp
- src/hotspot/share/runtime/arguments_ext.cpp
- src/hotspot/share/runtime/globals_ext.hpp
! src/hotspot/share/runtime/init.cpp
- src/hotspot/share/runtime/os_ext.hpp
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/module-info.java
! src/java.base/share/native/libjava/jni_util.h
- src/jdk.hotspot.agent/share/classes/META-INF/services/com.sun.jdi.connect.Connector
- test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeArray.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeStringArray.java
- test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java
- test/jdk/java/lang/invoke/findclass.security.policy
- test/jdk/java/net/Socket/reset/Test.java
- test/jdk/java/nio/charset/coders/SJISMappingPropTest.java
- test/jdk/java/nio/charset/coders/SJISPropTest.java
- test/jdk/java/nio/charset/coders/ref.windows-31j
- test/jdk/java/security/testlibrary/CertUtils.java
- test/jdk/javax/xml/jaxp/testng/validation/jdk8037819/BasicTest1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java


From maurizio.cimadamore at oracle.com  Wed Sep 11 22:10:18 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 11 Sep 2019 22:10:18 +0000
Subject: hg: panama/dev: Automatic merge with foreign
Message-ID: <201909112210.x8BMAJGj023584@aojmv0008.oracle.com>

Changeset: d5ba258b5854
Author:    mcimadamore
Date:      2019-09-11 22:10 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/d5ba258b5854

Automatic merge with foreign

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/x86/frame_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zArguments_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/classfile/javaClasses.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/code/codeBlob.cpp
- src/hotspot/share/gc/g1/g1HeapSizingPolicy_ext.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.hpp
- src/hotspot/share/gc/parallel/gcTaskThread.cpp
- src/hotspot/share/gc/parallel/gcTaskThread.hpp
- src/hotspot/share/gc/parallel/pcTasks.cpp
- src/hotspot/share/gc/parallel/pcTasks.hpp
- src/hotspot/share/gc/parallel/psTasks.cpp
- src/hotspot/share/gc/parallel/psTasks.hpp
! src/hotspot/share/logging/logTag.hpp
- src/hotspot/share/logging/logTag_ext.hpp
- src/hotspot/share/oops/markOop.cpp
- src/hotspot/share/oops/markOop.hpp
- src/hotspot/share/oops/markOop.inline.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/opto/runtime.hpp
! src/hotspot/share/prims/nativeLookup.cpp
! src/hotspot/share/prims/unsafe.cpp
- src/hotspot/share/runtime/arguments_ext.cpp
- src/hotspot/share/runtime/globals_ext.hpp
- src/hotspot/share/runtime/os_ext.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/runtime/stubRoutines.cpp
! src/hotspot/share/runtime/stubRoutines.hpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
- src/jdk.hotspot.agent/share/classes/META-INF/services/com.sun.jdi.connect.Connector
- test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeArray.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeStringArray.java
- test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java
- test/jdk/java/lang/invoke/findclass.security.policy
- test/jdk/java/net/Socket/reset/Test.java
- test/jdk/java/nio/charset/coders/SJISMappingPropTest.java
- test/jdk/java/nio/charset/coders/SJISPropTest.java
- test/jdk/java/nio/charset/coders/ref.windows-31j
- test/jdk/java/security/testlibrary/CertUtils.java
- test/jdk/javax/xml/jaxp/testng/validation/jdk8037819/BasicTest1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java


From maurizio.cimadamore at oracle.com  Thu Sep 12 13:09:53 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 12 Sep 2019 13:09:53 +0000
Subject: hg: panama/dev: manual merge with default
Message-ID: <201909121309.x8CD9rMi002750@aojmv0008.oracle.com>

Changeset: c3d683123981
Author:    mcimadamore
Date:      2019-09-12 14:09 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/c3d683123981

manual merge with default

! make/common/Modules.gmk
- src/hotspot/os_cpu/linux_aarch64/gc/z/zArguments_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.hpp
- src/hotspot/share/gc/g1/g1HeapSizingPolicy_ext.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.hpp
- src/hotspot/share/gc/parallel/gcTaskThread.cpp
- src/hotspot/share/gc/parallel/gcTaskThread.hpp
- src/hotspot/share/gc/parallel/pcTasks.cpp
- src/hotspot/share/gc/parallel/pcTasks.hpp
- src/hotspot/share/gc/parallel/psTasks.cpp
- src/hotspot/share/gc/parallel/psTasks.hpp
- src/hotspot/share/logging/logTag_ext.hpp
- src/hotspot/share/oops/markOop.cpp
- src/hotspot/share/oops/markOop.hpp
- src/hotspot/share/oops/markOop.inline.hpp
! src/hotspot/share/opto/library_call.cpp
- src/hotspot/share/runtime/arguments_ext.cpp
- src/hotspot/share/runtime/globals_ext.hpp
- src/hotspot/share/runtime/os_ext.hpp
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! src/java.base/share/classes/module-info.java
! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java
- src/jdk.hotspot.agent/share/classes/META-INF/services/com.sun.jdi.connect.Connector
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemoryScope.java
- test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeArray.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeStringArray.java
- test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java
- test/jdk/java/lang/invoke/findclass.security.policy
- test/jdk/java/net/Socket/reset/Test.java
- test/jdk/java/nio/charset/coders/SJISMappingPropTest.java
- test/jdk/java/nio/charset/coders/SJISPropTest.java
- test/jdk/java/nio/charset/coders/ref.windows-31j
- test/jdk/java/security/testlibrary/CertUtils.java
- test/jdk/javax/xml/jaxp/testng/validation/jdk8037819/BasicTest1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java


From maurizio.cimadamore at oracle.com  Thu Sep 12 13:14:58 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 12 Sep 2019 13:14:58 +0000
Subject: hg: panama/dev: Automatic merge with foreign-memaccess
Message-ID: <201909121314.x8CDEx8r005685@aojmv0008.oracle.com>

Changeset: 0adfd3ade3da
Author:    mcimadamore
Date:      2019-09-12 13:14 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/0adfd3ade3da

Automatic merge with foreign-memaccess

! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zArguments_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.hpp
- src/hotspot/share/gc/g1/g1HeapSizingPolicy_ext.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.hpp
- src/hotspot/share/gc/parallel/gcTaskThread.cpp
- src/hotspot/share/gc/parallel/gcTaskThread.hpp
- src/hotspot/share/gc/parallel/pcTasks.cpp
- src/hotspot/share/gc/parallel/pcTasks.hpp
- src/hotspot/share/gc/parallel/psTasks.cpp
- src/hotspot/share/gc/parallel/psTasks.hpp
! src/hotspot/share/logging/logTag.hpp
- src/hotspot/share/logging/logTag_ext.hpp
- src/hotspot/share/oops/markOop.cpp
- src/hotspot/share/oops/markOop.hpp
- src/hotspot/share/oops/markOop.inline.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/prims/nativeLookup.cpp
- src/hotspot/share/runtime/arguments_ext.cpp
- src/hotspot/share/runtime/globals_ext.hpp
! src/hotspot/share/runtime/init.cpp
- src/hotspot/share/runtime/os_ext.hpp
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/module-info.java
! src/java.base/share/native/libjava/jni_util.h
- src/jdk.hotspot.agent/share/classes/META-INF/services/com.sun.jdi.connect.Connector
- test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeArray.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeStringArray.java
- test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java
- test/jdk/java/lang/invoke/findclass.security.policy
- test/jdk/java/net/Socket/reset/Test.java
- test/jdk/java/nio/charset/coders/SJISMappingPropTest.java
- test/jdk/java/nio/charset/coders/SJISPropTest.java
- test/jdk/java/nio/charset/coders/ref.windows-31j
- test/jdk/java/security/testlibrary/CertUtils.java
- test/jdk/javax/xml/jaxp/testng/validation/jdk8037819/BasicTest1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java


From maurizio.cimadamore at oracle.com  Thu Sep 12 14:53:57 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 12 Sep 2019 14:53:57 +0000
Subject: hg: panama/dev: manual merge with linkToNative
Message-ID: <201909121453.x8CErvYp007998@aojmv0008.oracle.com>

Changeset: a028f4507a8f
Author:    mcimadamore
Date:      2019-09-12 15:53 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/a028f4507a8f

manual merge with linkToNative

! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/share/logging/logTag.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java


From youngty1997 at gmail.com  Sat Sep 14 05:36:28 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sat, 14 Sep 2019 00:36:28 -0500
Subject: Project Panama & dynamic library loading
In-Reply-To: <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
Message-ID: <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>


On 9/7/19 3:11 PM, Maurizio Cimadamore wrote:
>
> On 07/09/2019 20:15, Ty Young wrote:
>>
>> On 9/7/19 12:14 PM, Maurizio Cimadamore wrote:
>>>
>>> On 07/09/2019 05:17, Ty Young wrote:
>>>>
>>>> On 9/6/19 11:04 PM, Henry Jen wrote:
>>>>>
>>>>>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>>>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore 
>>>>>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>>>>>> Hi Ty, you are not forced to save the library path in the 
>>>>>>>>>> generated extracted jar with the --record-library-path 
>>>>>>>>>> option. If you can also omit that option, and then set 
>>>>>>>>>> java.library.path (or LD_LIBRARY_PATH) accordingly when it's 
>>>>>>>>>> time to run your application.
>>>>>>>> Can java.library.path be modified in code or does it have to be 
>>>>>>>> a launch option to work? I've always assumed it was a launch 
>>>>>>>> option only and haven't thought much of it.
>>>>>>>>
>>>>>>> It?s a launch option, and thus can adapt to your deployment 
>>>>>>> environment.
>>>>>>
>>>>>> There is no specific "deployment environment". If you were to 
>>>>>> create bindings in Arch Linux you'd need to specify the pathing 
>>>>>> for every other Linux distro and even Windows, resulting in not 
>>>>>> working on more obscure Linux distros and two different builds 
>>>>>> between Windows and Linux. If you could just dynamically add the 
>>>>>> paths that'd make this so much easier?
>>>>>>
>>>>> In this case, you are looking for a sane system default, which as 
>>>>> Mauricio mentioned, we need to look for better ways. OpenJDK by 
>>>>> default is not providing proper value across various Linux 
>>>>> distros. But java.library.path provide a way to accommodate that. 
>>>>> Also, it?s possible to
>>>>>
>>>>> Usually, a Linux distro will have a customized OpenJDK package has 
>>>>> customized default.
>>>>>
>>>>>>>> It would really be nice if the whole thing was dynamic with 
>>>>>>>> zero hardcoded values, even if startup time was sacrificed due 
>>>>>>>> to library searching. With how fragmented the Linux ecosystem 
>>>>>>>> specifically is, there is never any guarantee that any 
>>>>>>>> hardcoded values(s) will work for all Linux distros.
>>>>>>>>
>>>>>>> Dynamic loading is supported since beginning, typical code 
>>>>>>> snippet is like following.
>>>>>>>
>>>>>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), 
>>>>>>> "tensorflow");
>>>>>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>>>>>
>>>>>>> As long as you define java.library.path to include correct 
>>>>>>> search path for the native library, it should work just fine.
>>>>>>
>>>>>> The search path being static is the problem here. Without a 
>>>>>> dynamic way to add libraries easily things will blowup real badly.
>>>>>>
>>>>>>
>>>>> With jextract, combine -L option with -l and ?record-library-path, 
>>>>> the provided search paths is saved to be used for runtime. I know 
>>>>> it?s not the same as an API, but provide the behavior you described?
>>>>
>>>>
>>>> Path(s) or path? None of the examples that I see show multiple 
>>>> library paths being specified. If it is possible then sure, I 
>>>> guess. It's still hardcoded and could break but at least I'll have 
>>>> the three major distros covered and don't have to copy libraries 
>>>> around...
>>>>
>>>>
>>>> That said, can a Windows path be specified alongside the Linux paths?
>>>
>>> When you use --record-library-path whatever path you specify with -L 
>>> will end up saved in the generated annotations. You can put 
>>> non-existent paths in there - it's no harm, they will be just 
>>> ignored at runtime on th eplatforms where they don't make sense.
>>
>>
>> Alright, but how do you specify multiple paths? Something like this:
>>
>>
>> -L /usr/lib:/usr/lib64
>
> You repeat -L as many times as you want e.g.
>
> -L /usr/lib -L /usr/lib64
>
> Maurizio


Finally got around to testing this. Sorry for the late reply.


This doesn't seem to actually work? It seems to find the first library 
correctly but then fails to find the second one even though you can see 
it being there. Does -L only apply to the next specified library? For 
example:

-L /usr/lib -lfoo -L /usr/lib64 -lbar


?


>
>>
>>
>> Or does it have its own unique regex?
>>
>>
>>>
>>> Maurizio
>>>
>>>>
>>>>
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>

From maurizio.cimadamore at oracle.com  Sun Sep 15 10:50:22 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sun, 15 Sep 2019 11:50:22 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
Message-ID: <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>


On 14/09/2019 06:36, Ty Young wrote:
>
> On 9/7/19 3:11 PM, Maurizio Cimadamore wrote:
>>
>> On 07/09/2019 20:15, Ty Young wrote:
>>>
>>> On 9/7/19 12:14 PM, Maurizio Cimadamore wrote:
>>>>
>>>> On 07/09/2019 05:17, Ty Young wrote:
>>>>>
>>>>> On 9/6/19 11:04 PM, Henry Jen wrote:
>>>>>>
>>>>>>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>>>>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>>>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore 
>>>>>>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>>>>>>> Hi Ty, you are not forced to save the library path in the 
>>>>>>>>>>> generated extracted jar with the --record-library-path 
>>>>>>>>>>> option. If you can also omit that option, and then set 
>>>>>>>>>>> java.library.path (or LD_LIBRARY_PATH) accordingly when it's 
>>>>>>>>>>> time to run your application.
>>>>>>>>> Can java.library.path be modified in code or does it have to 
>>>>>>>>> be a launch option to work? I've always assumed it was a 
>>>>>>>>> launch option only and haven't thought much of it.
>>>>>>>>>
>>>>>>>> It?s a launch option, and thus can adapt to your deployment 
>>>>>>>> environment.
>>>>>>>
>>>>>>> There is no specific "deployment environment". If you were to 
>>>>>>> create bindings in Arch Linux you'd need to specify the pathing 
>>>>>>> for every other Linux distro and even Windows, resulting in not 
>>>>>>> working on more obscure Linux distros and two different builds 
>>>>>>> between Windows and Linux. If you could just dynamically add the 
>>>>>>> paths that'd make this so much easier?
>>>>>>>
>>>>>> In this case, you are looking for a sane system default, which as 
>>>>>> Mauricio mentioned, we need to look for better ways. OpenJDK by 
>>>>>> default is not providing proper value across various Linux 
>>>>>> distros. But java.library.path provide a way to accommodate that. 
>>>>>> Also, it?s possible to
>>>>>>
>>>>>> Usually, a Linux distro will have a customized OpenJDK package 
>>>>>> has customized default.
>>>>>>
>>>>>>>>> It would really be nice if the whole thing was dynamic with 
>>>>>>>>> zero hardcoded values, even if startup time was sacrificed due 
>>>>>>>>> to library searching. With how fragmented the Linux ecosystem 
>>>>>>>>> specifically is, there is never any guarantee that any 
>>>>>>>>> hardcoded values(s) will work for all Linux distros.
>>>>>>>>>
>>>>>>>> Dynamic loading is supported since beginning, typical code 
>>>>>>>> snippet is like following.
>>>>>>>>
>>>>>>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), 
>>>>>>>> "tensorflow");
>>>>>>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>>>>>>
>>>>>>>> As long as you define java.library.path to include correct 
>>>>>>>> search path for the native library, it should work just fine.
>>>>>>>
>>>>>>> The search path being static is the problem here. Without a 
>>>>>>> dynamic way to add libraries easily things will blowup real badly.
>>>>>>>
>>>>>>>
>>>>>> With jextract, combine -L option with -l and 
>>>>>> ?record-library-path, the provided search paths is saved to be 
>>>>>> used for runtime. I know it?s not the same as an API, but provide 
>>>>>> the behavior you described?
>>>>>
>>>>>
>>>>> Path(s) or path? None of the examples that I see show multiple 
>>>>> library paths being specified. If it is possible then sure, I 
>>>>> guess. It's still hardcoded and could break but at least I'll have 
>>>>> the three major distros covered and don't have to copy libraries 
>>>>> around...
>>>>>
>>>>>
>>>>> That said, can a Windows path be specified alongside the Linux paths?
>>>>
>>>> When you use --record-library-path whatever path you specify with 
>>>> -L will end up saved in the generated annotations. You can put 
>>>> non-existent paths in there - it's no harm, they will be just 
>>>> ignored at runtime on th eplatforms where they don't make sense.
>>>
>>>
>>> Alright, but how do you specify multiple paths? Something like this:
>>>
>>>
>>> -L /usr/lib:/usr/lib64
>>
>> You repeat -L as many times as you want e.g.
>>
>> -L /usr/lib -L /usr/lib64
>>
>> Maurizio
>
>
> Finally got around to testing this. Sorry for the late reply.
>
>
> This doesn't seem to actually work? It seems to find the first library 
> correctly but then fails to find the second one even though you can 
> see it being there. Does -L only apply to the next specified library? 
> For example:
>
> -L /usr/lib -lfoo -L /usr/lib64 -lbar

No, -L should just be applied globally. To be 100% sure, I tried to 
extract OpenGL with the latest binaries (instructions in [1]) and I also 
threw in a fake path:

jextract -l GL -l GLU -l glut --record-library-path -L/foo/bar -L 
/usr/lib/x86_64-linux-gnu/ -t opengl -o lib/opengl.jar 
/usr/include/GL/glut.h

(note the -L foo/bar)

The extra fake library path is reflected in the generated annotation:

@NativeHeader(
 ??? path = "/usr/include/GL/gl.h",
 ??? libraries = {"GL", "GLU", "glut"},
 ??? libraryPaths = {"/foo/bar", "/usr/lib/x86_64-linux-gnu/"}
)

I think that in order to diagnose further we need to see what commands 
are you trying to use to extract, and what is the code that you are 
trying to run, so that we can try to reproduce it. Adding extra spurious 
paths should work.

Maurizio

>
>
> ?
>
>
>>
>>>
>>>
>>> Or does it have its own unique regex?
>>>
>>>
>>>>
>>>> Maurizio
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Henry
>>>>>>

From youngty1997 at gmail.com  Sun Sep 15 11:27:07 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 15 Sep 2019 06:27:07 -0500
Subject: Project Panama & dynamic library loading
In-Reply-To: <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
Message-ID: <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>


On 9/15/19 5:50 AM, Maurizio Cimadamore wrote:
>
> On 14/09/2019 06:36, Ty Young wrote:
>>
>> On 9/7/19 3:11 PM, Maurizio Cimadamore wrote:
>>>
>>> On 07/09/2019 20:15, Ty Young wrote:
>>>>
>>>> On 9/7/19 12:14 PM, Maurizio Cimadamore wrote:
>>>>>
>>>>> On 07/09/2019 05:17, Ty Young wrote:
>>>>>>
>>>>>> On 9/6/19 11:04 PM, Henry Jen wrote:
>>>>>>>
>>>>>>>> On Sep 6, 2019, at 6:47 PM, Ty Young <youngty1997 at gmail.com> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/6/19 8:12 PM, Henry Jen wrote:
>>>>>>>>>> On Sep 6, 2019, at 4:58 PM, Ty Young <youngty1997 at gmail.com> 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/6/19 6:36 PM, Ty Young wrote:
>>>>>>>>>>> On Fri, Sep 6, 2019 at 6:34 PM, Maurizio Cimadamore 
>>>>>>>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>>>>>>>> Hi Ty, you are not forced to save the library path in the 
>>>>>>>>>>>> generated extracted jar with the --record-library-path 
>>>>>>>>>>>> option. If you can also omit that option, and then set 
>>>>>>>>>>>> java.library.path (or LD_LIBRARY_PATH) accordingly when 
>>>>>>>>>>>> it's time to run your application.
>>>>>>>>>> Can java.library.path be modified in code or does it have to 
>>>>>>>>>> be a launch option to work? I've always assumed it was a 
>>>>>>>>>> launch option only and haven't thought much of it.
>>>>>>>>>>
>>>>>>>>> It?s a launch option, and thus can adapt to your deployment 
>>>>>>>>> environment.
>>>>>>>>
>>>>>>>> There is no specific "deployment environment". If you were to 
>>>>>>>> create bindings in Arch Linux you'd need to specify the pathing 
>>>>>>>> for every other Linux distro and even Windows, resulting in not 
>>>>>>>> working on more obscure Linux distros and two different builds 
>>>>>>>> between Windows and Linux. If you could just dynamically add 
>>>>>>>> the paths that'd make this so much easier?
>>>>>>>>
>>>>>>> In this case, you are looking for a sane system default, which 
>>>>>>> as Mauricio mentioned, we need to look for better ways. OpenJDK 
>>>>>>> by default is not providing proper value across various Linux 
>>>>>>> distros. But java.library.path provide a way to accommodate 
>>>>>>> that. Also, it?s possible to
>>>>>>>
>>>>>>> Usually, a Linux distro will have a customized OpenJDK package 
>>>>>>> has customized default.
>>>>>>>
>>>>>>>>>> It would really be nice if the whole thing was dynamic with 
>>>>>>>>>> zero hardcoded values, even if startup time was sacrificed 
>>>>>>>>>> due to library searching. With how fragmented the Linux 
>>>>>>>>>> ecosystem specifically is, there is never any guarantee that 
>>>>>>>>>> any hardcoded values(s) will work for all Linux distros.
>>>>>>>>>>
>>>>>>>>> Dynamic loading is supported since beginning, typical code 
>>>>>>>>> snippet is like following.
>>>>>>>>>
>>>>>>>>> Library lib = Libraries.loadLibrary(MethodHandles.lookup(), 
>>>>>>>>> "tensorflow");
>>>>>>>>> libTF = Libraries.bind(c_api_h.class, lib);
>>>>>>>>>
>>>>>>>>> As long as you define java.library.path to include correct 
>>>>>>>>> search path for the native library, it should work just fine.
>>>>>>>>
>>>>>>>> The search path being static is the problem here. Without a 
>>>>>>>> dynamic way to add libraries easily things will blowup real badly.
>>>>>>>>
>>>>>>>>
>>>>>>> With jextract, combine -L option with -l and 
>>>>>>> ?record-library-path, the provided search paths is saved to be 
>>>>>>> used for runtime. I know it?s not the same as an API, but 
>>>>>>> provide the behavior you described?
>>>>>>
>>>>>>
>>>>>> Path(s) or path? None of the examples that I see show multiple 
>>>>>> library paths being specified. If it is possible then sure, I 
>>>>>> guess. It's still hardcoded and could break but at least I'll 
>>>>>> have the three major distros covered and don't have to copy 
>>>>>> libraries around...
>>>>>>
>>>>>>
>>>>>> That said, can a Windows path be specified alongside the Linux 
>>>>>> paths?
>>>>>
>>>>> When you use --record-library-path whatever path you specify with 
>>>>> -L will end up saved in the generated annotations. You can put 
>>>>> non-existent paths in there - it's no harm, they will be just 
>>>>> ignored at runtime on th eplatforms where they don't make sense.
>>>>
>>>>
>>>> Alright, but how do you specify multiple paths? Something like this:
>>>>
>>>>
>>>> -L /usr/lib:/usr/lib64
>>>
>>> You repeat -L as many times as you want e.g.
>>>
>>> -L /usr/lib -L /usr/lib64
>>>
>>> Maurizio
>>
>>
>> Finally got around to testing this. Sorry for the late reply.
>>
>>
>> This doesn't seem to actually work? It seems to find the first 
>> library correctly but then fails to find the second one even though 
>> you can see it being there. Does -L only apply to the next specified 
>> library? For example:
>>
>> -L /usr/lib -lfoo -L /usr/lib64 -lbar
>
> No, -L should just be applied globally. To be 100% sure, I tried to 
> extract OpenGL with the latest binaries (instructions in [1]) and I 
> also threw in a fake path:
>
> jextract -l GL -l GLU -l glut --record-library-path -L/foo/bar -L 
> /usr/lib/x86_64-linux-gnu/ -t opengl -o lib/opengl.jar 
> /usr/include/GL/glut.h
>
> (note the -L foo/bar)
>
> The extra fake library path is reflected in the generated annotation:
>
> @NativeHeader(
> ??? path = "/usr/include/GL/gl.h",
> ??? libraries = {"GL", "GLU", "glut"},
> ??? libraryPaths = {"/foo/bar", "/usr/lib/x86_64-linux-gnu/"}
> )
>
> I think that in order to diagnose further we need to see what commands 
> are you trying to use to extract, and what is the code that you are 
> trying to run, so that we can try to reproduce it. Adding extra 
> spurious paths should work.


jextract: jextract -t org.nvidia.envious -L /usr/lib -L /usr/lib64 -L 
/usr/lib/x86_64-linux-gnu -lXNVCtrl -lnvidia-ml --record-library-path 
/opt/cuda/targets/x86_64-linux/include/nvml.h /usr/include/X11/Xmd.h 
/usr/include/X11/Xlibint.h /usr/include/NVCtrl/nv_control.h 
/usr/include/NVCtrl/NVCtrlLib.h -o org.nvidia.envious.jar


Tried removing record library path just for the giggles. No difference.


Project: 
https://github.com/BlueGoliath/GoliathEnviousNative/releases/tag/V1-Alpha-5


Requires Linux and Nvidia GPU w/ binary drivers. Loading libraries is 
done via NVML.init() and NvXCtrl.init(). If NVML's library was missing 
then it would fail, but it doesn't yet NvXCtrl's does despite being in 
the same directory on Ubuntu(/usr/lib/x86_64-linux-gnu). It works fine 
on Arch Linux(/usr/lib, part of default path).


The only difference between the two distros is a ".0" soname at the end 
on Ubuntu vs. none on Arch Linux*. Could that be the reason?


*On Arch there is actually 3 libraries, one without a soname, one with 
".0", and the last one with ".0.0.0". Ubuntu only has the last two.


>
> Maurizio
>
>>
>>
>> ?
>>
>>
>>>
>>>>
>>>>
>>>> Or does it have its own unique regex?
>>>>
>>>>
>>>>>
>>>>> Maurizio
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Henry
>>>>>>>

From maurizio.cimadamore at oracle.com  Sun Sep 15 11:59:42 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sun, 15 Sep 2019 12:59:42 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
Message-ID: <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>


On 15/09/2019 12:27, Ty Young wrote:
> The only difference between the two distros is a ".0" soname at the 
> end on Ubuntu vs. none on Arch Linux*. Could that be the reason? 

I had issues with soname in the past. Would it be possible, as a means 
of an experiment to try and copy the library stripped of the .0 suffix?

Maurizio


From youngty1997 at gmail.com  Sun Sep 15 12:13:22 2019
From: youngty1997 at gmail.com (Ty Young)
Date: Sun, 15 Sep 2019 07:13:22 -0500
Subject: Project Panama & dynamic library loading
In-Reply-To: <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
Message-ID: <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>


On 9/15/19 6:59 AM, Maurizio Cimadamore wrote:
>
> On 15/09/2019 12:27, Ty Young wrote:
>> The only difference between the two distros is a ".0" soname at the 
>> end on Ubuntu vs. none on Arch Linux*. Could that be the reason? 
>
> I had issues with soname in the past. Would it be possible, as a means 
> of an experiment to try and copy the library stripped of the .0 suffix?
>

Yep. Tried it on a USB live boot of Pop!_OS 19.10 and it stops 
complaining about NvXCtrl.


...Then it starts complaining about nvidia-ml not existing but the 
library names are 100% the same with paths only being different. There 
is libnvidia-ml.so, libnvidia-ml.so.0, and 
libnvidia-ml.so.<DRIVER_VERSION> on both Ubuntu and Arch.


> Maurizio
>

From samuel.audet at gmail.com  Sun Sep 15 13:00:50 2019
From: samuel.audet at gmail.com (Samuel Audet)
Date: Sun, 15 Sep 2019 22:00:50 +0900
Subject: Project Panama & dynamic library loading
In-Reply-To: <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
Message-ID: <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>

The soname that the OS cares about is in the file itself, not the 
filename. Check with `readelf -d`, or `objdump -p`, etc to make sure 
you're actually loading what you think you're loading. The soname might 
have a version and that's what the OS will consider as the library name. 
The runtime will search the path for files that have that as filename, 
but once loaded, whether it matches the filename or not doesn't matter. 
If jextract cares about the filename on Linux, you'll run into problems 
when there's a mismatch between the two. Windows is different in that 
regard...

On 9/15/19 9:13 PM, Ty Young wrote:
> 
> On 9/15/19 6:59 AM, Maurizio Cimadamore wrote:
>>
>> On 15/09/2019 12:27, Ty Young wrote:
>>> The only difference between the two distros is a ".0" soname at the 
>>> end on Ubuntu vs. none on Arch Linux*. Could that be the reason? 
>>
>> I had issues with soname in the past. Would it be possible, as a means 
>> of an experiment to try and copy the library stripped of the .0 suffix?
>>
> 
> Yep. Tried it on a USB live boot of Pop!_OS 19.10 and it stops 
> complaining about NvXCtrl.
> 
> 
> ...Then it starts complaining about nvidia-ml not existing but the 
> library names are 100% the same with paths only being different. There 
> is libnvidia-ml.so, libnvidia-ml.so.0, and 
> libnvidia-ml.so.<DRIVER_VERSION> on both Ubuntu and Arch.
> 
> 
>> Maurizio
>>

From maurizio.cimadamore at oracle.com  Mon Sep 16 09:53:09 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 16 Sep 2019 10:53:09 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
Message-ID: <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>

I agree with this analysis.

One addition - it's not really that jextract cares about sonames - it's 
just that if you call

System::loadLibrary("foo")

and you are on Linux, the VM will try to load:

libfoo.so

on all the paths that are part of the native library path.

If you want something different, then there's the more general 
System::load which takes a full _patth_ (not a libname), which can of 
course contain sonames and all.

Jexract/binder is relying on libnames and System::loadLibrary - so it's 
expecting that the _right_ library is available at PATH/libfoo.so (I've 
seen cases where this path, despite pointing to a shared object, it 
pointed to one that did NOT contain any symbols - on Linux x64/Ubuntu).

At the moment jextract doesn't have a way to specify a full library path 
- but that could be added. In the longer term, I think that, as part of 
the 'cleanup' I was mentioning few emails ago, it would also be nice, 
if, in addition of honoring the right system native paths (e.g. ld paths 
on linux), the VM would also be smarter about sonames when deriving a 
library path from a library name.

Maurizio

On 15/09/2019 14:00, Samuel Audet wrote:
> The soname that the OS cares about is in the file itself, not the 
> filename. Check with `readelf -d`, or `objdump -p`, etc to make sure 
> you're actually loading what you think you're loading. The soname 
> might have a version and that's what the OS will consider as the 
> library name. The runtime will search the path for files that have 
> that as filename, but once loaded, whether it matches the filename or 
> not doesn't matter. If jextract cares about the filename on Linux, 
> you'll run into problems when there's a mismatch between the two. 
> Windows is different in that regard...
>
> On 9/15/19 9:13 PM, Ty Young wrote:
>>
>> On 9/15/19 6:59 AM, Maurizio Cimadamore wrote:
>>>
>>> On 15/09/2019 12:27, Ty Young wrote:
>>>> The only difference between the two distros is a ".0" soname at the 
>>>> end on Ubuntu vs. none on Arch Linux*. Could that be the reason? 
>>>
>>> I had issues with soname in the past. Would it be possible, as a 
>>> means of an experiment to try and copy the library stripped of the 
>>> .0 suffix?
>>>
>>
>> Yep. Tried it on a USB live boot of Pop!_OS 19.10 and it stops 
>> complaining about NvXCtrl.
>>
>>
>> ...Then it starts complaining about nvidia-ml not existing but the 
>> library names are 100% the same with paths only being different. 
>> There is libnvidia-ml.so, libnvidia-ml.so.0, and 
>> libnvidia-ml.so.<DRIVER_VERSION> on both Ubuntu and Arch.
>>
>>
>>> Maurizio
>>>

From maurizio.cimadamore at oracle.com  Mon Sep 16 10:14:12 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 16 Sep 2019 11:14:12 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
Message-ID: <6288ccd2-268f-0848-8469-4a49301e82f6@oracle.com>

Another thing to check is library dependencies, with 'ldd <filename'.

I've seen cases of "weirdly" packaged libraries which failed to specify 
a dependency on other required libraries. Opening such libraries would 
lead to missing symbols, even when using a low-level 'dlopen', not much 
that can be done in that case.

I wonder if in the Arch case, libnvidia-ml.so depends on 
libnvidia-ml.so.<DRIVER_VERSION>, whereas in Ubuntu it does not.

Also, there seem to be some issues with nvidia libraries and their 
integration with the host system:

https://github.com/NVIDIA/nvidia-docker/issues/854

And even weirder interaction between Nvidia drivers and bumblebee 
causing wrong library to be loaded

https://askubuntu.com/questions/833862/nvidia-smi-couldnt-find-libnvidia-ml-so-library

In other words, _something_ seems not to be set up correctly in your 
Ubuntu install, and the jextract/VM issues with library loading are 
likely just symptoms, not the cause.

Maurizio

On 16/09/2019 10:53, Maurizio Cimadamore wrote:
> I agree with this analysis.
>
> One addition - it's not really that jextract cares about sonames - 
> it's just that if you call
>
> System::loadLibrary("foo")
>
> and you are on Linux, the VM will try to load:
>
> libfoo.so
>
> on all the paths that are part of the native library path.
>
> If you want something different, then there's the more general 
> System::load which takes a full _patth_ (not a libname), which can of 
> course contain sonames and all.
>
> Jexract/binder is relying on libnames and System::loadLibrary - so 
> it's expecting that the _right_ library is available at PATH/libfoo.so 
> (I've seen cases where this path, despite pointing to a shared object, 
> it pointed to one that did NOT contain any symbols - on Linux 
> x64/Ubuntu).
>
> At the moment jextract doesn't have a way to specify a full library 
> path - but that could be added. In the longer term, I think that, as 
> part of the 'cleanup' I was mentioning few emails ago, it would also 
> be nice, if, in addition of honoring the right system native paths 
> (e.g. ld paths on linux), the VM would also be smarter about sonames 
> when deriving a library path from a library name.
>
> Maurizio
>
> On 15/09/2019 14:00, Samuel Audet wrote:
>> The soname that the OS cares about is in the file itself, not the 
>> filename. Check with `readelf -d`, or `objdump -p`, etc to make sure 
>> you're actually loading what you think you're loading. The soname 
>> might have a version and that's what the OS will consider as the 
>> library name. The runtime will search the path for files that have 
>> that as filename, but once loaded, whether it matches the filename or 
>> not doesn't matter. If jextract cares about the filename on Linux, 
>> you'll run into problems when there's a mismatch between the two. 
>> Windows is different in that regard...
>>
>> On 9/15/19 9:13 PM, Ty Young wrote:
>>>
>>> On 9/15/19 6:59 AM, Maurizio Cimadamore wrote:
>>>>
>>>> On 15/09/2019 12:27, Ty Young wrote:
>>>>> The only difference between the two distros is a ".0" soname at 
>>>>> the end on Ubuntu vs. none on Arch Linux*. Could that be the reason? 
>>>>
>>>> I had issues with soname in the past. Would it be possible, as a 
>>>> means of an experiment to try and copy the library stripped of the 
>>>> .0 suffix?
>>>>
>>>
>>> Yep. Tried it on a USB live boot of Pop!_OS 19.10 and it stops 
>>> complaining about NvXCtrl.
>>>
>>>
>>> ...Then it starts complaining about nvidia-ml not existing but the 
>>> library names are 100% the same with paths only being different. 
>>> There is libnvidia-ml.so, libnvidia-ml.so.0, and 
>>> libnvidia-ml.so.<DRIVER_VERSION> on both Ubuntu and Arch.
>>>
>>>
>>>> Maurizio
>>>>

From org.openjdk at io7m.com  Mon Sep 16 10:51:26 2019
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Mon, 16 Sep 2019 11:51:26 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
Message-ID: <20190916115126.73f85a8a@almond.int.arc7.info>

On 2019-09-16T10:53:09 +0100
Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

> I agree with this analysis.
> 
> One addition - it's not really that jextract cares about sonames - it's 
> just that if you call
> 
> System::loadLibrary("foo")
> 
> and you are on Linux, the VM will try to load:
> 
> libfoo.so
> 
> on all the paths that are part of the native library path.
> 
> If you want something different, then there's the more general 
> System::load which takes a full _patth_ (not a libname), which can of 
> course contain sonames and all.

Just a quick question: Is anyone here familiar with how OSGi handles
this? In my opinion, this stuff already seems to be a solved problem
there.

Bundles (jar files in OSGi speak) contain native libraries directly,
and contain metadata in the MANIFEST.MF file that explain which native
libraries match each arch/os combination. For example:

Bundle-NativeCode:\
  lwjgl_opengl32.dll;osname=Win32;processor=x86,\
  lwjgl_opengl.dll;osname=Win32;processor=x86-64,\
  liblwjgl_opengl.so;osname=Linux;processor=x86-64,\
  liblwjgl_opengl.dylib;osname=MacOSX;processor=x86-64

That's an extract from the OSGi bundles from the LWJGL project. The
Bundle-NativeCode declaration specifies which native libraries are
included, and which should be loaded in a given situation. You can see
that it states that the runtime should load lwjgl_opengl32.dll if the
current platform is Windows on x86. It should load liblwjgl_opengl.so
if the current platform is Linux on x86-64, etc. It's also possible to
state that a particular platform/arch doesn't require a native library.

The runtime transparently extracts and arranges paths as necessary so
that calls to System::loadLibrary("lwjgl_opengl") work correctly.

I believe that JBoss modules work similarly.

-- 
Mark Raynsford | http://www.io7m.com


From maurizio.cimadamore at oracle.com  Mon Sep 16 11:55:20 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 16 Sep 2019 12:55:20 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <20190916115126.73f85a8a@almond.int.arc7.info>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
 <20190916115126.73f85a8a@almond.int.arc7.info>
Message-ID: <16c7f0f2-3fbe-ee1c-da5e-b061ba2001ba@oracle.com>

Something along these lines might well be required yes - although AFAIK 
not even OSGi can protect you from sonames and missing dependencies (as, 
under the hood, it will still delegate to System::loadLibrary). Also, 
while not required, I think OSGi typical use case will be to co-package 
the required native libraries in a given bundle, which I don't think 
it's exactly the case we're discussing here? E.g. I took a look at 
lwjgl-opengl and that seems to load libGL that comes installed in the 
system - outside the bundle, with a call to dlopen (on Linux). So, if 
the system library is not installed correctly (e.g. the system has 
libGL.so.1, but not libGL.so), I think that approach will still run into 
issues - although I agree that having the ability to co-bundle multiple 
platfrom-dependent shared libraries onto the same artifact is nice.

Maurizio

On 16/09/2019 11:51, Mark Raynsford wrote:
> On 2019-09-16T10:53:09 +0100
> Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
>> I agree with this analysis.
>>
>> One addition - it's not really that jextract cares about sonames - it's
>> just that if you call
>>
>> System::loadLibrary("foo")
>>
>> and you are on Linux, the VM will try to load:
>>
>> libfoo.so
>>
>> on all the paths that are part of the native library path.
>>
>> If you want something different, then there's the more general
>> System::load which takes a full _patth_ (not a libname), which can of
>> course contain sonames and all.
> Just a quick question: Is anyone here familiar with how OSGi handles
> this? In my opinion, this stuff already seems to be a solved problem
> there.
>
> Bundles (jar files in OSGi speak) contain native libraries directly,
> and contain metadata in the MANIFEST.MF file that explain which native
> libraries match each arch/os combination. For example:
>
> Bundle-NativeCode:\
>    lwjgl_opengl32.dll;osname=Win32;processor=x86,\
>    lwjgl_opengl.dll;osname=Win32;processor=x86-64,\
>    liblwjgl_opengl.so;osname=Linux;processor=x86-64,\
>    liblwjgl_opengl.dylib;osname=MacOSX;processor=x86-64
>
> That's an extract from the OSGi bundles from the LWJGL project. The
> Bundle-NativeCode declaration specifies which native libraries are
> included, and which should be loaded in a given situation. You can see
> that it states that the runtime should load lwjgl_opengl32.dll if the
> current platform is Windows on x86. It should load liblwjgl_opengl.so
> if the current platform is Linux on x86-64, etc. It's also possible to
> state that a particular platform/arch doesn't require a native library.
>
> The runtime transparently extracts and arranges paths as necessary so
> that calls to System::loadLibrary("lwjgl_opengl") work correctly.
>
> I believe that JBoss modules work similarly.
>

From org.openjdk at io7m.com  Mon Sep 16 12:32:56 2019
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Mon, 16 Sep 2019 13:32:56 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <16c7f0f2-3fbe-ee1c-da5e-b061ba2001ba@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
 <20190916115126.73f85a8a@almond.int.arc7.info>
 <16c7f0f2-3fbe-ee1c-da5e-b061ba2001ba@oracle.com>
Message-ID: <20190916133256.2c31e22b@almond.int.arc7.info>

On 2019-09-16T12:55:20 +0100
Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

> Something along these lines might well be required yes - although AFAIK 
> not even OSGi can protect you from sonames and missing dependencies (as, 
> under the hood, it will still delegate to System::loadLibrary). Also, 
> while not required, I think OSGi typical use case will be to co-package 
> the required native libraries in a given bundle, which I don't think 
> it's exactly the case we're discussing here? E.g. I took a look at 
> lwjgl-opengl and that seems to load libGL that comes installed in the 
> system - outside the bundle, with a call to dlopen (on Linux). So, if 
> the system library is not installed correctly (e.g. the system has 
> libGL.so.1, but not libGL.so), I think that approach will still run into 
> issues - although I agree that having the ability to co-bundle multiple 
> platfrom-dependent shared libraries onto the same artifact is nice.
> 

Heh, yes, that particular library was perhaps not the best example I
could have picked. It was the one I had closest to hand. :)

LWJGL is a non-OSGi project that has been separately OSGi-ized. The
explicit, external load of libGL.so is because that library is part of
the system graphics drivers and so can't be distributed.

I take your point about the rest. I misunderstood and thought that the
problem was being unable to sensibly find bundled libraries.

-- 
Mark Raynsford | http://www.io7m.com


From iotsakp at gmail.com  Mon Sep 16 16:37:16 2019
From: iotsakp at gmail.com (Ioannis Tsakpinis)
Date: Mon, 16 Sep 2019 19:37:16 +0300
Subject: Project Panama & dynamic library loading
In-Reply-To: <20190916133256.2c31e22b@almond.int.arc7.info>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <238779db-79a5-2c38-e63b-ac3beab26b85@oracle.com>
 <c9752750-309a-a54e-24e7-3e93f4141287@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
 <20190916115126.73f85a8a@almond.int.arc7.info>
 <16c7f0f2-3fbe-ee1c-da5e-b061ba2001ba@oracle.com>
 <20190916133256.2c31e22b@almond.int.arc7.info>
Message-ID: <CAL=VLdUCbg0J+OetE=rYiX-Kq0hY4A=Dau8n0BEpQ2=Gg0CHBQ@mail.gmail.com>

Hey Maurizio and Mark,

The OpenGL module in LWJGL is a bit special. We need to load both a
system library (i.e. provided by the GPU driver or Mesa) and a separate
JNI library (bundled with LWJGL) that handles the bindings. This is
necessary because, unlike modern APIs like Vulkan, OpenGL function
pointers are basically thread-local (may be different across contexts).
We've found that it's more efficient to handle this in JNI, rather than
polluting every OpenGL function call with a Java-side thread-local
lookup (note: LWJGL exposes a static API, there's no "GL" object passed
around).

For the system library, by default LWJGL tries to load both libGL.so.1
(official & most common) and libGL.so (fallback for certain systems).
There is also a system property (can also be set programmatically) that
overrides the default lookup. This can be a simple name ("myGL"), or a
shared library name ("libmyGL.so"), or even an absolute path. This kind
of flexibility is very useful to many of our users (maybe not for
OpenGL but certainly for other libraries).

For the JNI library, the default and most convenient behavior is to
resolve it from the class/module-path. This usually means that we'll
find it inside a jar file, in which case it is extracted to a temporary
folder and loaded from there via System::load. This covers most
development scenarios and is often used in production as well. The
trade-off is a bit of extra I/O at startup, which is mitigated after
the first launch (the shared library is extracted again only if an
updated version is detected).

Choice of an appropriate temporary folder is an interesting problem by
itself (e.g. Files.createTempDirectory is our last resort), due to
versioning and various platform-specific difficulties, but the current
implementation has been robust for the past few years. Configurability
is important here too, so users can override the temporary folder if
they wish. For example, this is useful in a server setting where you
need multiple versions of the same application running concurrently.

Other details you might find interesting:

- System::load is preferred over System::loadLibrary. It's more
predictable and users don't have to worry about java.library.path.
- LWJGL doesn't know anything about OSGi, but we support it with a
fallback to System::loadLibrary when everything else fails.
- An org.lwjgl.librarypath property is available that functions exactly
like java.library.path but can be set independently to avoid conflicts
with other libraries.
- The name/path of every external library can be overridden. This
includes non-JNI shared libraries bundled with LWJGL, which can be
useful when an alternative build should be used (e.g. a debug build or
a build optimized for a specific system).
- The LWJGL core and various bindings are all explicit JPMS modules. We
put the module-info classes in META-INF/versions/9/ and there's no
trouble with either Java 8 and outdated IDEs/tooling or modern
environments. The shared library loading works fine everywhere.
- We have moved away from bundling shared libraries for multiple
platforms/architectures in the same jar/artifact. Some bindings include
shared libraries in the multi-megabyte range and bundling such a
library x <number of supported platforms> stops being practical. We
have mitigated the inconvenience by creating a "build customizer" on
our website (e.g. bundles the chosen bindings and corresponding
artifacts in a zip file or generates an appropriate Maven script).
- There is a debug mode that, when enabled, prints everything about the
shared library loading process. Which lookups were attempted, why they
failed, etc. It has turned library loading related issues from the
number one support headache, to virtually non-existent.
- When possible (using platform-specific APIs), the full path to the
loaded shared library is resolved (even when a simple dlopen("foo") was
used). Users can then be certain that their configuration is correct
when that path is printed in the debug mode output.

I hope this was useful,

- Ioannis

P.S. LWJGL is obviously going to adopt Project Panama at day one. We're
super excited about the work that's been going on and track progress
very closely. Expect more feedback when the low-level/memaccess API
and linkToNative are more stable/available.

On Mon, 16 Sep 2019 at 15:34, Mark Raynsford <org.openjdk at io7m.com> wrote:
>
> On 2019-09-16T12:55:20 +0100
> Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
> > Something along these lines might well be required yes - although AFAIK
> > not even OSGi can protect you from sonames and missing dependencies (as,
> > under the hood, it will still delegate to System::loadLibrary). Also,
> > while not required, I think OSGi typical use case will be to co-package
> > the required native libraries in a given bundle, which I don't think
> > it's exactly the case we're discussing here? E.g. I took a look at
> > lwjgl-opengl and that seems to load libGL that comes installed in the
> > system - outside the bundle, with a call to dlopen (on Linux). So, if
> > the system library is not installed correctly (e.g. the system has
> > libGL.so.1, but not libGL.so), I think that approach will still run into
> > issues - although I agree that having the ability to co-bundle multiple
> > platfrom-dependent shared libraries onto the same artifact is nice.
> >
>
> Heh, yes, that particular library was perhaps not the best example I
> could have picked. It was the one I had closest to hand. :)
>
> LWJGL is a non-OSGi project that has been separately OSGi-ized. The
> explicit, external load of libGL.so is because that library is part of
> the system graphics drivers and so can't be distributed.
>
> I take your point about the rest. I misunderstood and thought that the
> problem was being unable to sensibly find bundled libraries.
>
> --
> Mark Raynsford | http://www.io7m.com
>

From maurizio.cimadamore at oracle.com  Mon Sep 16 16:53:54 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 16 Sep 2019 17:53:54 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <CAL=VLdUCbg0J+OetE=rYiX-Kq0hY4A=Dau8n0BEpQ2=Gg0CHBQ@mail.gmail.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
 <20190916115126.73f85a8a@almond.int.arc7.info>
 <16c7f0f2-3fbe-ee1c-da5e-b061ba2001ba@oracle.com>
 <20190916133256.2c31e22b@almond.int.arc7.info>
 <CAL=VLdUCbg0J+OetE=rYiX-Kq0hY4A=Dau8n0BEpQ2=Gg0CHBQ@mail.gmail.com>
Message-ID: <fdbcf6fc-8d50-c7a1-06e8-1570e0fd3a4b@oracle.com>

Thanks for the feedback - you give us a lot to think about here, and 
your email is a perfect description of the pain that users are in when 
it comes to 'just load' a native library.

While in principle we could tackle all this as part of the Panama binder 
support, I think it would be very helpful to split this into a bunch of 
tasks/issues which we can solve more generally. As I mentioned before, 
the fact that System::loadLibrary seems not that integrated with the 
host environment looks like a bug; the ability to load a library from an 
archive seems also worth of consideration on its own merit (given that 
everybody is doing the trick of extracting the archived library 
somewhere and then load it from there).

There could be other relative self-contained piece of work like these 
which can be worked on (even in parallel) and benefit the wider 
community (even beyond Panama) interacting with native libraries and/or JNI.

Interestingly, your comment on splitting artifacts by platform (not to 
have to bundle too many native libs in the same artifact) seems to point 
_against_ the notion of a multi-platform jar.

Maurizio

On 16/09/2019 17:37, Ioannis Tsakpinis wrote:
> Hey Maurizio and Mark,
>
> The OpenGL module in LWJGL is a bit special. We need to load both a
> system library (i.e. provided by the GPU driver or Mesa) and a separate
> JNI library (bundled with LWJGL) that handles the bindings. This is
> necessary because, unlike modern APIs like Vulkan, OpenGL function
> pointers are basically thread-local (may be different across contexts).
> We've found that it's more efficient to handle this in JNI, rather than
> polluting every OpenGL function call with a Java-side thread-local
> lookup (note: LWJGL exposes a static API, there's no "GL" object passed
> around).
>
> For the system library, by default LWJGL tries to load both libGL.so.1
> (official & most common) and libGL.so (fallback for certain systems).
> There is also a system property (can also be set programmatically) that
> overrides the default lookup. This can be a simple name ("myGL"), or a
> shared library name ("libmyGL.so"), or even an absolute path. This kind
> of flexibility is very useful to many of our users (maybe not for
> OpenGL but certainly for other libraries).
>
> For the JNI library, the default and most convenient behavior is to
> resolve it from the class/module-path. This usually means that we'll
> find it inside a jar file, in which case it is extracted to a temporary
> folder and loaded from there via System::load. This covers most
> development scenarios and is often used in production as well. The
> trade-off is a bit of extra I/O at startup, which is mitigated after
> the first launch (the shared library is extracted again only if an
> updated version is detected).
>
> Choice of an appropriate temporary folder is an interesting problem by
> itself (e.g. Files.createTempDirectory is our last resort), due to
> versioning and various platform-specific difficulties, but the current
> implementation has been robust for the past few years. Configurability
> is important here too, so users can override the temporary folder if
> they wish. For example, this is useful in a server setting where you
> need multiple versions of the same application running concurrently.
>
> Other details you might find interesting:
>
> - System::load is preferred over System::loadLibrary. It's more
> predictable and users don't have to worry about java.library.path.
> - LWJGL doesn't know anything about OSGi, but we support it with a
> fallback to System::loadLibrary when everything else fails.
> - An org.lwjgl.librarypath property is available that functions exactly
> like java.library.path but can be set independently to avoid conflicts
> with other libraries.
> - The name/path of every external library can be overridden. This
> includes non-JNI shared libraries bundled with LWJGL, which can be
> useful when an alternative build should be used (e.g. a debug build or
> a build optimized for a specific system).
> - The LWJGL core and various bindings are all explicit JPMS modules. We
> put the module-info classes in META-INF/versions/9/ and there's no
> trouble with either Java 8 and outdated IDEs/tooling or modern
> environments. The shared library loading works fine everywhere.
> - We have moved away from bundling shared libraries for multiple
> platforms/architectures in the same jar/artifact. Some bindings include
> shared libraries in the multi-megabyte range and bundling such a
> library x <number of supported platforms> stops being practical. We
> have mitigated the inconvenience by creating a "build customizer" on
> our website (e.g. bundles the chosen bindings and corresponding
> artifacts in a zip file or generates an appropriate Maven script).
> - There is a debug mode that, when enabled, prints everything about the
> shared library loading process. Which lookups were attempted, why they
> failed, etc. It has turned library loading related issues from the
> number one support headache, to virtually non-existent.
> - When possible (using platform-specific APIs), the full path to the
> loaded shared library is resolved (even when a simple dlopen("foo") was
> used). Users can then be certain that their configuration is correct
> when that path is printed in the debug mode output.
>
> I hope this was useful,
>
> - Ioannis
>
> P.S. LWJGL is obviously going to adopt Project Panama at day one. We're
> super excited about the work that's been going on and track progress
> very closely. Expect more feedback when the low-level/memaccess API
> and linkToNative are more stable/available.
>
> On Mon, 16 Sep 2019 at 15:34, Mark Raynsford <org.openjdk at io7m.com> wrote:
>> On 2019-09-16T12:55:20 +0100
>> Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>>> Something along these lines might well be required yes - although AFAIK
>>> not even OSGi can protect you from sonames and missing dependencies (as,
>>> under the hood, it will still delegate to System::loadLibrary). Also,
>>> while not required, I think OSGi typical use case will be to co-package
>>> the required native libraries in a given bundle, which I don't think
>>> it's exactly the case we're discussing here? E.g. I took a look at
>>> lwjgl-opengl and that seems to load libGL that comes installed in the
>>> system - outside the bundle, with a call to dlopen (on Linux). So, if
>>> the system library is not installed correctly (e.g. the system has
>>> libGL.so.1, but not libGL.so), I think that approach will still run into
>>> issues - although I agree that having the ability to co-bundle multiple
>>> platfrom-dependent shared libraries onto the same artifact is nice.
>>>
>> Heh, yes, that particular library was perhaps not the best example I
>> could have picked. It was the one I had closest to hand. :)
>>
>> LWJGL is a non-OSGi project that has been separately OSGi-ized. The
>> explicit, external load of libGL.so is because that library is part of
>> the system graphics drivers and so can't be distributed.
>>
>> I take your point about the rest. I misunderstood and thought that the
>> problem was being unable to sensibly find bundled libraries.
>>
>> --
>> Mark Raynsford | http://www.io7m.com
>>

From org.openjdk at io7m.com  Mon Sep 16 17:06:41 2019
From: org.openjdk at io7m.com (Mark Raynsford)
Date: Mon, 16 Sep 2019 18:06:41 +0100
Subject: Project Panama & dynamic library loading
In-Reply-To: <fdbcf6fc-8d50-c7a1-06e8-1570e0fd3a4b@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
 <20190916115126.73f85a8a@almond.int.arc7.info>
 <16c7f0f2-3fbe-ee1c-da5e-b061ba2001ba@oracle.com>
 <20190916133256.2c31e22b@almond.int.arc7.info>
 <CAL=VLdUCbg0J+OetE=rYiX-Kq0hY4A=Dau8n0BEpQ2=Gg0CHBQ@mail.gmail.com>
 <fdbcf6fc-8d50-c7a1-06e8-1570e0fd3a4b@oracle.com>
Message-ID: <20190916180641.0a279656@almond.int.arc7.info>

On 2019-09-16T17:53:54 +0100
Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
> Interestingly, your comment on splitting artifacts by platform (not to 
> have to bundle too many native libs in the same artifact) seems to point 
> _against_ the notion of a multi-platform jar.
> 

To be clear: The normal LWJGL artifacts have separate jars for
per-platform natives. In OSGi, however, it's more typical to bundle all
native libraries into the same ... bundle ... so I did this when I
produced them.

We have a set of Maven POMs here that repackage the existing LWJGL jars
into conventional OSGi bundles:

  https://github.com/LWJGL/lwjgl3-osgi

These are very much not an integral part of LWJGL (as Ioannis said:
LWJGL knows nothing about OSGi), they're developed and maintained
separately because I need OSGi support.

--
Mark Raynsford | http://www.io7m.com


From iotsakp at gmail.com  Mon Sep 16 17:39:16 2019
From: iotsakp at gmail.com (Ioannis Tsakpinis)
Date: Mon, 16 Sep 2019 20:39:16 +0300
Subject: Project Panama & dynamic library loading
In-Reply-To: <fdbcf6fc-8d50-c7a1-06e8-1570e0fd3a4b@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <E1044F2C-4AC5-442D-89CD-B6496284E203@oracle.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
 <20190916115126.73f85a8a@almond.int.arc7.info>
 <16c7f0f2-3fbe-ee1c-da5e-b061ba2001ba@oracle.com>
 <20190916133256.2c31e22b@almond.int.arc7.info>
 <CAL=VLdUCbg0J+OetE=rYiX-Kq0hY4A=Dau8n0BEpQ2=Gg0CHBQ@mail.gmail.com>
 <fdbcf6fc-8d50-c7a1-06e8-1570e0fd3a4b@oracle.com>
Message-ID: <CAL=VLdVqWHS5dgQZhB9_Uv2CnBuXTV7KR6NkMvWvHBXQwwABTg@mail.gmail.com>

On Mon, 16 Sep 2019 at 19:54, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> Interestingly, your comment on splitting artifacts by platform (not to
> have to bundle too many native libs in the same artifact) seems to point
> _against_ the notion of a multi-platform jar.

Indeed. As an example, these are the bgfx artifacts in the latest LWJGL
release:

https://repo1.maven.org/maven2/org/lwjgl/lwjgl-bgfx/3.2.3/

With such file sizes, the difference between downloading/deploying
natives for a single platform vs all 6 platforms can be significant.

Also interesting:

- We use same artifact name + different classifier for the various
platforms.
- The module-info declaration in the native jar files is identical for
all platforms. This implies that putting multiple such jars in the
module path will produce an error at JVM start-up.
- The package structure inside the native jar files allows users to
combine all natives (+ the identical module-info.class) to a single jar
file, if they so wish. It's just something that they'd have to do
manually and I'm not aware of anyone opting for such a solution.

- Ioannis

From samuel.audet at gmail.com  Tue Sep 17 00:26:46 2019
From: samuel.audet at gmail.com (Samuel Audet)
Date: Tue, 17 Sep 2019 09:26:46 +0900
Subject: Project Panama & dynamic library loading
In-Reply-To: <fdbcf6fc-8d50-c7a1-06e8-1570e0fd3a4b@oracle.com>
References: <9d9fed98-e7ac-305e-edcc-fa3f342540a9@gmail.com>
 <c8aa564b-18cb-ab6d-f7eb-addfb2be4b7c@gmail.com>
 <41B7BF12-FD7F-4E23-BF5F-4E5EB78FABCB@oracle.com>
 <59308476-7bc4-1da3-95cd-7b753c2adbf5@gmail.com>
 <8a934177-9eb1-a8f6-e9f4-a161e743e063@oracle.com>
 <cc0a118e-05a2-53bc-eb25-1ef2394dac04@gmail.com>
 <de2d29a2-3616-a58b-087c-192205d2433e@oracle.com>
 <02f54b37-8648-2bf7-08c1-f6dd7a99b87b@gmail.com>
 <1c18397b-0bfd-b2e8-7bc4-4c46de6b52a0@oracle.com>
 <dfe88e74-351c-393c-bfad-02012c475f49@gmail.com>
 <3e8b958d-a5a0-2899-7134-52109bdfb4ba@oracle.com>
 <c81c8856-cbb2-4b0e-bb93-308283f4607e@gmail.com>
 <10b29f1f-d0ff-b6d5-ddf6-915b529ab23e@gmail.com>
 <a31f6fc2-535d-66ba-d978-98216551eeb6@oracle.com>
 <20190916115126.73f85a8a@almond.int.arc7.info>
 <16c7f0f2-3fbe-ee1c-da5e-b061ba2001ba@oracle.com>
 <20190916133256.2c31e22b@almond.int.arc7.info>
 <CAL=VLdUCbg0J+OetE=rYiX-Kq0hY4A=Dau8n0BEpQ2=Gg0CHBQ@mail.gmail.com>
 <fdbcf6fc-8d50-c7a1-06e8-1570e0fd3a4b@oracle.com>
Message-ID: <93e89f61-fd51-dd1e-9dbb-986aaf0f6a02@gmail.com>

I've had to solve the same kind of issues as Ioannis and Mark are 
describing, and I also do believe this kind of API needs to be part of 
the JDK...

Anyway what I'm tackling is more general than LWJGL, and I do need to do 
something about sonames, library preloading, and what not. I wrote my 
own "loadLibrary()" that supports sonames with a string like 
`name at .version`, which ends up loading `libname.so.version` on Linux and 
`libname.version.dylib` on Mac, and more can be added.

On 9/17/19 1:53 AM, Maurizio Cimadamore wrote:
> Thanks for the feedback - you give us a lot to think about here, and 
> your email is a perfect description of the pain that users are in when 
> it comes to 'just load' a native library.
> 
> While in principle we could tackle all this as part of the Panama binder 
> support, I think it would be very helpful to split this into a bunch of 
> tasks/issues which we can solve more generally. As I mentioned before, 
> the fact that System::loadLibrary seems not that integrated with the 
> host environment looks like a bug; the ability to load a library from an 
> archive seems also worth of consideration on its own merit (given that 
> everybody is doing the trick of extracting the archived library 
> somewhere and then load it from there).
> 
> There could be other relative self-contained piece of work like these 
> which can be worked on (even in parallel) and benefit the wider 
> community (even beyond Panama) interacting with native libraries and/or 
> JNI.
> 
> Interestingly, your comment on splitting artifacts by platform (not to 
> have to bundle too many native libs in the same artifact) seems to point 
> _against_ the notion of a multi-platform jar.
> 
> Maurizio
> 
> On 16/09/2019 17:37, Ioannis Tsakpinis wrote:
>> Hey Maurizio and Mark,
>>
>> The OpenGL module in LWJGL is a bit special. We need to load both a
>> system library (i.e. provided by the GPU driver or Mesa) and a separate
>> JNI library (bundled with LWJGL) that handles the bindings. This is
>> necessary because, unlike modern APIs like Vulkan, OpenGL function
>> pointers are basically thread-local (may be different across contexts).
>> We've found that it's more efficient to handle this in JNI, rather than
>> polluting every OpenGL function call with a Java-side thread-local
>> lookup (note: LWJGL exposes a static API, there's no "GL" object passed
>> around).
>>
>> For the system library, by default LWJGL tries to load both libGL.so.1
>> (official & most common) and libGL.so (fallback for certain systems).
>> There is also a system property (can also be set programmatically) that
>> overrides the default lookup. This can be a simple name ("myGL"), or a
>> shared library name ("libmyGL.so"), or even an absolute path. This kind
>> of flexibility is very useful to many of our users (maybe not for
>> OpenGL but certainly for other libraries).
>>
>> For the JNI library, the default and most convenient behavior is to
>> resolve it from the class/module-path. This usually means that we'll
>> find it inside a jar file, in which case it is extracted to a temporary
>> folder and loaded from there via System::load. This covers most
>> development scenarios and is often used in production as well. The
>> trade-off is a bit of extra I/O at startup, which is mitigated after
>> the first launch (the shared library is extracted again only if an
>> updated version is detected).
>>
>> Choice of an appropriate temporary folder is an interesting problem by
>> itself (e.g. Files.createTempDirectory is our last resort), due to
>> versioning and various platform-specific difficulties, but the current
>> implementation has been robust for the past few years. Configurability
>> is important here too, so users can override the temporary folder if
>> they wish. For example, this is useful in a server setting where you
>> need multiple versions of the same application running concurrently.
>>
>> Other details you might find interesting:
>>
>> - System::load is preferred over System::loadLibrary. It's more
>> predictable and users don't have to worry about java.library.path.
>> - LWJGL doesn't know anything about OSGi, but we support it with a
>> fallback to System::loadLibrary when everything else fails.
>> - An org.lwjgl.librarypath property is available that functions exactly
>> like java.library.path but can be set independently to avoid conflicts
>> with other libraries.
>> - The name/path of every external library can be overridden. This
>> includes non-JNI shared libraries bundled with LWJGL, which can be
>> useful when an alternative build should be used (e.g. a debug build or
>> a build optimized for a specific system).
>> - The LWJGL core and various bindings are all explicit JPMS modules. We
>> put the module-info classes in META-INF/versions/9/ and there's no
>> trouble with either Java 8 and outdated IDEs/tooling or modern
>> environments. The shared library loading works fine everywhere.
>> - We have moved away from bundling shared libraries for multiple
>> platforms/architectures in the same jar/artifact. Some bindings include
>> shared libraries in the multi-megabyte range and bundling such a
>> library x <number of supported platforms> stops being practical. We
>> have mitigated the inconvenience by creating a "build customizer" on
>> our website (e.g. bundles the chosen bindings and corresponding
>> artifacts in a zip file or generates an appropriate Maven script).
>> - There is a debug mode that, when enabled, prints everything about the
>> shared library loading process. Which lookups were attempted, why they
>> failed, etc. It has turned library loading related issues from the
>> number one support headache, to virtually non-existent.
>> - When possible (using platform-specific APIs), the full path to the
>> loaded shared library is resolved (even when a simple dlopen("foo") was
>> used). Users can then be certain that their configuration is correct
>> when that path is printed in the debug mode output.
>>
>> I hope this was useful,
>>
>> - Ioannis
>>
>> P.S. LWJGL is obviously going to adopt Project Panama at day one. We're
>> super excited about the work that's been going on and track progress
>> very closely. Expect more feedback when the low-level/memaccess API
>> and linkToNative are more stable/available.
>>
>> On Mon, 16 Sep 2019 at 15:34, Mark Raynsford <org.openjdk at io7m.com> 
>> wrote:
>>> On 2019-09-16T12:55:20 +0100
>>> Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>>
>>>> Something along these lines might well be required yes - although AFAIK
>>>> not even OSGi can protect you from sonames and missing dependencies (as,
>>>> under the hood, it will still delegate to System::loadLibrary). Also,
>>>> while not required, I think OSGi typical use case will be to co-package
>>>> the required native libraries in a given bundle, which I don't think
>>>> it's exactly the case we're discussing here? E.g. I took a look at
>>>> lwjgl-opengl and that seems to load libGL that comes installed in the
>>>> system - outside the bundle, with a call to dlopen (on Linux). So, if
>>>> the system library is not installed correctly (e.g. the system has
>>>> libGL.so.1, but not libGL.so), I think that approach will still run into
>>>> issues - although I agree that having the ability to co-bundle multiple
>>>> platfrom-dependent shared libraries onto the same artifact is nice.
>>>>
>>> Heh, yes, that particular library was perhaps not the best example I
>>> could have picked. It was the one I had closest to hand. :)
>>>
>>> LWJGL is a non-OSGi project that has been separately OSGi-ized. The
>>> explicit, external load of libGL.so is because that library is part of
>>> the system graphics drivers and so can't be distributed.
>>>
>>> I take your point about the rest. I misunderstood and thought that the
>>> problem was being unable to sensibly find bundled libraries.
>>>
>>> -- 
>>> Mark Raynsford | http://www.io7m.com
>>>


From jatin.bhateja at intel.com  Wed Sep 18 06:02:33 2019
From: jatin.bhateja at intel.com (jatin.bhateja at intel.com)
Date: Wed, 18 Sep 2019 06:02:33 +0000
Subject: hg: panama/dev: Summary: [vector][generic-opers] Changes for build
 failures on non-X86 targets and some code-refactoring.
Message-ID: <201909180602.x8I62XOo025337@aojmv0008.oracle.com>

Changeset: 2ad69b36c78f
Author:    Jatin Bhateja <jatin.bhateja at intel.com>
Date:      2019-09-18 11:35 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/2ad69b36c78f

Summary: [vector][generic-opers] Changes for build failures on non-X86 targets and some code-refactoring.
Reviewed-by: sandhya.viswanathan at intel.com
Contributed-by: jatin.bhateja at intel.com

! src/hotspot/cpu/x86/postSelection_x86.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/type.cpp


From jatin.bhateja at intel.com  Wed Sep 18 06:05:14 2019
From: jatin.bhateja at intel.com (jatin.bhateja at intel.com)
Date: Wed, 18 Sep 2019 06:05:14 +0000
Subject: hg: panama/dev: Summary: [vector][generic-opers] Changes for build
 failures on non-X86 targets and some code-refactoring.
Message-ID: <201909180605.x8I65EkP027019@aojmv0008.oracle.com>

Changeset: d78d3d6098ab
Author:    jbhateja
Date:      2019-09-18 11:38 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/d78d3d6098ab

Summary: [vector][generic-opers] Changes for build failures on non-X86 targets and some code-refactoring.
Reviewed-by: sandhya.viswanathan at intel.com
Contributed-by: jatin.bhateja at intel.com

! src/hotspot/cpu/x86/postSelection_x86.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/type.cpp


From maurizio.cimadamore at oracle.com  Wed Sep 18 22:03:50 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 18 Sep 2019 22:03:50 +0000
Subject: hg: panama/dev: 66 new changesets
Message-ID: <201909182203.x8IM3uBj008125@aojmv0008.oracle.com>

Changeset: c0cc906cb29c
Author:    darcy
Date:      2019-09-11 16:06 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/c0cc906cb29c

8230734: Remove default constructors from java.compiler
Reviewed-by: jjg

! src/java.compiler/share/classes/javax/tools/DiagnosticCollector.java
! src/java.compiler/share/classes/javax/tools/ToolProvider.java

Changeset: b00b4706ec0f
Author:    afarley
Date:      2019-09-11 23:10 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/b00b4706ec0f

8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow
Summary: Check buffer overflow when the jdwp agent full dll name is built
Reviewed-by: cjplummer, sspitsyn

! src/jdk.jdwp.agent/unix/native/libjdwp/linker_md.c
! src/jdk.jdwp.agent/windows/native/libjdwp/linker_md.c

Changeset: 50e1d346a126
Author:    lmesnik
Date:      2019-09-11 16:25 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/50e1d346a126

8230830: No required ResourceMark in src/hotspot/share/prims/jvmtiImpl.cpp:JvmtiSuspendControl::print()
Reviewed-by: dholmes, cjplummer, sspitsyn

! src/hotspot/share/prims/jvmtiImpl.cpp

Changeset: 0f6c749acd15
Author:    jwilhelm
Date:      2019-09-12 03:21 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/0f6c749acd15

Added tag jdk-14+14 for changeset cddef3bde924

! .hgtags

Changeset: adc72cd1d1f2
Author:    dholmes
Date:      2019-09-11 22:09 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/adc72cd1d1f2

8230423: Move os::sleep to JavaThread::sleep
Reviewed-by: rehn, dcubed

! src/hotspot/cpu/x86/rdtsc_x86.cpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
! src/hotspot/share/jvmci/jvmciCompiler.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp
! test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp
! test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp

Changeset: 0d97bf7cf8a4
Author:    iklam
Date:      2019-09-11 18:31 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/0d97bf7cf8a4

8230586: Encapsulate fields in filemap.hpp
Reviewed-by: ccheung

! src/hotspot/share/classfile/classLoaderExt.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/include/cds.h
! src/hotspot/share/interpreter/abstractInterpreter.cpp
! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/dynamicArchive.hpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/filemap.hpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/memory/metaspaceShared.hpp
! src/hotspot/share/prims/cdsoffsets.cpp
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java

Changeset: fa0514bdc09b
Author:    mbaesken
Date:      2019-09-11 16:54 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/fa0514bdc09b

8230861: missing ReleaseStringUTFChars in Java_sun_security_pkcs11_wrapper_PKCS11_connect
Reviewed-by: alanb, stuefe

! src/jdk.crypto.cryptoki/unix/native/libj2pkcs11/p11_md.c

Changeset: ea93d6a9f720
Author:    mbaesken
Date:      2019-09-11 16:13 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/ea93d6a9f720

8230856: Java_java_net_NetworkInterface_getByName0 on unix misses ReleaseStringUTFChars in early return
Reviewed-by: dfuchs, stuefe, vtewari

! src/java.base/unix/native/libnet/NetworkInterface.c

Changeset: b2a4b22f8cf2
Author:    roland
Date:      2019-08-23 14:22 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/b2a4b22f8cf2

8229701: aarch64: C2 OSR compilation fails with "shouldn't process one node several times" in final graph reshaping
Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/compile.cpp
+ test/hotspot/jtreg/compiler/c2/aarch64/ConvI2LWideningAssertTooStrong.java

Changeset: 689a80d20550
Author:    chagedorn
Date:      2019-09-12 12:12 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/689a80d20550

8230762: Change MacroAssembler::debug32/64 to use fatal instead of assert
Summary: Always call fatal from debug32/64 to also crash in product build as a follow-up to JDK-8225653.
Reviewed-by: roland, thartmann

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp

Changeset: 46e11f978852
Author:    chagedorn
Date:      2019-09-12 12:23 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/46e11f978852

8220416: Comparison of klass pointers is not optimized any more
Summary: Enables dead klass pointer optimization (since JDK-6964458) again.
Reviewed-by: roland, thartmann

! src/hotspot/share/opto/subnode.cpp

Changeset: efcda145fb2c
Author:    stuefe
Date:      2019-09-12 12:51 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/efcda145fb2c

8230888: jfrVirtualMemory.cpp should include globals.hpp
Reviewed-by: dholmes, mgronlun

! src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp

Changeset: 79186d82463e
Author:    roland
Date:      2019-09-03 09:28 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/79186d82463e

8230470: Shenandoah doesn't need change from JDK-8212610 anymore
Reviewed-by: thartmann

! src/hotspot/share/opto/loopPredicate.cpp
! src/hotspot/share/opto/loopnode.hpp

Changeset: 5302477c8285
Author:    dfuchs
Date:      2019-09-12 15:46 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/5302477c8285

8230858: Replace wildcard address with loopback or local host in tests - part 23
Summary: Add new traces for better diagnosis, refrain binding to the wildcard address when possible.
Reviewed-by: chegar, xuelei

! test/jdk/java/net/CookieHandler/CookieManagerTest.java
! test/jdk/java/net/Socket/HttpProxy.java
! test/jdk/java/net/Socket/NullHost.java
! test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java
! test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/Identities.java
! test/jdk/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java
! test/jdk/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java
! test/jdk/sun/net/www/protocol/jar/B4957695.java

Changeset: 85e1de070bef
Author:    ccheung
Date:      2019-09-12 09:59 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/85e1de070bef

8186988: use log_warning() and log_error() instead of tty->print_cr for CDS warning and error messages
Reviewed-by: stuefe, iklam, dholmes

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoaderExt.cpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/metaspaceShared.cpp

Changeset: f63f50a4bf43
Author:    igerasim
Date:      2019-09-12 11:07 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/f63f50a4bf43

8230829: Matcher matches a surrogate pair that crosses border of the region
Reviewed-by: naoto

! src/java.base/share/classes/java/util/regex/Pattern.java
! test/jdk/java/util/regex/RegExTest.java

Changeset: 48d51def09f9
Author:    pliden
Date:      2019-09-13 08:40 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/48d51def09f9

8230845: ZGC: Implement ZLock using os::PlatformMutex
Reviewed-by: stefank

! src/hotspot/share/gc/z/zLock.hpp
! src/hotspot/share/gc/z/zLock.inline.hpp

Changeset: 70aebd567a5c
Author:    pliden
Date:      2019-09-13 08:40 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/70aebd567a5c

8230846: ZGC: Make ZUtils::alloc_aligned() posix-specific
Reviewed-by: stefank

+ src/hotspot/os/posix/gc/z/zUtils_posix.cpp
- src/hotspot/share/gc/z/zUtils.cpp

Changeset: dc792fa77da0
Author:    pliden
Date:      2019-09-13 08:40 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/dc792fa77da0

8230877: Rename THREAD_LOCAL_DECL to THREAD_LOCAL
Reviewed-by: kbarrett, dholmes

! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/utilities/globalDefinitions_gcc.hpp
! src/hotspot/share/utilities/globalDefinitions_solstudio.hpp
! src/hotspot/share/utilities/globalDefinitions_visCPP.hpp
! src/hotspot/share/utilities/globalDefinitions_xlc.hpp

Changeset: 9b4717ca9bd1
Author:    pliden
Date:      2019-09-13 08:40 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/9b4717ca9bd1

8230878: ZGC: Use THREAD_LOCAL instead of __thread
Reviewed-by: kbarrett

! src/hotspot/share/gc/z/zCPU.cpp
! src/hotspot/share/gc/z/zCPU.hpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zStat.hpp
! src/hotspot/share/gc/z/zThread.cpp
! src/hotspot/share/gc/z/zThread.hpp

Changeset: 1def54255e93
Author:    prappo
Date:      2019-09-13 11:00 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/1def54255e93

8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect
Reviewed-by: dfuchs, martin, robm

! src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java
! src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java
! test/jdk/ProblemList.txt
! test/jdk/com/sun/jndi/ldap/LdapTimeoutTest.java
! test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java

Changeset: 41082cd965cc
Author:    lmesnik
Date:      2019-09-13 09:34 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/41082cd965cc

8230881: serviceability/sa/TestJmapCore tests fail with java.lang.RuntimeException: Could not find dump file
Reviewed-by: dholmes, cjplummer

! test/hotspot/jtreg/serviceability/sa/TestJmapCore.java

Changeset: 88bbe06ab8d6
Author:    bchristi
Date:      2019-09-13 09:33 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/88bbe06ab8d6

8230937: Update bugid in ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java
Reviewed-by: dholmes, mchung

! test/hotspot/jtreg/ProblemList.txt

Changeset: ff0eae1719d0
Author:    dcubed
Date:      2019-09-13 18:54 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/ff0eae1719d0

8230938: Deprecate MonitorBound
Reviewed-by: dholmes

! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: 3054503bad7d
Author:    bpb
Date:      2019-09-13 16:03 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/3054503bad7d

8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina
Reviewed-by: alanb

! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java
! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java
! src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c
! src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java

Changeset: caa25ab47aca
Author:    mgronlun
Date:      2019-09-14 14:40 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/caa25ab47aca

8225797: OldObjectSample event creates unexpected amount of checkpoint data
Reviewed-by: egahlin

! src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp
! src/hotspot/share/jfr/jfr.cpp
! src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp
! src/hotspot/share/jfr/leakprofiler/chains/edgeStore.hpp
! src/hotspot/share/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp
! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp
! src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp
! src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.hpp
! src/hotspot/share/jfr/leakprofiler/sampling/sampleList.hpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.hpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp
- src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp
! src/hotspot/share/jfr/recorder/repository/jfrChunkState.cpp
! src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
! src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.cpp
! src/hotspot/share/jfr/recorder/repository/jfrChunkWriter.hpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
+ src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp
+ src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.hpp
! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.hpp
! src/hotspot/share/jfr/recorder/storage/jfrMemorySpace.hpp
! src/hotspot/share/jfr/recorder/storage/jfrMemorySpace.inline.hpp
! src/hotspot/share/jfr/support/jfrKlassExtension.hpp
! src/hotspot/share/jfr/support/jfrThreadLocal.cpp
! src/hotspot/share/jfr/support/jfrThreadLocal.hpp
! src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp
+ src/hotspot/share/jfr/utilities/jfrBlob.cpp
+ src/hotspot/share/jfr/utilities/jfrBlob.hpp
! src/hotspot/share/jfr/utilities/jfrHashtable.hpp
! src/hotspot/share/jfr/utilities/jfrTypes.hpp
+ src/hotspot/share/jfr/writers/jfrTypeWriterHost.hpp
! src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp

Changeset: 515fc9f6b2d6
Author:    mgronlun
Date:      2019-09-14 18:45 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/515fc9f6b2d6

8231025: Incorrect method tag offset for big endian platform
Reviewed-by: egahlin

! src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp

Changeset: 51cd29502ea9
Author:    dl
Date:      2019-09-14 11:16 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/51cd29502ea9

8229442: AQS and lock classes refresh
Reviewed-by: martin

! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/Lock.java
! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java
! test/jdk/java/util/concurrent/locks/Lock/CheckedLockLoops.java
! test/jdk/java/util/concurrent/locks/Lock/FlakyMutex.java
! test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java
! test/jdk/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java
! test/jdk/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java
! test/jdk/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java
! test/jdk/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
! test/jdk/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java

Changeset: 2081ff900d65
Author:    dl
Date:      2019-09-14 11:20 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/2081ff900d65

8227235: rare failures in testForkHelpQuiesce tck tests
Reviewed-by: martin, alanb

! test/jdk/java/util/concurrent/tck/ForkJoinTask8Test.java
! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java

Changeset: f689a48dba4b
Author:    dl
Date:      2019-09-14 11:24 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/f689a48dba4b

8221168: java/util/concurrent/CountDownLatch/Basic.java fails
Reviewed-by: martin, alanb

! test/jdk/java/util/concurrent/CountDownLatch/Basic.java

Changeset: 6a556bcd94fc
Author:    dl
Date:      2019-09-14 11:26 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/6a556bcd94fc

8145138: CyclicBarrier/Basic.java failed with "3 not equal to 4"
Reviewed-by: martin, alanb

! test/jdk/java/util/concurrent/CyclicBarrier/Basic.java

Changeset: 1e4270f875ee
Author:    dl
Date:      2019-09-14 11:26 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/1e4270f875ee

8225490: Miscellaneous changes imported from jsr166 CVS 2019-09
Reviewed-by: martin, alanb

! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/java.base/share/classes/java/util/concurrent/Phaser.java
! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/java.base/share/classes/java/util/concurrent/package-info.java
! test/jdk/java/util/Map/Get.java
! test/jdk/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java
! test/jdk/java/util/concurrent/ConcurrentHashMap/MapCheck.java
! test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
! test/jdk/java/util/concurrent/ConcurrentHashMap/ToArray.java
! test/jdk/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java
! test/jdk/java/util/concurrent/FutureTask/BlockingTaskExecutor.java
! test/jdk/java/util/concurrent/FutureTask/CancelledFutureLoops.java
! test/jdk/java/util/concurrent/FutureTask/DoneTimedGetLoops.java
! test/jdk/java/util/concurrent/Phaser/FickleRegister.java
! test/jdk/java/util/concurrent/Phaser/TieredArriveLoops.java
! test/jdk/java/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java
! test/jdk/java/util/concurrent/TimeUnit/Basic.java
! test/jdk/java/util/concurrent/atomic/DoubleAdderDemo.java
! test/jdk/java/util/concurrent/tck/AbstractQueuedLongSynchronizerTest.java
! test/jdk/java/util/concurrent/tck/AbstractQueuedSynchronizerTest.java
! test/jdk/java/util/concurrent/tck/ArrayBlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/BlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java
! test/jdk/java/util/concurrent/tck/CountDownLatchTest.java
! test/jdk/java/util/concurrent/tck/CyclicBarrierTest.java
! test/jdk/java/util/concurrent/tck/DelayQueueTest.java
! test/jdk/java/util/concurrent/tck/DoubleAccumulatorTest.java
! test/jdk/java/util/concurrent/tck/ForkJoinPool9Test.java
! test/jdk/java/util/concurrent/tck/FutureTaskTest.java
! test/jdk/java/util/concurrent/tck/JSR166TestCase.java
! test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
! test/jdk/java/util/concurrent/tck/LinkedBlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/LinkedTransferQueueTest.java
! test/jdk/java/util/concurrent/tck/LongAccumulatorTest.java
! test/jdk/java/util/concurrent/tck/MapTest.java
! test/jdk/java/util/concurrent/tck/PhaserTest.java
! test/jdk/java/util/concurrent/tck/PriorityBlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java
! test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java
! test/jdk/java/util/concurrent/tck/SemaphoreTest.java
! test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java
! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java
! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java
! test/jdk/java/util/concurrent/tck/TimeUnitTest.java

Changeset: 593005ac5a0a
Author:    stooke
Date:      2019-09-15 07:47 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/593005ac5a0a

8216354: Syntax error in toolchain_windows.m4
Reviewed-by: erikj, dholmes, clanger

! make/autoconf/toolchain_windows.m4

Changeset: a6f653312b19
Author:    stuefe
Date:      2019-09-15 08:41 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/a6f653312b19

8230910: libsspi_bridge does not build on Windows 32bit
Reviewed-by: alanb, weijun

! src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp

Changeset: a6c85c21aa39
Author:    darcy
Date:      2019-09-15 13:23 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/a6c85c21aa39

8230882: Use @index in javax.lang.model javadoc
Reviewed-by: jjg

! src/java.compiler/share/classes/javax/lang/model/package-info.java

Changeset: 24df796eef3d
Author:    dholmes
Date:      2019-09-15 21:00 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/24df796eef3d

8231033: Problemlist ReservedStackTest
8231034: ProblemList failing ThreadMXBean tests
Reviewed-by: darcy

! test/hotspot/jtreg/ProblemList.txt
! test/jdk/ProblemList.txt

Changeset: b35771556cd0
Author:    clanger
Date:      2019-09-16 09:21 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/b35771556cd0

8230850: Test sun/tools/jcmd/TestProcessHelper.java fails intermittently
Reviewed-by: stuefe, cjplummer, sgehwolf

! test/jdk/sun/tools/jcmd/TestProcessHelper.java

Changeset: d003b3ef8b60
Author:    clanger
Date:      2019-09-16 09:28 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/d003b3ef8b60

8230854: Cleanup SuppressWarnings in test lib and remove noisy traces in StreamPumper
Reviewed-by: stuefe, dholmes

! test/lib/jdk/test/lib/Platform.java
! test/lib/jdk/test/lib/Utils.java
! test/lib/jdk/test/lib/process/ProcessTools.java
! test/lib/jdk/test/lib/process/StreamPumper.java

Changeset: 00aebe177a71
Author:    thartmann
Date:      2019-09-16 13:53 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/00aebe177a71

8230742: Make AggressiveUnboxing a diagnostic flag
Summary: AggressiveUnboxing is enabled by default. It should therefore be a diagnostic flag.
Reviewed-by: roland, shade

! src/hotspot/share/opto/c2_globals.hpp

Changeset: 6a30ad1cfeec
Author:    mbaesken
Date:      2019-09-13 11:04 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/6a30ad1cfeec

8230901: missing ReleaseStringUTFChars in serviceability native code
Reviewed-by: stuefe, sspitsyn

! src/java.instrument/share/native/libinstrument/JPLISAgent.c
! src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp

Changeset: d349347d6b5f
Author:    mbaesken
Date:      2019-09-13 07:43 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/d349347d6b5f

8230900: missing ReleaseStringUTFChars in java.desktop native code
Reviewed-by: clanger, prr

! src/java.desktop/unix/native/common/awt/fontpath.c
! src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp

Changeset: 272910ccd7bb
Author:    pliden
Date:      2019-09-17 09:51 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/272910ccd7bb

8230796: Remove BarrierSet::oop_equals_operator_allowed()
Reviewed-by: tschatzl, shade

! src/hotspot/share/gc/shared/barrierSet.hpp
! src/hotspot/share/oops/oopsHierarchy.cpp
! src/hotspot/share/oops/oopsHierarchy.hpp

Changeset: 470af058bd5f
Author:    pliden
Date:      2019-09-17 09:51 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/470af058bd5f

8230808: Remove Access::equals()
Reviewed-by: tschatzl, shade

! src/hotspot/share/gc/shared/barrierSet.hpp
- src/hotspot/share/oops/access.cpp
! src/hotspot/share/oops/access.hpp
! src/hotspot/share/oops/access.inline.hpp
! src/hotspot/share/oops/accessBackend.hpp
! src/hotspot/share/oops/oop.hpp

Changeset: 4932dce35882
Author:    pliden
Date:      2019-09-17 09:51 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/4932dce35882

8230841: Remove oopDesc::equals()
Reviewed-by: rkennke, tschatzl

! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/ci/ciObjectFactory.hpp
! src/hotspot/share/classfile/classLoaderData.cpp
! src/hotspot/share/classfile/classLoaderStats.hpp
! src/hotspot/share/classfile/dictionary.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.inline.hpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/protectionDomainCache.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/referenceProcessor.hpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp
! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/interpreter/bytecodeInterpreter.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/jvmci/jvmciCompiler.cpp
! src/hotspot/share/memory/heapShared.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/compressedOops.inline.hpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klassVtable.cpp
! src/hotspot/share/oops/objArrayKlass.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiTagMap.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/stackwalk.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/handles.hpp
! src/hotspot/share/runtime/jniHandles.inline.hpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/vframe.cpp
! src/hotspot/share/services/memoryManager.hpp
! src/hotspot/share/services/memoryPool.hpp
! src/hotspot/share/services/threadService.cpp
! src/hotspot/share/utilities/exceptions.cpp
! src/hotspot/share/utilities/growableArray.hpp

Changeset: bb1aaed00341
Author:    pliden
Date:      2019-09-17 09:51 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/bb1aaed00341

8231051: Remove check_obj_alignment() and replace with is_object_aligned()
Reviewed-by: tschatzl, shade

! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/memory/heapShared.inline.hpp
! src/hotspot/share/oops/compressedOops.inline.hpp
! src/hotspot/share/oops/oopsHierarchy.hpp

Changeset: 8ee083465318
Author:    coffeys
Date:      2019-09-17 11:07 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/8ee083465318

8223490: Optimize search algorithm for determining default time zone
Reviewed-by: naoto, rriggs

! src/java.base/unix/native/libjava/TimeZone_md.c

Changeset: 2f301425af62
Author:    jiefu
Date:      2019-09-17 20:38 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/2f301425af62

8230943: False deadlock detection with -XX:+CIPrintCompileQueue after JDK-8163511
Reviewed-by: dholmes, thartmann

! src/hotspot/share/compiler/compileBroker.cpp
+ test/hotspot/jtreg/compiler/print/PrintCompileQueue.java

Changeset: 9adf95692a3d
Author:    zgu
Date:      2019-09-17 08:22 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/9adf95692a3d

8230350: Shenandoah: Assertion failed when GC is cancelled by a worker thread
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 8a8e87e8a4fd
Author:    coffeys
Date:      2019-09-17 16:39 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/8a8e87e8a4fd

8231124: Missing closedir call with JDK-8223490
Reviewed-by: naoto

! src/java.base/unix/native/libjava/TimeZone_md.c

Changeset: 6a05019acb67
Author:    lancea
Date:      2019-09-17 14:00 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/6a05019acb67

8230870: (zipfs) Add a ZIP FS test that is similar to test/jdk/java/util/zip/EntryCount64k.java
Reviewed-by: clanger, martin

+ test/jdk/jdk/nio/zipfs/LargeEntriesTest.java

Changeset: a82fe7a88ce4
Author:    jiefu
Date:      2019-09-17 09:20 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/a82fe7a88ce4

8231024: Improve the debug info when the output is truncated
Reviewed-by: iklam, dholmes

! src/hotspot/share/utilities/ostream.cpp

Changeset: cea6839598e8
Author:    dholmes
Date:      2019-09-17 19:09 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/cea6839598e8

8230424: Use platform independent code for Thread.interrupt support
8231094: os::sleep in assert message should be changed to JavaThread::sleep
Reviewed-by: rehn, dcubed

! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/solaris/os_solaris.cpp
! src/hotspot/os/windows/osThread_windows.cpp
! src/hotspot/os/windows/osThread_windows.hpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/jvmtiRawMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/osThread.cpp
! src/hotspot/share/runtime/osThread.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: c46407f651a9
Author:    serb
Date:      2019-09-17 19:52 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/c46407f651a9

8231027: Correct typos
Reviewed-by: lancea, dholmes, erikj

! make/autoconf/buildjdk-spec.gmk.in
! make/autoconf/spec.gmk.in
! src/hotspot/share/opto/block.hpp
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java
! src/java.xml/share/classes/com/sun/xml/internal/stream/StaxXMLInputSource.java
! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/BignumDtoa.java
! test/jdk/java/awt/GradientPaint/LinearColorSpaceGradientTest.java
! test/jdk/java/awt/Graphics2D/DrawString/XRenderElt254TextTest.java
! test/jdk/java/nio/channels/Selector/WakeupSpeed.java
! test/jdk/java/text/Format/DecimalFormat/FormatMicroBenchmark.java

Changeset: a45cce906207
Author:    mbaesken
Date:      2019-07-23 16:52 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/a45cce906207

8228482: fix xlc16/xlclang comparison of distinct pointer types and string literal conversion warnings
Reviewed-by: clanger, mdoerr

! src/hotspot/os/aix/libodm_aix.cpp
! src/hotspot/os/aix/libodm_aix.hpp
! src/hotspot/os/aix/os_aix.cpp
! src/java.base/aix/native/libjli/java_md_aix.c
! src/java.base/unix/native/libnet/NetworkInterface.c
! src/java.desktop/aix/native/libawt/porting_aix.c

Changeset: dfd434203aa0
Author:    jlahoda
Date:      2019-09-18 10:41 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/dfd434203aa0

8228460: bootstrap class path not set in conjunction with -source 11
Summary: Ensuring implicit system module path is checked for the no-bootclasspath warning for -source >= 9.
Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/javac/diags/examples/SourceNoSystemModulesPath.java
+ test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java
! test/langtools/tools/javac/var_implicit_lambda/VarInImplicitLambdaNegTest01_source10.out

Changeset: 0f3c23c374a4
Author:    phh
Date:      2019-09-18 05:41 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/0f3c23c374a4

8207266: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
Summary: Add com.sun.management.getCurrentThreadAllocatedBytes, implement getThreadAllocatedBytes(long) independent of getThreadAllocatedBytes(long[])
Reviewed-by: mchung, dholmes, sspitsyn

! src/hotspot/share/include/jmm.h
! src/hotspot/share/services/management.cpp
! src/java.management/share/classes/java/lang/management/ThreadMXBean.java
! src/java.management/share/classes/sun/management/ThreadImpl.java
! src/java.management/share/native/libmanagement/ThreadImpl.c
! src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java
! src/jdk.management/share/classes/com/sun/management/internal/HotSpotThreadImpl.java
! test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java

Changeset: 377f47ccc20b
Author:    jlahoda
Date:      2019-09-18 15:13 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/377f47ccc20b

8231176: Test tools/javac/options/BCPOrSystemNotSpecified.java broken on Windows
Summary: Temporarily disabling BCPOrSystemNotSpecified.java test on Windows.
Reviewed-by: vromero

! test/langtools/ProblemList.txt

Changeset: 8c44ac2a908e
Author:    epavlova
Date:      2019-09-18 10:58 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/8c44ac2a908e

8231145: [Graal] org.graalvm.compiler.debug.test.DebugContextTest fails because DebugContextTest.testLogging.input is not available
Reviewed-by: erikj, iveresov, ihse

! make/test/JtregGraalUnit.gmk
! test/hotspot/jtreg/ProblemList-graal.txt

Changeset: 0368f3a073a9
Author:    jwilhelm
Date:      2019-09-06 17:50 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/0368f3a073a9

Added tag jdk-13-ga for changeset 9c250a7600e1

! .hgtags

Changeset: f43c809a27bd
Author:    jwilhelm
Date:      2019-09-18 11:48 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/f43c809a27bd

Merge

! .hgtags

Changeset: b1a394e15ae9
Author:    rkennke
Date:      2019-09-18 20:56 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/b1a394e15ae9

8231085: C2/GC: Better GC-interface for expanding clone
Reviewed-by: eosterlund

! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp
! src/hotspot/share/opto/macro.hpp
! src/hotspot/share/opto/macroArrayCopy.cpp

Changeset: 0d7877278adf
Author:    rkennke
Date:      2019-09-18 20:56 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/0d7877278adf

8231086: Shenandoah: Stronger invariant for object-arraycopy
Reviewed-by: shade

! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp

Changeset: bc0648405d67
Author:    rkennke
Date:      2019-09-18 20:56 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/bc0648405d67

8231087: Shenandoah: Self-fixing load reference barriers for C1/C2
Reviewed-by: shade

! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: 2c4185d7276a
Author:    amenkov
Date:      2019-09-18 12:13 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/2c4185d7276a

8186825: some memory leak issues in the transport_startTransport
Reviewed-by: sspitsyn, phh

! src/jdk.jdwp.agent/share/native/libjdwp/transport.c

Changeset: b73753eff8b7
Author:    godin
Date:      2019-09-18 21:20 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/b73753eff8b7

8066774: Rename the annotations arrays names in ClassFileParser
Reviewed-by: shade, coleenp, dholmes
Contributed-by: Evgeny Mandrikov <mandrikov at gmail.com>

! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp

Changeset: ee37c9b2eb61
Author:    dholmes
Date:      2019-09-18 17:31 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/ee37c9b2eb61

8231162: JVMTI RawMonitorWait triggers assertion failure: Only JavaThreads can be interruptible
Reviewed-by: dcubed

! src/hotspot/share/prims/jvmtiEnv.cpp


From maurizio.cimadamore at oracle.com  Wed Sep 18 22:09:03 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 18 Sep 2019 22:09:03 +0000
Subject: hg: panama/dev: Automatic merge with default
Message-ID: <201909182209.x8IM93QG014288@aojmv0008.oracle.com>

Changeset: 3918e659002d
Author:    mcimadamore
Date:      2019-09-18 22:08 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/3918e659002d

Automatic merge with default

! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
- src/hotspot/share/gc/z/zUtils.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp
- src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp
- src/hotspot/share/oops/access.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/unsafe.cpp


From maurizio.cimadamore at oracle.com  Wed Sep 18 22:09:28 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 18 Sep 2019 22:09:28 +0000
Subject: hg: panama/dev: Automatic merge with default
Message-ID: <201909182209.x8IM9S6C014793@aojmv0008.oracle.com>

Changeset: ffaaba2094d1
Author:    mcimadamore
Date:      2019-09-18 22:09 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/ffaaba2094d1

Automatic merge with default

! make/autoconf/spec.gmk.in
- src/hotspot/share/gc/z/zUtils.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp
- src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp
- src/hotspot/share/oops/access.cpp


From maurizio.cimadamore at oracle.com  Wed Sep 18 22:09:51 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 18 Sep 2019 22:09:51 +0000
Subject: hg: panama/dev: Automatic merge with default
Message-ID: <201909182209.x8IM9pAA015331@aojmv0008.oracle.com>

Changeset: 6925f04b6463
Author:    mcimadamore
Date:      2019-09-18 22:09 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/6925f04b6463

Automatic merge with default

- src/hotspot/share/gc/z/zUtils.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp
- src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp
- src/hotspot/share/oops/access.cpp


From maurizio.cimadamore at oracle.com  Wed Sep 18 22:10:19 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 18 Sep 2019 22:10:19 +0000
Subject: hg: panama/dev: Automatic merge with foreign
Message-ID: <201909182210.x8IMAJ0O015857@aojmv0008.oracle.com>

Changeset: 128037e5dc6a
Author:    mcimadamore
Date:      2019-09-18 22:10 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/128037e5dc6a

Automatic merge with foreign

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
- src/hotspot/share/gc/z/zUtils.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp
- src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp
- src/hotspot/share/oops/access.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/runtime/thread.hpp


From maurizio.cimadamore at oracle.com  Wed Sep 18 22:10:41 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 18 Sep 2019 22:10:41 +0000
Subject: hg: panama/dev: Automatic merge with linkToNative
Message-ID: <201909182210.x8IMAgxi016179@aojmv0008.oracle.com>

Changeset: 65d2c5d603fb
Author:    mcimadamore
Date:      2019-09-18 22:10 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/65d2c5d603fb

Automatic merge with linkToNative



From maurizio.cimadamore at oracle.com  Wed Sep 18 22:11:04 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 18 Sep 2019 22:11:04 +0000
Subject: hg: panama/dev: Automatic merge with foreign-memaccess
Message-ID: <201909182211.x8IMB4ua016662@aojmv0008.oracle.com>

Changeset: 469c7ea4a0dc
Author:    mcimadamore
Date:      2019-09-18 22:10 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/469c7ea4a0dc

Automatic merge with foreign-memaccess

- src/hotspot/share/gc/z/zUtils.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp
- src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp
- src/hotspot/share/oops/access.cpp


From jorn.vernee at oracle.com  Mon Sep 23 11:43:30 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Mon, 23 Sep 2019 13:43:30 +0200
Subject: [foreign-abi] On invokers
Message-ID: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>

Hi,

I've been looking into the current set of invokers we have on the 
foreign-abi branch for the past few weeks. There is still work to be 
done in this area, both in terms of performance, and in terms of 
programmability. In this email I will focus on the latter.

The UniversalNativeInvoker (UNI) API is currently the most programmble 
invoker that we have, so if we want to increase the programmability of 
our backend to cover more and more ABIs, this seems like a good place to 
start. UNI goes a ways in being programmable with the CallingSequence, 
ShuffleRecipe and ArgumentBinding APIs, being able to select in which 
registers to pass values, but there are still some aspects that could be 
polished:

1.) If you look into the VM code that processes the shuffle recipe, 
you'll notice that the eventual argument buffer that's being fed to the 
stub has a fixed set of registers it can work with on a given platform 
[1], namely the ones that are used by the C ABI. This works when we have 
only one ABI (C), but for different ABIs we'd probably want a different 
set of registers. We can change the stub generation code to take an 
'ABIDescriptor' from which we derive the stub and argument buffer layout 
instead. This will also provide a place to put other ABI details that 
need to be customized, like stack alignment, and argument shadow space 
(Windows), as well as a set of volatile registers, which will be a super 
set of the argument registers. We would end up generating 1 generic 
downcall stub for each ABI. Also, note that we would need to create 
architecture definitions on the Java side to be able to specify the 
ABIDescriptors there (since ABIs are defined in terms of architecture).

2.) There is a need to pass meta arguments to a function sometimes. For 
instance, we need to pass in a pointer to a return buffer for 
in-memory-returns, and e.g. on SysV we need to pass in the number of 
float arguments in RAX (or rather AL) for variadic functions. The former 
is handled automatically by CallingSequenceBuilder, and the latter is 
hard-coded in the VM code. Since these are both ABI details, I believe 
they should be handled by the ABI implementations. Ideally we'd have an 
invoker API that let's us say: "add a Java argument with this carrier 
type, and this MemoryLayout, and then shuffle it into this register.", 
and then the ABI implementation can handle the further adaptation from 
the ABI-level signature (e.g. an additional MemoryAddress passed in as 
first argument), to the C-level signature (allocate a buffer as first 
argument and also return it). This is mostly a refactoring move in 
UNI::invoke and CallingSequenceBuilder that removes the handling for in 
memory returns, and replaces it with a more general way of passing those 
kinds of arguments.

3.) The unboxing/boxing is currently handled by calling into the various 
ABI implementations. We can make this code shared by extending the 
current ArgumentBinding 'recipe' to include other operations, besides 
moving from a pointer to a register, that cover the things that are 
currently handled by the ABI boxing/unboxing implementations. The 
various CallingSequenceBuilder implementations can then specify these 
additional binding operations when generating bindings. This means that 
we only need one shared piece of code that interprets this 'binding 
recipe'. The other advantage of doing this is that we would eventually 
be able to use these binding recipes + ABIDescriptor to generate a 
specialized stub for a particular call site.

4.) We are currently shuffling the arguments for a down call into a 
long[], and then in the VM we shuffle the arguments from the long[] into 
an argument buffer (ShuffleDowncallContext). We can merge these steps 
together, by directly shuffling the arguments into an argument buffer on 
the Java side (since we have an off-heap API). This decreases the 
overall complexity of the invoker implementation significantly, since we 
can drop all the code relating to shuffle recipes.

I've been experimenting with these ideas, and have a prototype for 
downcalls on Windows [2]. For this I copied the relevant UNI classes to 
a separate `programmable` package and made the relevant changes there, 
since some of the code was shared with UniversalUpcallHandler. I've also 
preemptively removed the old UNI code (for x86) to show roughly how much 
code would be removed by switching to the new invoker API. I want to 
continue the experiment for upcalls as well, after which more old code 
could be removed; namely Argument, ArgumentBinding, CallingSequence 
(old), CallingSeqeunceBuilder (old), Storage, StorageClass, SharedUtils 
(mostly) and UniversalAdapter.

How do these ideas sound? I'm mostly interested if this is flexible 
enough to support AArch64 and SysV. After the upcall support, I can look 
into porting the other 2 ABIs as well.

Thanks,
Jorn

[1] : 
https://github.com/openjdk/panama/blob/foreign-abi/src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp#L73
[2] : 
https://github.com/openjdk/panama/compare/foreign-abi...JornVernee:prog-back-no-old


From jorn.vernee at oracle.com  Mon Sep 23 12:32:08 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Mon, 23 Sep 2019 14:32:08 +0200
Subject: [foreign-abi] On invokers
In-Reply-To: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
Message-ID: <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>

Here is a webrev version of the changes as well: 
http://cr.openjdk.java.net/~jvernee/prog-back/webrev.00/

Jorn

On 23/09/2019 13:43, Jorn Vernee wrote:
> Hi,
>
> I've been looking into the current set of invokers we have on the 
> foreign-abi branch for the past few weeks. There is still work to be 
> done in this area, both in terms of performance, and in terms of 
> programmability. In this email I will focus on the latter.
>
> The UniversalNativeInvoker (UNI) API is currently the most programmble 
> invoker that we have, so if we want to increase the programmability of 
> our backend to cover more and more ABIs, this seems like a good place 
> to start. UNI goes a ways in being programmable with the 
> CallingSequence, ShuffleRecipe and ArgumentBinding APIs, being able to 
> select in which registers to pass values, but there are still some 
> aspects that could be polished:
>
> 1.) If you look into the VM code that processes the shuffle recipe, 
> you'll notice that the eventual argument buffer that's being fed to 
> the stub has a fixed set of registers it can work with on a given 
> platform [1], namely the ones that are used by the C ABI. This works 
> when we have only one ABI (C), but for different ABIs we'd probably 
> want a different set of registers. We can change the stub generation 
> code to take an 'ABIDescriptor' from which we derive the stub and 
> argument buffer layout instead. This will also provide a place to put 
> other ABI details that need to be customized, like stack alignment, 
> and argument shadow space (Windows), as well as a set of volatile 
> registers, which will be a super set of the argument registers. We 
> would end up generating 1 generic downcall stub for each ABI. Also, 
> note that we would need to create architecture definitions on the Java 
> side to be able to specify the ABIDescriptors there (since ABIs are 
> defined in terms of architecture).
>
> 2.) There is a need to pass meta arguments to a function sometimes. 
> For instance, we need to pass in a pointer to a return buffer for 
> in-memory-returns, and e.g. on SysV we need to pass in the number of 
> float arguments in RAX (or rather AL) for variadic functions. The 
> former is handled automatically by CallingSequenceBuilder, and the 
> latter is hard-coded in the VM code. Since these are both ABI details, 
> I believe they should be handled by the ABI implementations. Ideally 
> we'd have an invoker API that let's us say: "add a Java argument with 
> this carrier type, and this MemoryLayout, and then shuffle it into 
> this register.", and then the ABI implementation can handle the 
> further adaptation from the ABI-level signature (e.g. an additional 
> MemoryAddress passed in as first argument), to the C-level signature 
> (allocate a buffer as first argument and also return it). This is 
> mostly a refactoring move in UNI::invoke and CallingSequenceBuilder 
> that removes the handling for in memory returns, and replaces it with 
> a more general way of passing those kinds of arguments.
>
> 3.) The unboxing/boxing is currently handled by calling into the 
> various ABI implementations. We can make this code shared by extending 
> the current ArgumentBinding 'recipe' to include other operations, 
> besides moving from a pointer to a register, that cover the things 
> that are currently handled by the ABI boxing/unboxing implementations. 
> The various CallingSequenceBuilder implementations can then specify 
> these additional binding operations when generating bindings. This 
> means that we only need one shared piece of code that interprets this 
> 'binding recipe'. The other advantage of doing this is that we would 
> eventually be able to use these binding recipes + ABIDescriptor to 
> generate a specialized stub for a particular call site.
>
> 4.) We are currently shuffling the arguments for a down call into a 
> long[], and then in the VM we shuffle the arguments from the long[] 
> into an argument buffer (ShuffleDowncallContext). We can merge these 
> steps together, by directly shuffling the arguments into an argument 
> buffer on the Java side (since we have an off-heap API). This 
> decreases the overall complexity of the invoker implementation 
> significantly, since we can drop all the code relating to shuffle 
> recipes.
>
> I've been experimenting with these ideas, and have a prototype for 
> downcalls on Windows [2]. For this I copied the relevant UNI classes 
> to a separate `programmable` package and made the relevant changes 
> there, since some of the code was shared with UniversalUpcallHandler. 
> I've also preemptively removed the old UNI code (for x86) to show 
> roughly how much code would be removed by switching to the new invoker 
> API. I want to continue the experiment for upcalls as well, after 
> which more old code could be removed; namely Argument, 
> ArgumentBinding, CallingSequence (old), CallingSeqeunceBuilder (old), 
> Storage, StorageClass, SharedUtils (mostly) and UniversalAdapter.
>
> How do these ideas sound? I'm mostly interested if this is flexible 
> enough to support AArch64 and SysV. After the upcall support, I can 
> look into porting the other 2 ABIs as well.
>
> Thanks,
> Jorn
>
> [1] : 
> https://github.com/openjdk/panama/blob/foreign-abi/src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp#L73
> [2] : 
> https://github.com/openjdk/panama/compare/foreign-abi...JornVernee:prog-back-no-old
>

From shravya.rukmannagari at intel.com  Mon Sep 23 18:48:24 2019
From: shravya.rukmannagari at intel.com (shravya.rukmannagari at intel.com)
Date: Mon, 23 Sep 2019 18:48:24 +0000
Subject: hg: panama/dev: Generic Operands Support for VectorBlend
Message-ID: <201909231848.x8NImOwk029797@aojmv0008.oracle.com>

Changeset: bd924d3f0f79
Author:    srukmannagar
Date:      2019-09-23 03:17 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/bd924d3f0f79

Generic Operands Support for VectorBlend

! src/hotspot/cpu/x86/x86.ad


From maurizio.cimadamore at oracle.com  Mon Sep 23 20:56:23 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 23 Sep 2019 21:56:23 +0100
Subject: [foreign-abi] On invokers
In-Reply-To: <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
Message-ID: <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>

Hi Jorn,
this is a very solid piece of work, and I like how it makes it a lot 
saner to reason about what's going on in the universal invoker - the 
entire logic is now more scrutable, so well done!

I think that, in order to understand better how things are glued, I'd 
like to try to port SysV and see how that goes; from that perspective, I 
think it's not immediately clear which parts of the Java code are meant 
to be truly reusable across ABIs/platforms and which one are fixed.

For instance: the ABIDescriptor class looks very general - and it is 
probably enough to cover the ABIs we have now. But, in a way, I see with 
it the same problems I see in the current universal invoker - that is, 
the ABIDescriptor class has to be an 'union' of all the things used in 
all possible ABIs. That is, a descriptor has to have input storage, 
output storage, (arguably very general) then more exotic info such as 
shadow space etc. The fact that - e.g. when using SysV we'd be forced to 
use an ABIDescriptor that speaks about 'shadow space' (ok we can set it 
to zero, no big deal) feels wrong in a way, for all the same reason as 
to why it was wrong in the old universal invoker to speak about x87 
registers (which are pretty SysV specific).

Let's imagine to add a very weird ABI which requires a more complex 
stack alignment scheme (e.g. stack alignment not constant across all 
args). How would we encode such an hypothetical ABI using the classes 
provided? Am I right that it would not be possible to do that using the 
out of the box ABIDescriptor, but that we would have to extend the 
ABIDescriptor to cover the requirements of the exotic ABI (e.g. have an 
extra array for the alignments for each arguments), and then leave those 
bits unused in most cases.

The same goes, I think, for the set of operation supported by bindings 
and the binding interpreter, which are, I think, supposed to be shared 
across ABIs/platform. For now we have moves, buffer copy - which are, 
again, probably ok to cover the waterfront (especially since moves 
involve arbitrary VM storage, which makes them quite flexible and 
general); at the same time if a new operation is required by some exotic 
API (e.g. set overflow flag), maybe we need to add a new binding - which 
would mean updating the single shared binding interpreter (and then 
maybe start thinking about which interaction the new binding operation 
could have with the existing ones, even though, maybe some combinations 
are not even possible, by ABI design).

In other words, while I can see this being much more general and 
maintainable than what we have now, I'm not sure I would still call it 
"pluggable" or "programmable", if you get what I'm saying. That is, at 
the end of the day the capability of ProgrammableInvoker are fixed by 
two factors: (i) the ABI descriptor (which seems fixed) and (ii) the set 
of supported binding operations (again fixed). So, even assuming we had 
an ultra-low-level API to allow an advanced developer to define his/her 
own ABI, I could still see ways in which certain ABIs could not be 
modeled w/o going deeper into the API internals (e.g. tweak ABI 
descriptor or bindings) or the VM.

And that's ok - as long as we're honest about the goal here: we're not 
after a single API to rule'em'all (which I think, as attractive as it 
is, it might be a siren song) - we're after a way to put some method 
into the ABI madness, so that less work will be required when new ABIs 
will need to be defined.

Or, did I take a wrong turn somewhere when going through the code?

Maurizio


On 23/09/2019 13:32, Jorn Vernee wrote:
> Here is a webrev version of the changes as well: 
> http://cr.openjdk.java.net/~jvernee/prog-back/webrev.00/
>
> Jorn
>
> On 23/09/2019 13:43, Jorn Vernee wrote:
>> Hi,
>>
>> I've been looking into the current set of invokers we have on the 
>> foreign-abi branch for the past few weeks. There is still work to be 
>> done in this area, both in terms of performance, and in terms of 
>> programmability. In this email I will focus on the latter.
>>
>> The UniversalNativeInvoker (UNI) API is currently the most 
>> programmble invoker that we have, so if we want to increase the 
>> programmability of our backend to cover more and more ABIs, this 
>> seems like a good place to start. UNI goes a ways in being 
>> programmable with the CallingSequence, ShuffleRecipe and 
>> ArgumentBinding APIs, being able to select in which registers to pass 
>> values, but there are still some aspects that could be polished:
>>
>> 1.) If you look into the VM code that processes the shuffle recipe, 
>> you'll notice that the eventual argument buffer that's being fed to 
>> the stub has a fixed set of registers it can work with on a given 
>> platform [1], namely the ones that are used by the C ABI. This works 
>> when we have only one ABI (C), but for different ABIs we'd probably 
>> want a different set of registers. We can change the stub generation 
>> code to take an 'ABIDescriptor' from which we derive the stub and 
>> argument buffer layout instead. This will also provide a place to put 
>> other ABI details that need to be customized, like stack alignment, 
>> and argument shadow space (Windows), as well as a set of volatile 
>> registers, which will be a super set of the argument registers. We 
>> would end up generating 1 generic downcall stub for each ABI. Also, 
>> note that we would need to create architecture definitions on the 
>> Java side to be able to specify the ABIDescriptors there (since ABIs 
>> are defined in terms of architecture).
>>
>> 2.) There is a need to pass meta arguments to a function sometimes. 
>> For instance, we need to pass in a pointer to a return buffer for 
>> in-memory-returns, and e.g. on SysV we need to pass in the number of 
>> float arguments in RAX (or rather AL) for variadic functions. The 
>> former is handled automatically by CallingSequenceBuilder, and the 
>> latter is hard-coded in the VM code. Since these are both ABI 
>> details, I believe they should be handled by the ABI implementations. 
>> Ideally we'd have an invoker API that let's us say: "add a Java 
>> argument with this carrier type, and this MemoryLayout, and then 
>> shuffle it into this register.", and then the ABI implementation can 
>> handle the further adaptation from the ABI-level signature (e.g. an 
>> additional MemoryAddress passed in as first argument), to the C-level 
>> signature (allocate a buffer as first argument and also return it). 
>> This is mostly a refactoring move in UNI::invoke and 
>> CallingSequenceBuilder that removes the handling for in memory 
>> returns, and replaces it with a more general way of passing those 
>> kinds of arguments.
>>
>> 3.) The unboxing/boxing is currently handled by calling into the 
>> various ABI implementations. We can make this code shared by 
>> extending the current ArgumentBinding 'recipe' to include other 
>> operations, besides moving from a pointer to a register, that cover 
>> the things that are currently handled by the ABI boxing/unboxing 
>> implementations. The various CallingSequenceBuilder implementations 
>> can then specify these additional binding operations when generating 
>> bindings. This means that we only need one shared piece of code that 
>> interprets this 'binding recipe'. The other advantage of doing this 
>> is that we would eventually be able to use these binding recipes + 
>> ABIDescriptor to generate a specialized stub for a particular call site.
>>
>> 4.) We are currently shuffling the arguments for a down call into a 
>> long[], and then in the VM we shuffle the arguments from the long[] 
>> into an argument buffer (ShuffleDowncallContext). We can merge these 
>> steps together, by directly shuffling the arguments into an argument 
>> buffer on the Java side (since we have an off-heap API). This 
>> decreases the overall complexity of the invoker implementation 
>> significantly, since we can drop all the code relating to shuffle 
>> recipes.
>>
>> I've been experimenting with these ideas, and have a prototype for 
>> downcalls on Windows [2]. For this I copied the relevant UNI classes 
>> to a separate `programmable` package and made the relevant changes 
>> there, since some of the code was shared with UniversalUpcallHandler. 
>> I've also preemptively removed the old UNI code (for x86) to show 
>> roughly how much code would be removed by switching to the new 
>> invoker API. I want to continue the experiment for upcalls as well, 
>> after which more old code could be removed; namely Argument, 
>> ArgumentBinding, CallingSequence (old), CallingSeqeunceBuilder (old), 
>> Storage, StorageClass, SharedUtils (mostly) and UniversalAdapter.
>>
>> How do these ideas sound? I'm mostly interested if this is flexible 
>> enough to support AArch64 and SysV. After the upcall support, I can 
>> look into porting the other 2 ABIs as well.
>>
>> Thanks,
>> Jorn
>>
>> [1] : 
>> https://github.com/openjdk/panama/blob/foreign-abi/src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp#L73
>> [2] : 
>> https://github.com/openjdk/panama/compare/foreign-abi...JornVernee:prog-back-no-old
>>

From shravya.rukmannagari at intel.com  Mon Sep 23 21:11:41 2019
From: shravya.rukmannagari at intel.com (shravya.rukmannagari at intel.com)
Date: Mon, 23 Sep 2019 21:11:41 +0000
Subject: hg: panama/dev: Generic Operands Support for VectorLoad
Message-ID: <201909232111.x8NLBg63000964@aojmv0008.oracle.com>

Changeset: 6927d99bb780
Author:    srukmannagar
Date:      2019-09-23 05:38 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/6927d99bb780

Generic Operands Support for VectorLoad

! src/hotspot/cpu/x86/x86.ad


From jorn.vernee at oracle.com  Tue Sep 24 09:42:26 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 24 Sep 2019 11:42:26 +0200
Subject: [foreign-abi] On invokers
In-Reply-To: <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
Message-ID: <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>

Yes, you're right that this is not the ultimate solution. It's 
'programmable' in the sense that what was previously hard-coded inside 
the VM code is now passed in dynamically from Java through the API, and 
defined by a particular ABIDescriptor.

These changes are meant to clean up some of the existing technological 
debt we have in the UNI API. The 'programmability' is merely improved to 
be able to describe the quirks in the existing ABIs using more general, 
and hopefully broadly applicable concepts.

I noticed that there is a mismatch between a C-level function descriptor 
and an ABI-level function descriptor, for instance in the case of 
meta-arguments. The current problem is that we give an un-altered 
descriptor to UNI to work with, and then expect the invoker to work out 
the mapping to an ABI-level call, which is inherently ABI-specific. This 
patch adds another layer in between; it's the job of the ABI 
implementation to adapt from the C-level descriptor to the ABI-level 
descriptor. We need to extend the invoker API to provided the right 
primitives for the ABI impl to do that. The API supports creating a 
MethodHandle for an ABI-level call, which is then adapted to C-level by 
the particular ABI impl.

If more programmability is needed in the future this can be added. As 
you say, likely in the areas of Bindings and ABIDescriptor + stub 
generation :). This is just intended to be the next iteration in the 
process.

If you want to do a SysV port that would be much appreciated :). In 
principle everything in the `programmable` package, except for 
CallArranger is a part of the API, though there should be no need to 
interact directly with BindingInterpreter and BufferLayout. So, if you 
want to do a port the only thing you should have to do is add a SysV 
version of CallArranger, (which I based on CallingSequenceBuilderImpl, 
so that's probably a good place to start) and then call that from 
SysVx64ABI.

The things to do are;

1.) Create a SysV ABIDescriptor instance (make sure to add RAX as an 
input storage). The x86_64Architecture class has the `abiFor` method to 
do this

2.) Add a method that takes a C-level FunctionDescriptor + MethodType 
and creates an ABI-level MethodHandle for this using the invoker API, 
and then adapts this back to a C-level MethodHandle. You have to add 
meta-arguments manually (see CallArranger::arrangeDowncall for an 
example with in-memory return).

3.) When generating bindings, map storage indices to VMStorage instances 
using the ABIDescriptor instance you created + StorageClasses defined in 
x86_64Architecture (to get the right VMStorage[] index).

4.) Add additional needed Binding operations when generating the 
bindings, to replace things handled by the box-/unbox-Value methods 
(this was needed for Windows, but maybe not for SysV).

Cheers,
Jorn

On 23/09/2019 22:56, Maurizio Cimadamore wrote:
> Hi Jorn,
> this is a very solid piece of work, and I like how it makes it a lot 
> saner to reason about what's going on in the universal invoker - the 
> entire logic is now more scrutable, so well done!
>
> I think that, in order to understand better how things are glued, I'd 
> like to try to port SysV and see how that goes; from that perspective, 
> I think it's not immediately clear which parts of the Java code are 
> meant to be truly reusable across ABIs/platforms and which one are fixed.
>
> For instance: the ABIDescriptor class looks very general - and it is 
> probably enough to cover the ABIs we have now. But, in a way, I see 
> with it the same problems I see in the current universal invoker - 
> that is, the ABIDescriptor class has to be an 'union' of all the 
> things used in all possible ABIs. That is, a descriptor has to have 
> input storage, output storage, (arguably very general) then more 
> exotic info such as shadow space etc. The fact that - e.g. when using 
> SysV we'd be forced to use an ABIDescriptor that speaks about 'shadow 
> space' (ok we can set it to zero, no big deal) feels wrong in a way, 
> for all the same reason as to why it was wrong in the old universal 
> invoker to speak about x87 registers (which are pretty SysV specific).
>
> Let's imagine to add a very weird ABI which requires a more complex 
> stack alignment scheme (e.g. stack alignment not constant across all 
> args). How would we encode such an hypothetical ABI using the classes 
> provided? Am I right that it would not be possible to do that using 
> the out of the box ABIDescriptor, but that we would have to extend the 
> ABIDescriptor to cover the requirements of the exotic ABI (e.g. have 
> an extra array for the alignments for each arguments), and then leave 
> those bits unused in most cases.
>
> The same goes, I think, for the set of operation supported by bindings 
> and the binding interpreter, which are, I think, supposed to be shared 
> across ABIs/platform. For now we have moves, buffer copy - which are, 
> again, probably ok to cover the waterfront (especially since moves 
> involve arbitrary VM storage, which makes them quite flexible and 
> general); at the same time if a new operation is required by some 
> exotic API (e.g. set overflow flag), maybe we need to add a new 
> binding - which would mean updating the single shared binding 
> interpreter (and then maybe start thinking about which interaction the 
> new binding operation could have with the existing ones, even though, 
> maybe some combinations are not even possible, by ABI design).
>
> In other words, while I can see this being much more general and 
> maintainable than what we have now, I'm not sure I would still call it 
> "pluggable" or "programmable", if you get what I'm saying. That is, at 
> the end of the day the capability of ProgrammableInvoker are fixed by 
> two factors: (i) the ABI descriptor (which seems fixed) and (ii) the 
> set of supported binding operations (again fixed). So, even assuming 
> we had an ultra-low-level API to allow an advanced developer to define 
> his/her own ABI, I could still see ways in which certain ABIs could 
> not be modeled w/o going deeper into the API internals (e.g. tweak ABI 
> descriptor or bindings) or the VM.
>
> And that's ok - as long as we're honest about the goal here: we're not 
> after a single API to rule'em'all (which I think, as attractive as it 
> is, it might be a siren song) - we're after a way to put some method 
> into the ABI madness, so that less work will be required when new ABIs 
> will need to be defined.
>
> Or, did I take a wrong turn somewhere when going through the code?
>
> Maurizio
>
>
> On 23/09/2019 13:32, Jorn Vernee wrote:
>> Here is a webrev version of the changes as well: 
>> http://cr.openjdk.java.net/~jvernee/prog-back/webrev.00/
>>
>> Jorn
>>
>> On 23/09/2019 13:43, Jorn Vernee wrote:
>>> Hi,
>>>
>>> I've been looking into the current set of invokers we have on the 
>>> foreign-abi branch for the past few weeks. There is still work to be 
>>> done in this area, both in terms of performance, and in terms of 
>>> programmability. In this email I will focus on the latter.
>>>
>>> The UniversalNativeInvoker (UNI) API is currently the most 
>>> programmble invoker that we have, so if we want to increase the 
>>> programmability of our backend to cover more and more ABIs, this 
>>> seems like a good place to start. UNI goes a ways in being 
>>> programmable with the CallingSequence, ShuffleRecipe and 
>>> ArgumentBinding APIs, being able to select in which registers to 
>>> pass values, but there are still some aspects that could be polished:
>>>
>>> 1.) If you look into the VM code that processes the shuffle recipe, 
>>> you'll notice that the eventual argument buffer that's being fed to 
>>> the stub has a fixed set of registers it can work with on a given 
>>> platform [1], namely the ones that are used by the C ABI. This works 
>>> when we have only one ABI (C), but for different ABIs we'd probably 
>>> want a different set of registers. We can change the stub generation 
>>> code to take an 'ABIDescriptor' from which we derive the stub and 
>>> argument buffer layout instead. This will also provide a place to 
>>> put other ABI details that need to be customized, like stack 
>>> alignment, and argument shadow space (Windows), as well as a set of 
>>> volatile registers, which will be a super set of the argument 
>>> registers. We would end up generating 1 generic downcall stub for 
>>> each ABI. Also, note that we would need to create architecture 
>>> definitions on the Java side to be able to specify the 
>>> ABIDescriptors there (since ABIs are defined in terms of architecture).
>>>
>>> 2.) There is a need to pass meta arguments to a function sometimes. 
>>> For instance, we need to pass in a pointer to a return buffer for 
>>> in-memory-returns, and e.g. on SysV we need to pass in the number of 
>>> float arguments in RAX (or rather AL) for variadic functions. The 
>>> former is handled automatically by CallingSequenceBuilder, and the 
>>> latter is hard-coded in the VM code. Since these are both ABI 
>>> details, I believe they should be handled by the ABI 
>>> implementations. Ideally we'd have an invoker API that let's us say: 
>>> "add a Java argument with this carrier type, and this MemoryLayout, 
>>> and then shuffle it into this register.", and then the ABI 
>>> implementation can handle the further adaptation from the ABI-level 
>>> signature (e.g. an additional MemoryAddress passed in as first 
>>> argument), to the C-level signature (allocate a buffer as first 
>>> argument and also return it). This is mostly a refactoring move in 
>>> UNI::invoke and CallingSequenceBuilder that removes the handling for 
>>> in memory returns, and replaces it with a more general way of 
>>> passing those kinds of arguments.
>>>
>>> 3.) The unboxing/boxing is currently handled by calling into the 
>>> various ABI implementations. We can make this code shared by 
>>> extending the current ArgumentBinding 'recipe' to include other 
>>> operations, besides moving from a pointer to a register, that cover 
>>> the things that are currently handled by the ABI boxing/unboxing 
>>> implementations. The various CallingSequenceBuilder implementations 
>>> can then specify these additional binding operations when generating 
>>> bindings. This means that we only need one shared piece of code that 
>>> interprets this 'binding recipe'. The other advantage of doing this 
>>> is that we would eventually be able to use these binding recipes + 
>>> ABIDescriptor to generate a specialized stub for a particular call 
>>> site.
>>>
>>> 4.) We are currently shuffling the arguments for a down call into a 
>>> long[], and then in the VM we shuffle the arguments from the long[] 
>>> into an argument buffer (ShuffleDowncallContext). We can merge these 
>>> steps together, by directly shuffling the arguments into an argument 
>>> buffer on the Java side (since we have an off-heap API). This 
>>> decreases the overall complexity of the invoker implementation 
>>> significantly, since we can drop all the code relating to shuffle 
>>> recipes.
>>>
>>> I've been experimenting with these ideas, and have a prototype for 
>>> downcalls on Windows [2]. For this I copied the relevant UNI classes 
>>> to a separate `programmable` package and made the relevant changes 
>>> there, since some of the code was shared with 
>>> UniversalUpcallHandler. I've also preemptively removed the old UNI 
>>> code (for x86) to show roughly how much code would be removed by 
>>> switching to the new invoker API. I want to continue the experiment 
>>> for upcalls as well, after which more old code could be removed; 
>>> namely Argument, ArgumentBinding, CallingSequence (old), 
>>> CallingSeqeunceBuilder (old), Storage, StorageClass, SharedUtils 
>>> (mostly) and UniversalAdapter.
>>>
>>> How do these ideas sound? I'm mostly interested if this is flexible 
>>> enough to support AArch64 and SysV. After the upcall support, I can 
>>> look into porting the other 2 ABIs as well.
>>>
>>> Thanks,
>>> Jorn
>>>
>>> [1] : 
>>> https://github.com/openjdk/panama/blob/foreign-abi/src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp#L73
>>> [2] : 
>>> https://github.com/openjdk/panama/compare/foreign-abi...JornVernee:prog-back-no-old
>>>

From maurizio.cimadamore at oracle.com  Tue Sep 24 10:02:28 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 24 Sep 2019 11:02:28 +0100
Subject: [foreign-abi] On invokers
In-Reply-To: <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
Message-ID: <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>


On 24/09/2019 10:42, Jorn Vernee wrote:
> Yes, you're right that this is not the ultimate solution. It's 
> 'programmable' in the sense that what was previously hard-coded inside 
> the VM code is now passed in dynamically from Java through the API, 
> and defined by a particular ABIDescriptor.
Thanks, that matches my understanding of the code.
>
> These changes are meant to clean up some of the existing technological 
> debt we have in the UNI API. The 'programmability' is merely improved 
> to be able to describe the quirks in the existing ABIs using more 
> general, and hopefully broadly applicable concepts.
>
> I noticed that there is a mismatch between a C-level function 
> descriptor and an ABI-level function descriptor, for instance in the 
> case of meta-arguments. The current problem is that we give an 
> un-altered descriptor to UNI to work with, and then expect the invoker 
> to work out the mapping to an ABI-level call, which is inherently 
> ABI-specific. This patch adds another layer in between; it's the job 
> of the ABI implementation to adapt from the C-level descriptor to the 
> ABI-level descriptor. We need to extend the invoker API to provided 
> the right primitives for the ABI impl to do that. The API supports 
> creating a MethodHandle for an ABI-level call, which is then adapted 
> to C-level by the particular ABI impl.
>
> If more programmability is needed in the future this can be added. As 
> you say, likely in the areas of Bindings and ABIDescriptor + stub 
> generation :). This is just intended to be the next iteration in the 
> process.
Sure, don't let my comments detract from anything you have done which is 
great - I was just connecting it to some of the comments that were 
raised in the past - re. a desire to have a very low level ABI to allow 
user to _create_ new ABIs from scratch [1]. After seeing this work, I'm 
more skeptical that such an approach is really feasible.
>
> If you want to do a SysV port that would be much appreciated :). In 
> principle everything in the `programmable` package, except for 
> CallArranger is a part of the API, though there should be no need to 
> interact directly with BindingInterpreter and BufferLayout. So, if you 
> want to do a port the only thing you should have to do is add a SysV 
> version of CallArranger, (which I based on CallingSequenceBuilderImpl, 
> so that's probably a good place to start) and then call that from 
> SysVx64ABI.
>
> The things to do are;
>
> 1.) Create a SysV ABIDescriptor instance (make sure to add RAX as an 
> input storage). The x86_64Architecture class has the `abiFor` method 
> to do this
>
> 2.) Add a method that takes a C-level FunctionDescriptor + MethodType 
> and creates an ABI-level MethodHandle for this using the invoker API, 
> and then adapts this back to a C-level MethodHandle. You have to add 
> meta-arguments manually (see CallArranger::arrangeDowncall for an 
> example with in-memory return).
>
> 3.) When generating bindings, map storage indices to VMStorage 
> instances using the ABIDescriptor instance you created + 
> StorageClasses defined in x86_64Architecture (to get the right 
> VMStorage[] index).
>
> 4.) Add additional needed Binding operations when generating the 
> bindings, to replace things handled by the box-/unbox-Value methods 
> (this was needed for Windows, but maybe not for SysV).

Yep - this seems to match what I understood when looking around (hence 
my question on generality). I'll give this a short (probably in the 
later part of the week).

Thanks!
Maurizio

>
> Cheers,
> Jorn
>
> On 23/09/2019 22:56, Maurizio Cimadamore wrote:
>> Hi Jorn,
>> this is a very solid piece of work, and I like how it makes it a lot 
>> saner to reason about what's going on in the universal invoker - the 
>> entire logic is now more scrutable, so well done!
>>
>> I think that, in order to understand better how things are glued, I'd 
>> like to try to port SysV and see how that goes; from that 
>> perspective, I think it's not immediately clear which parts of the 
>> Java code are meant to be truly reusable across ABIs/platforms and 
>> which one are fixed.
>>
>> For instance: the ABIDescriptor class looks very general - and it is 
>> probably enough to cover the ABIs we have now. But, in a way, I see 
>> with it the same problems I see in the current universal invoker - 
>> that is, the ABIDescriptor class has to be an 'union' of all the 
>> things used in all possible ABIs. That is, a descriptor has to have 
>> input storage, output storage, (arguably very general) then more 
>> exotic info such as shadow space etc. The fact that - e.g. when using 
>> SysV we'd be forced to use an ABIDescriptor that speaks about 'shadow 
>> space' (ok we can set it to zero, no big deal) feels wrong in a way, 
>> for all the same reason as to why it was wrong in the old universal 
>> invoker to speak about x87 registers (which are pretty SysV specific).
>>
>> Let's imagine to add a very weird ABI which requires a more complex 
>> stack alignment scheme (e.g. stack alignment not constant across all 
>> args). How would we encode such an hypothetical ABI using the classes 
>> provided? Am I right that it would not be possible to do that using 
>> the out of the box ABIDescriptor, but that we would have to extend 
>> the ABIDescriptor to cover the requirements of the exotic ABI (e.g. 
>> have an extra array for the alignments for each arguments), and then 
>> leave those bits unused in most cases.
>>
>> The same goes, I think, for the set of operation supported by 
>> bindings and the binding interpreter, which are, I think, supposed to 
>> be shared across ABIs/platform. For now we have moves, buffer copy - 
>> which are, again, probably ok to cover the waterfront (especially 
>> since moves involve arbitrary VM storage, which makes them quite 
>> flexible and general); at the same time if a new operation is 
>> required by some exotic API (e.g. set overflow flag), maybe we need 
>> to add a new binding - which would mean updating the single shared 
>> binding interpreter (and then maybe start thinking about which 
>> interaction the new binding operation could have with the existing 
>> ones, even though, maybe some combinations are not even possible, by 
>> ABI design).
>>
>> In other words, while I can see this being much more general and 
>> maintainable than what we have now, I'm not sure I would still call 
>> it "pluggable" or "programmable", if you get what I'm saying. That 
>> is, at the end of the day the capability of ProgrammableInvoker are 
>> fixed by two factors: (i) the ABI descriptor (which seems fixed) and 
>> (ii) the set of supported binding operations (again fixed). So, even 
>> assuming we had an ultra-low-level API to allow an advanced developer 
>> to define his/her own ABI, I could still see ways in which certain 
>> ABIs could not be modeled w/o going deeper into the API internals 
>> (e.g. tweak ABI descriptor or bindings) or the VM.
>>
>> And that's ok - as long as we're honest about the goal here: we're 
>> not after a single API to rule'em'all (which I think, as attractive 
>> as it is, it might be a siren song) - we're after a way to put some 
>> method into the ABI madness, so that less work will be required when 
>> new ABIs will need to be defined.
>>
>> Or, did I take a wrong turn somewhere when going through the code?
>>
>> Maurizio
>>
>>
>> On 23/09/2019 13:32, Jorn Vernee wrote:
>>> Here is a webrev version of the changes as well: 
>>> http://cr.openjdk.java.net/~jvernee/prog-back/webrev.00/
>>>
>>> Jorn
>>>
>>> On 23/09/2019 13:43, Jorn Vernee wrote:
>>>> Hi,
>>>>
>>>> I've been looking into the current set of invokers we have on the 
>>>> foreign-abi branch for the past few weeks. There is still work to 
>>>> be done in this area, both in terms of performance, and in terms of 
>>>> programmability. In this email I will focus on the latter.
>>>>
>>>> The UniversalNativeInvoker (UNI) API is currently the most 
>>>> programmble invoker that we have, so if we want to increase the 
>>>> programmability of our backend to cover more and more ABIs, this 
>>>> seems like a good place to start. UNI goes a ways in being 
>>>> programmable with the CallingSequence, ShuffleRecipe and 
>>>> ArgumentBinding APIs, being able to select in which registers to 
>>>> pass values, but there are still some aspects that could be polished:
>>>>
>>>> 1.) If you look into the VM code that processes the shuffle recipe, 
>>>> you'll notice that the eventual argument buffer that's being fed to 
>>>> the stub has a fixed set of registers it can work with on a given 
>>>> platform [1], namely the ones that are used by the C ABI. This 
>>>> works when we have only one ABI (C), but for different ABIs we'd 
>>>> probably want a different set of registers. We can change the stub 
>>>> generation code to take an 'ABIDescriptor' from which we derive the 
>>>> stub and argument buffer layout instead. This will also provide a 
>>>> place to put other ABI details that need to be customized, like 
>>>> stack alignment, and argument shadow space (Windows), as well as a 
>>>> set of volatile registers, which will be a super set of the 
>>>> argument registers. We would end up generating 1 generic downcall 
>>>> stub for each ABI. Also, note that we would need to create 
>>>> architecture definitions on the Java side to be able to specify the 
>>>> ABIDescriptors there (since ABIs are defined in terms of 
>>>> architecture).
>>>>
>>>> 2.) There is a need to pass meta arguments to a function sometimes. 
>>>> For instance, we need to pass in a pointer to a return buffer for 
>>>> in-memory-returns, and e.g. on SysV we need to pass in the number 
>>>> of float arguments in RAX (or rather AL) for variadic functions. 
>>>> The former is handled automatically by CallingSequenceBuilder, and 
>>>> the latter is hard-coded in the VM code. Since these are both ABI 
>>>> details, I believe they should be handled by the ABI 
>>>> implementations. Ideally we'd have an invoker API that let's us 
>>>> say: "add a Java argument with this carrier type, and this 
>>>> MemoryLayout, and then shuffle it into this register.", and then 
>>>> the ABI implementation can handle the further adaptation from the 
>>>> ABI-level signature (e.g. an additional MemoryAddress passed in as 
>>>> first argument), to the C-level signature (allocate a buffer as 
>>>> first argument and also return it). This is mostly a refactoring 
>>>> move in UNI::invoke and CallingSequenceBuilder that removes the 
>>>> handling for in memory returns, and replaces it with a more general 
>>>> way of passing those kinds of arguments.
>>>>
>>>> 3.) The unboxing/boxing is currently handled by calling into the 
>>>> various ABI implementations. We can make this code shared by 
>>>> extending the current ArgumentBinding 'recipe' to include other 
>>>> operations, besides moving from a pointer to a register, that cover 
>>>> the things that are currently handled by the ABI boxing/unboxing 
>>>> implementations. The various CallingSequenceBuilder implementations 
>>>> can then specify these additional binding operations when 
>>>> generating bindings. This means that we only need one shared piece 
>>>> of code that interprets this 'binding recipe'. The other advantage 
>>>> of doing this is that we would eventually be able to use these 
>>>> binding recipes + ABIDescriptor to generate a specialized stub for 
>>>> a particular call site.
>>>>
>>>> 4.) We are currently shuffling the arguments for a down call into a 
>>>> long[], and then in the VM we shuffle the arguments from the long[] 
>>>> into an argument buffer (ShuffleDowncallContext). We can merge 
>>>> these steps together, by directly shuffling the arguments into an 
>>>> argument buffer on the Java side (since we have an off-heap API). 
>>>> This decreases the overall complexity of the invoker implementation 
>>>> significantly, since we can drop all the code relating to shuffle 
>>>> recipes.
>>>>
>>>> I've been experimenting with these ideas, and have a prototype for 
>>>> downcalls on Windows [2]. For this I copied the relevant UNI 
>>>> classes to a separate `programmable` package and made the relevant 
>>>> changes there, since some of the code was shared with 
>>>> UniversalUpcallHandler. I've also preemptively removed the old UNI 
>>>> code (for x86) to show roughly how much code would be removed by 
>>>> switching to the new invoker API. I want to continue the experiment 
>>>> for upcalls as well, after which more old code could be removed; 
>>>> namely Argument, ArgumentBinding, CallingSequence (old), 
>>>> CallingSeqeunceBuilder (old), Storage, StorageClass, SharedUtils 
>>>> (mostly) and UniversalAdapter.
>>>>
>>>> How do these ideas sound? I'm mostly interested if this is flexible 
>>>> enough to support AArch64 and SysV. After the upcall support, I can 
>>>> look into porting the other 2 ABIs as well.
>>>>
>>>> Thanks,
>>>> Jorn
>>>>
>>>> [1] : 
>>>> https://github.com/openjdk/panama/blob/foreign-abi/src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp#L73
>>>> [2] : 
>>>> https://github.com/openjdk/panama/compare/foreign-abi...JornVernee:prog-back-no-old
>>>>

From maurizio.cimadamore at oracle.com  Tue Sep 24 14:06:04 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 24 Sep 2019 15:06:04 +0100
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
Message-ID: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>

Hi,
as the subject says, the implementation classes of the layout API do not 
always store their properties into final fields, and they resort to lazy 
computation, etc. This negatively impacts C2 scrutability of same data 
structures.

This patch fixes this situation, by changing size/alignment to be final 
fields in AbstractLayout - so that they will have to be provided before 
hand. I've added, for clarity, and extra 'default' constructor to all 
layout implementation classes which allows to create a layout with 
standard alignment and empty name.

There are also few minor changes:

* I've tweaked VM to also trust final fields in the layout package

* I've rearranged some some scope classes so that their creation is less 
straightforward, more transparent and requires less reflective checks. 
This is particularly evident in HeapScope and BufferScope. Note that I 
also changed the public API of MemorySegment::ofArray and replaced that 
with multiple overloads (one per primitive array). This is good because 
it makes the code more 'static' and also because it removes the 
possibility for the user to pass in a wrong array type.

* I've re-ordered the way in which scope vs. segment is created - that 
is, instead of this

new XYZSegment(.., ..., ..., new XYZScope(...))

We now do this:

XYZScope scope = new XYZScope(...);
new XYZSegment(.., ..., ..., scope)

As this makes a difference for C2 (Vlad pointed this out).

Webrev:

http://cr.openjdk.java.net/~mcimadamore/panama/8231402_v2/


With this patch, the level of performances of the memory access API is 
virtually on par with Unsafe in our suite of synthetic benchmarks, at 
least when using the Graal compiler (*). With C2 there are still issues 
which have to do mainly with (i) escape analysis not being aggressive 
enough (a VM patch is required) and (ii) inlining not working well in 
relatively 'cold' code (e.g. segment creation/closure), so that some 
manual sprinkling of @ForceInline annotations is? required. I will 
pursue these in a follow up patch.

Maurizio

(*) the only exception to this is a test which performs indexed access, 
in which Graal compiler is not able to vectorize the loop when using the 
memory access API (because of the presence of address operation on 
longs); that said, performance of code compiled by the Graal compiler 
with the memory access API is still superior than that of C2 using 
unsafe (I'm also following up with the Graal compiler team on this 
issue). There also seems to be an issue with the liveness check which is 
never hoisted out of hot loops - leading to slightly slower 
performances; in C2 we have a similar issue and it's caused by the fact 
that the VM puts a memory barrier after Unsafe memory access calls 
(since the Unsafe call could touch the loop invariant itself!). We 
obviously need to relax some of these checks if the Unsafe call occurs 
from within the memory access API (which does not allow arbitrary 
read/write of Java fields).




From brian.goetz at oracle.com  Tue Sep 24 18:59:00 2019
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 24 Sep 2019 14:59:00 -0400
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
In-Reply-To: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
References: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
Message-ID: <c1efaf1f-0c2f-c3d0-9556-cc9f4dee5767@oracle.com>

Some review comments on the class specs themselves, not just on this 
particular change set.

I am happy to see that you have raised the flag of value-based on 
MemorySegment and friends.? But, as written, it's a bit of a lie, as 
these types are interfaces, and only classes can be value-based.? What 
you probably mean is: "all implementations of XXX must be value-based."? 
The same is true when you say "this class is immutable and thread-safe".

I would add to this: "In the future, this will be a **sealed** type 
..."; you do this for MemoryLayout but not MemorySegment. But even in 
MemoryLayout, I would strengthen to the wording used in j.l.constant:

 ?* <p>Non-platform classes should not implement {@linkplain 
ConstantDesc} directly.
 ?* Instead, they should extend {@link DynamicConstantDesc} (as {@link 
EnumDesc}
 ?* and {@link VarHandleDesc} do.)

 ?* @apiNote In the future, if the Java language permits, {@linkplain 
ConstantDesc}
 ?* may become a {@code sealed} interface, which would prohibit 
subclassing except by
 ?* explicitly permitted types.? Clients can assume that the following
 ?* set of subtypes is exhaustive: {@link String}, {@link Integer},
 ?* {@link Long}, {@link Float}, {@link Double}, {@link ClassDesc},
 ?* {@link MethodTypeDesc}, {@link MethodHandleDesc}, and
 ?* {@link DynamicConstantDesc}; this list may be extended to reflect future
 ?* changes to the constant pool format as defined in JVMS 4.4.

The view factories seem to have a naming inconsistency; there is 
`asPinned` and `asReadonly`, but `slice`.? Given the slightly odd 
treatment of views when it comes to temporal bounds, I would prefer the 
asXxx (which suggests you're going to use the view in place of the 
original) form, and suggest `asSlice` or `asNarrowed`.

I think you also want to give the sealing treatment to PathElement.



On 9/24/2019 10:06 AM, Maurizio Cimadamore wrote:
> Hi,
> as the subject says, the implementation classes of the layout API do 
> not always store their properties into final fields, and they resort 
> to lazy computation, etc. This negatively impacts C2 scrutability of 
> same data structures.
>
> This patch fixes this situation, by changing size/alignment to be 
> final fields in AbstractLayout - so that they will have to be provided 
> before hand. I've added, for clarity, and extra 'default' constructor 
> to all layout implementation classes which allows to create a layout 
> with standard alignment and empty name.
>
> There are also few minor changes:
>
> * I've tweaked VM to also trust final fields in the layout package
>
> * I've rearranged some some scope classes so that their creation is 
> less straightforward, more transparent and requires less reflective 
> checks. This is particularly evident in HeapScope and BufferScope. 
> Note that I also changed the public API of MemorySegment::ofArray and 
> replaced that with multiple overloads (one per primitive array). This 
> is good because it makes the code more 'static' and also because it 
> removes the possibility for the user to pass in a wrong array type.
>
> * I've re-ordered the way in which scope vs. segment is created - that 
> is, instead of this
>
> new XYZSegment(.., ..., ..., new XYZScope(...))
>
> We now do this:
>
> XYZScope scope = new XYZScope(...);
> new XYZSegment(.., ..., ..., scope)
>
> As this makes a difference for C2 (Vlad pointed this out).
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8231402_v2/
>
>
> With this patch, the level of performances of the memory access API is 
> virtually on par with Unsafe in our suite of synthetic benchmarks, at 
> least when using the Graal compiler (*). With C2 there are still 
> issues which have to do mainly with (i) escape analysis not being 
> aggressive enough (a VM patch is required) and (ii) inlining not 
> working well in relatively 'cold' code (e.g. segment 
> creation/closure), so that some manual sprinkling of @ForceInline 
> annotations is? required. I will pursue these in a follow up patch.
>
> Maurizio
>
> (*) the only exception to this is a test which performs indexed 
> access, in which Graal compiler is not able to vectorize the loop when 
> using the memory access API (because of the presence of address 
> operation on longs); that said, performance of code compiled by the 
> Graal compiler with the memory access API is still superior than that 
> of C2 using unsafe (I'm also following up with the Graal compiler team 
> on this issue). There also seems to be an issue with the liveness 
> check which is never hoisted out of hot loops - leading to slightly 
> slower performances; in C2 we have a similar issue and it's caused by 
> the fact that the VM puts a memory barrier after Unsafe memory access 
> calls (since the Unsafe call could touch the loop invariant itself!). 
> We obviously need to relax some of these checks if the Unsafe call 
> occurs from within the memory access API (which does not allow 
> arbitrary read/write of Java fields).
>
>
>


From maurizio.cimadamore at oracle.com  Tue Sep 24 19:56:03 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 24 Sep 2019 20:56:03 +0100
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
In-Reply-To: <c1efaf1f-0c2f-c3d0-9556-cc9f4dee5767@oracle.com>
References: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
 <c1efaf1f-0c2f-c3d0-9556-cc9f4dee5767@oracle.com>
Message-ID: <fbb125f8-d948-f926-ad90-164aa009ec8a@oracle.com>


On 24/09/2019 19:59, Brian Goetz wrote:
> Some review comments on the class specs themselves, not just on this 
> particular change set.
>
> I am happy to see that you have raised the flag of value-based on 
> MemorySegment and friends.? But, as written, it's a bit of a lie, as 
> these types are interfaces, and only classes can be value-based.? What 
> you probably mean is: "all implementations of XXX must be 
> value-based."? The same is true when you say "this class is immutable 
> and thread-safe".
Thanks for pointing these out - I'll make sure these get addressed in a 
followup patch.
>
> I would add to this: "In the future, this will be a **sealed** type 
> ..."; you do this for MemoryLayout but not MemorySegment. But even in 
> MemoryLayout, I would strengthen to the wording used in j.l.constant:
I've looked at that - but then decided to only use parts of it, given 
there are no public API types that are truly exposed here. In any case, 
I'll strengthen what we have.
>
> ?* <p>Non-platform classes should not implement {@linkplain 
> ConstantDesc} directly.
> ?* Instead, they should extend {@link DynamicConstantDesc} (as {@link 
> EnumDesc}
> ?* and {@link VarHandleDesc} do.)
>
> ?* @apiNote In the future, if the Java language permits, {@linkplain 
> ConstantDesc}
> ?* may become a {@code sealed} interface, which would prohibit 
> subclassing except by
> ?* explicitly permitted types.? Clients can assume that the following
> ?* set of subtypes is exhaustive: {@link String}, {@link Integer},
> ?* {@link Long}, {@link Float}, {@link Double}, {@link ClassDesc},
> ?* {@link MethodTypeDesc}, {@link MethodHandleDesc}, and
> ?* {@link DynamicConstantDesc}; this list may be extended to reflect 
> future
> ?* changes to the constant pool format as defined in JVMS 4.4.
>
> The view factories seem to have a naming inconsistency; there is 
> `asPinned` and `asReadonly`, but `slice`.? Given the slightly odd 
> treatment of views when it comes to temporal bounds, I would prefer 
> the asXxx (which suggests you're going to use the view in place of the 
> original) form, and suggest `asSlice` or `asNarrowed`.
Good point - yes, the slice is a view and all views should use uniform 
naming.
>
> I think you also want to give the sealing treatment to PathElement.

Yup

Thanks
Maurizio

>
>
>
> On 9/24/2019 10:06 AM, Maurizio Cimadamore wrote:
>> Hi,
>> as the subject says, the implementation classes of the layout API do 
>> not always store their properties into final fields, and they resort 
>> to lazy computation, etc. This negatively impacts C2 scrutability of 
>> same data structures.
>>
>> This patch fixes this situation, by changing size/alignment to be 
>> final fields in AbstractLayout - so that they will have to be 
>> provided before hand. I've added, for clarity, and extra 'default' 
>> constructor to all layout implementation classes which allows to 
>> create a layout with standard alignment and empty name.
>>
>> There are also few minor changes:
>>
>> * I've tweaked VM to also trust final fields in the layout package
>>
>> * I've rearranged some some scope classes so that their creation is 
>> less straightforward, more transparent and requires less reflective 
>> checks. This is particularly evident in HeapScope and BufferScope. 
>> Note that I also changed the public API of MemorySegment::ofArray and 
>> replaced that with multiple overloads (one per primitive array). This 
>> is good because it makes the code more 'static' and also because it 
>> removes the possibility for the user to pass in a wrong array type.
>>
>> * I've re-ordered the way in which scope vs. segment is created - 
>> that is, instead of this
>>
>> new XYZSegment(.., ..., ..., new XYZScope(...))
>>
>> We now do this:
>>
>> XYZScope scope = new XYZScope(...);
>> new XYZSegment(.., ..., ..., scope)
>>
>> As this makes a difference for C2 (Vlad pointed this out).
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/8231402_v2/
>>
>>
>> With this patch, the level of performances of the memory access API 
>> is virtually on par with Unsafe in our suite of synthetic benchmarks, 
>> at least when using the Graal compiler (*). With C2 there are still 
>> issues which have to do mainly with (i) escape analysis not being 
>> aggressive enough (a VM patch is required) and (ii) inlining not 
>> working well in relatively 'cold' code (e.g. segment 
>> creation/closure), so that some manual sprinkling of @ForceInline 
>> annotations is? required. I will pursue these in a follow up patch.
>>
>> Maurizio
>>
>> (*) the only exception to this is a test which performs indexed 
>> access, in which Graal compiler is not able to vectorize the loop 
>> when using the memory access API (because of the presence of address 
>> operation on longs); that said, performance of code compiled by the 
>> Graal compiler with the memory access API is still superior than that 
>> of C2 using unsafe (I'm also following up with the Graal compiler 
>> team on this issue). There also seems to be an issue with the 
>> liveness check which is never hoisted out of hot loops - leading to 
>> slightly slower performances; in C2 we have a similar issue and it's 
>> caused by the fact that the VM puts a memory barrier after Unsafe 
>> memory access calls (since the Unsafe call could touch the loop 
>> invariant itself!). We obviously need to relax some of these checks 
>> if the Unsafe call occurs from within the memory access API (which 
>> does not allow arbitrary read/write of Java fields).
>>
>>
>>
>

From john.r.rose at oracle.com  Tue Sep 24 21:14:54 2019
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 24 Sep 2019 14:14:54 -0700
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
In-Reply-To: <fbb125f8-d948-f926-ad90-164aa009ec8a@oracle.com>
References: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
 <c1efaf1f-0c2f-c3d0-9556-cc9f4dee5767@oracle.com>
 <fbb125f8-d948-f926-ad90-164aa009ec8a@oracle.com>
Message-ID: <1357F1E3-A8B0-4989-B514-3CD54F0DB5B4@oracle.com>

On Sep 24, 2019, at 12:56 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
>> The view factories seem to have a naming inconsistency; there is `asPinned` and `asReadonly`, but `slice`.  Given the slightly odd treatment of views when it comes to temporal bounds, I would prefer the asXxx (which suggests you're going to use the view in place of the original) form, and suggest `asSlice` or `asNarrowed`.
> Good point - yes, the slice is a view and all views should use uniform naming.

Not to go crazy at the bike shed, but it seems to me that spatially narrowed views are
special enough to merit their own intuitive terminology, in the same way that
List has just subList and not asSubList/asSlice.  After all, the contiguous ordering
of a segment of memory is probably its most salient property, and so slicing
is one of the most fundamental operations.  The access modes (tweaked by
asReadOnly) and the temporal properties (tweaked by a scope API and/or
view operations like asPinned) are less salient and don?t deserve special
terms.  (List has very limited view-constructors, but omitting subList is hard
to imagine.)

Also, unlike most view creation operation, the slice creation API has two
degrees of freedom, and they vary over the whole datum being sliced.
Most view creators (think Array.asList) re-interpret the *whole* datum
with minimal configuration parameters.  The effect of this can be seen
by imagining the bikeshed color "asSubSegment? ("asSubSequence?,
etc., as appropriate).  How does that sound?  It sounds wrong IMO,
because the ?as? part sets you up to look for a view, but then the ?sub?
part doesn?t parse, since no ?foo? is alias-able to a ?sub-foo? of itself.
(The whole is greater than the part; Cantor?s pairing constructions, etc.)
So a sub-foo is a little like an alias of a foo, but only *part* of a foo.
Calling the sub-foo a ?view? of a foo drops the most important fact,
the part/whole distinction.

So, my only objection to ?slice? might be that it sounds like a verb where a
noun is probably preferable (but it?s a noun also, which is why I don?t find
it too difficult).  I think a bikeshed color like ?subSegment? or ?makeSlice?
is a better alternative to ?slice? than ?asSlice?.

I promise to put away my spray paint now.

? John

From maurizio.cimadamore at oracle.com  Tue Sep 24 22:08:13 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 24 Sep 2019 23:08:13 +0100
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
In-Reply-To: <1357F1E3-A8B0-4989-B514-3CD54F0DB5B4@oracle.com>
References: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
 <c1efaf1f-0c2f-c3d0-9556-cc9f4dee5767@oracle.com>
 <fbb125f8-d948-f926-ad90-164aa009ec8a@oracle.com>
 <1357F1E3-A8B0-4989-B514-3CD54F0DB5B4@oracle.com>
Message-ID: <feb0e6ca-a4e3-1b3a-5f79-8605096f1c1d@oracle.com>

For the records - the rationale behind MemorySegment::slice (and also 
asReadOnly...) was driven by familiarity with ByteBuffer API. That is, 
these concepts exist in the BB API with precisely those names, so I 
thought it might have been better not to reinvent the wheel (given that 
I can see people currently using BB for off-heap usages looking at this 
API).

Maurizio

On 24/09/2019 22:14, John Rose wrote:
> On Sep 24, 2019, at 12:56 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>> The view factories seem to have a naming inconsistency; there is 
>>> `asPinned` and `asReadonly`, but `slice`.? Given the slightly odd 
>>> treatment of views when it comes to temporal bounds, I would prefer 
>>> the asXxx (which suggests you're going to use the view in place of 
>>> the original) form, and suggest `asSlice` or `asNarrowed`.
>> Good point - yes, the slice is a view and all views should use 
>> uniform naming.
>
> Not to go crazy at the bike shed, but it seems to me that spatially 
> narrowed views are
> special enough to merit their own intuitive terminology, in the same 
> way that
> List has just subList and not asSubList/asSlice. ?After all, the 
> contiguous ordering
> of a segment of memory is probably its most salient property, and so 
> slicing
> is one of the most fundamental operations. ?The access modes (tweaked by
> asReadOnly) and the temporal properties (tweaked by a scope API and/or
> view operations like asPinned) are less salient and don?t deserve special
> terms. ?(List has very limited view-constructors, but omitting subList 
> is hard
> to imagine.)
>
> Also, unlike most view creation operation, the slice creation API has two
> degrees of freedom, and they vary over the whole datum being sliced.
> Most view creators (think Array.asList) re-interpret the *whole* datum
> with minimal configuration parameters. ?The effect of this can be seen
> by imagining the bikeshed color "asSubSegment? ("asSubSequence?,
> etc., as appropriate). ?How does that sound? ?It sounds wrong IMO,
> because the ?as? part sets you up to look for a view, but then the ?sub?
> part doesn?t parse, since no ?foo? is alias-able to a ?sub-foo? of itself.
> (The whole is greater than the part; Cantor?s pairing constructions, etc.)
> So a sub-foo is a little like an alias of a foo, but only *part* of a foo.
> Calling the sub-foo a ?view? of a foo drops the most important fact,
> the part/whole distinction.
>
> So, my only objection to ?slice? might be that it sounds like a verb 
> where a
> noun is probably preferable (but it?s a noun also, which is why I 
> don?t find
> it too difficult). ?I think a bikeshed color like ?subSegment? or 
> ?makeSlice?
> is a better alternative to ?slice? than ?asSlice?.
>
> I promise to put away my spray paint now.
>
> ? John

From john.r.rose at oracle.com  Tue Sep 24 22:10:34 2019
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 24 Sep 2019 15:10:34 -0700
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
In-Reply-To: <feb0e6ca-a4e3-1b3a-5f79-8605096f1c1d@oracle.com>
References: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
 <c1efaf1f-0c2f-c3d0-9556-cc9f4dee5767@oracle.com>
 <fbb125f8-d948-f926-ad90-164aa009ec8a@oracle.com>
 <1357F1E3-A8B0-4989-B514-3CD54F0DB5B4@oracle.com>
 <feb0e6ca-a4e3-1b3a-5f79-8605096f1c1d@oracle.com>
Message-ID: <77CC3448-18E0-4768-87A0-5D18404D368E@oracle.com>

That?s another good point for slice. Note however that asSubList is a more modern API point than BB.slice. 

> On Sep 24, 2019, at 3:08 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> For the records - the rationale behind MemorySegment::slice (and also asReadOnly...) was driven by familiarity with ByteBuffer API. That is, these concepts exist in the BB API with precisely those names, so I thought it might have been better not to reinvent the wheel (given that I can see people currently using BB for off-heap usages looking at this API).
> 
> Maurizio
> 
>> On 24/09/2019 22:14, John Rose wrote:
>>> On Sep 24, 2019, at 12:56 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>> 
>>>> The view factories seem to have a naming inconsistency; there is `asPinned` and `asReadonly`, but `slice`.  Given the slightly odd treatment of views when it comes to temporal bounds, I would prefer the asXxx (which suggests you're going to use the view in place of the original) form, and suggest `asSlice` or `asNarrowed`.
>>> Good point - yes, the slice is a view and all views should use uniform naming.
>> 
>> Not to go crazy at the bike shed, but it seems to me that spatially narrowed views are
>> special enough to merit their own intuitive terminology, in the same way that
>> List has just subList and not asSubList/asSlice.  After all, the contiguous ordering
>> of a segment of memory is probably its most salient property, and so slicing
>> is one of the most fundamental operations.  The access modes (tweaked by
>> asReadOnly) and the temporal properties (tweaked by a scope API and/or
>> view operations like asPinned) are less salient and don?t deserve special
>> terms.  (List has very limited view-constructors, but omitting subList is hard
>> to imagine.)
>> 
>> Also, unlike most view creation operation, the slice creation API has two
>> degrees of freedom, and they vary over the whole datum being sliced.
>> Most view creators (think Array.asList) re-interpret the *whole* datum
>> with minimal configuration parameters.  The effect of this can be seen
>> by imagining the bikeshed color "asSubSegment? ("asSubSequence?,
>> etc., as appropriate).  How does that sound?  It sounds wrong IMO,
>> because the ?as? part sets you up to look for a view, but then the ?sub?
>> part doesn?t parse, since no ?foo? is alias-able to a ?sub-foo? of itself.
>> (The whole is greater than the part; Cantor?s pairing constructions, etc.)
>> So a sub-foo is a little like an alias of a foo, but only *part* of a foo.
>> Calling the sub-foo a ?view? of a foo drops the most important fact,
>> the part/whole distinction.
>> 
>> So, my only objection to ?slice? might be that it sounds like a verb where a
>> noun is probably preferable (but it?s a noun also, which is why I don?t find
>> it too difficult).  I think a bikeshed color like ?subSegment? or ?makeSlice?
>> is a better alternative to ?slice? than ?asSlice?.
>> 
>> I promise to put away my spray paint now.
>> 
>> ? John

From john.r.rose at oracle.com  Tue Sep 24 22:31:02 2019
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 24 Sep 2019 15:31:02 -0700
Subject: [foreign-abi] On invokers
In-Reply-To: <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
 <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>
Message-ID: <259447E3-19EC-49D3-BCB4-C20F0E5BF010@oracle.com>

On Sep 24, 2019, at 3:02 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
>> If more programmability is needed in the future this can be added. As you say, likely in the areas of Bindings and ABIDescriptor + stub generation :). This is just intended to be the next iteration in the process.
> Sure, don't let my comments detract from anything you have done which is great - I was just connecting it to some of the comments that were raised in the past - re. a desire to have a very low level ABI to allow user to _create_ new ABIs from scratch [1]. After seeing this work, I'm more skeptical that such an approach is really feasible.

To call this programmable is like saying the glass has water in it.  Maurizio, you are pointing out that
more water could be added.  I agree.

I think, (at least as a design heuristic, and moreover as a matter of good taste), that a design like this
shows evidence of correct factoring if has the potential to build non-standard calling sequences
outside known ABIs).  Such non-ABI calling sequences are rare but sometimes important despite
being rare.  For example, Cilk uses (used) special non-ABI conventions for vector-function linkage.
This is something we would (IMO) like to have in our back pocket also.  (I have wide ambitions
for Java as a vector-programming platform.)  Also, Windows is known to have a whole grab-bag
of calling conventions.  And what if we want to inter-op with a newer language (Swift, Go) and find
that it (as such environments do) has some funny calling conventions?  We?d like to be nimble on
that score, just in case that?s a limiting factor.  (Yes, GC is another limiting factor, but you knock
them down one at a time.)  Thus, beyond heuristics and matters of taste, aiming for generalizable
mechanisms is the right move here.

Maurizio, my reaction to your observations about how we might have missed the ?full glass? of
full generality is simply that, if a meta-ABI design is known to be flexible across known degrees of
freedom,. then it is likely that it can be adapted to new, unforeseen degrees of freedom, as they
become important.

My $0.02?

? John



From maurizio.cimadamore at oracle.com  Tue Sep 24 22:47:47 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 24 Sep 2019 23:47:47 +0100
Subject: [foreign-abi] On invokers
In-Reply-To: <259447E3-19EC-49D3-BCB4-C20F0E5BF010@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
 <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>
 <259447E3-19EC-49D3-BCB4-C20F0E5BF010@oracle.com>
Message-ID: <821ff859-362e-6121-d4e3-4565ea4b7870@oracle.com>


On 24/09/2019 23:31, John Rose wrote:
> Maurizio, my reaction to your observations about how we might have 
> missed the ?full glass? of
> full generality is simply that, if a meta-ABI design is known to be 
> flexible across known degrees of
> freedom,. then it is likely that it can be adapted to new, unforeseen 
> degrees of freedom, as they
> become important.

To be clear, in case what I said came off the wrong way - it was not my 
intention to criticize this work in any way. It was more of a call for 
being honest about what this effort is about; programmable, or pluggable 
invoker might evoke the idea that users can mix and match ABIs according 
to their tastes - e.g. some sort of API that lets you control all the 
knobs - present and future. I think the best we can do at this point in 
time is, as you say, generalize over the case we know about - and hope 
(with good reason) that the new cases we'll see will be adapted with 
ease. In other words, our goal here is to devise an invoker that is 
general enough to supersede the invokers we currently have (of which we 
have three: universal, link2native and JNI-based direct invoker), and I 
was trying to resist to the sirens singing for a general meta-ABI API. 
That might come, in time, or maybe never will - for now the goal is to 
make the implementation saner, so that we can more rapidly adapt across 
platforms.

Maurizio



From john.r.rose at oracle.com  Wed Sep 25 00:25:29 2019
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 24 Sep 2019 17:25:29 -0700
Subject: [foreign-abi] On invokers
In-Reply-To: <821ff859-362e-6121-d4e3-4565ea4b7870@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
 <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>
 <259447E3-19EC-49D3-BCB4-C20F0E5BF010@oracle.com>
 <821ff859-362e-6121-d4e3-4565ea4b7870@oracle.com>
Message-ID: <38EF2152-43E5-464C-A66F-CE70B12B5164@oracle.com>

On Sep 24, 2019, at 3:47 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 24/09/2019 23:31, John Rose wrote:
>> Maurizio, my reaction to your observations about how we might have missed the ?full glass? of
>> full generality is simply that, if a meta-ABI design is known to be flexible across known degrees of
>> freedom,. then it is likely that it can be adapted to new, unforeseen degrees of freedom, as they
>> become important.
> 
> To be clear, in case what I said came off the wrong way - it was not my intention to criticize this work in any way. It was more of a call for being honest about what this effort is about; programmable, or pluggable invoker might evoke the idea that users can mix and match ABIs according to their tastes - e.g. some sort of API that lets you control all the knobs - present and future. I think the best we can do at this point in time is, as you say, generalize over the case we know about - and hope (with good reason) that the new cases we'll see will be adapted with ease. In other words, our goal here is to devise an invoker that is general enough to supersede the invokers we currently have (of which we have three: universal, link2native and JNI-based direct invoker), and I was trying to resist to the sirens singing for a general meta-ABI API. That might come, in time, or maybe never will - for now the goal is to make the implementation saner, so that we can more rapidly adapt across platforms.

:-)  Yes, that?s very good.

It looks like we are agreed to avoid the twin errors of (a) premature generalization, and (b) premature
non-generalization.

(*Mature* non-generalization appears when you have a road map with an endpoint, so you can say things like,
?You might ask my API to do extra task X, but you should really use a different API for that.?  Folks vary by
temperament which kind of premature-ness they are more likely to fall into.  Y'all know I?m an (a), so of course
I?m always on the lookout for signs of (b), whether they exist or not.  The Vector API is currently having a
vigourous conversation about such choices.)


From henry.jen at oracle.com  Wed Sep 25 02:52:13 2019
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 24 Sep 2019 19:52:13 -0700
Subject: [foreign] RFR: 8229857: scope inference on pointer to pointer is
 not friendly
In-Reply-To: <09f84600-e583-3e88-c3dd-5f4b7600b39d@oracle.com>
References: <7AD9968F-A226-47E8-9F88-DE016D592A2C@oracle.com>
 <33478d46-7bbd-b3a3-83c0-c51226cce66a@oracle.com>
 <8A03245A-91D6-4AF3-B482-8FDE887232C5@oracle.com>
 <8c5fd30e-84a4-7a73-6b10-85aef361dd99@oracle.com>
 <3682de37-8494-4100-d31c-465fdd36109f@oracle.com>
 <09f84600-e583-3e88-c3dd-5f4b7600b39d@oracle.com>
Message-ID: <B6EE0502-F99E-4242-8441-6098221F4BCB@oracle.com>

I revised the webrev[1] based on feedbacks, here is a quick summary:

- Stick with a single Pointer interface, with a isUnmanaged() predicate to allow check if the pointer is not associated with a Scope
- The method assertScope() still with same limitation that only allow an unmanaged Pointer to be associate with a Scope. It?s developer?s responsibility to make sure it?s proper. However, use of this method is mostly unnecessary.
- Relax the pointer assignment requirement derived based on scope inference. This is somewhat significant, but as we seems to agree that the scope inference is not working well, we take this out from Pointer API and expect usage not involving native code but only native memory be using MemAccess API instead. Case in point, when a native function returns a struct by value, the struct has it?s own scope, while we still need to work out a better approach for that, the limitation will create a subtle difference that?s not obvious for developer, see ScopeTest.java:214-215.
- Same scope inference change apply to Callback as well

Also I include another small change worth mentioning,
- Scope.allocateCString will allow null and return a Pointer.ofNull() in that case instead of cause NPE. This make it easier to make call to native functions more transparent where null pointer is accepted. We can keep it strict, but that would make more verbose code with null check when calling native functions take a null.

[1] http://cr.openjdk.java.net/~henryjen/panama/8229857/1/webrev/

Cheers,
Henry


> On Aug 28, 2019, at 12:56 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 28/08/2019 18:23, Maurizio Cimadamore wrote:
>> Do we agree on the description of the issue here? Then we can talk on how to fix it. 
> 
> Since we agree on the problem statement, let's dissect the problem a little more.
> 
> In my view this discussion raises the issue that there are two (very different) kind of pointer - I'll be using the terminology managed/unmanaged.
> 
> * managed pointers are created in Java code, typically via a Scope::allocate operation. They always have a finite region size, and a finite temporal range.
> 
> * unmanaged pointers are created by native code (or synthesized by the Panama runtime e.g. during struct access). They have an unknown region size and unknown range.
> 
> To me, this suggests (at least a design level) that this distinction between managed and unmanaged should perhaps be surfaced in the API. That is, there should be a top type Pointer<X> which is the common root for all pointers, both managed and unmanaged. As such it will NOT feature a scope() method.
> 
> Unmanaged or UncheckedPointer will only be available in the binder internals, but not available outside. They are not attached to any scope.
> 
> Then you have a ManagedPointer underneath, which does have a scope() method. These are the pointers returned by the Scope allocation methods.
> 
> As long as you remain in the ManagedPointer realm, you are safe - ownership keeps your pointer in check and so forth. We could even apply scope inference, if a struct's return type is ManagedPointer<X>, and get same strict semantics we have now. But, in the general case, jextracted types will be unmanaged (e.g. just Pointer<X>), meaning that to go from an unmanaged pointer to a managed one some magic trick is needed (there could be an API point for this... or not), in which case all safety guarantees are abandoned (e.g. it will be possible to crash the VM by assigning the wrong scope to an unmanaged pointer and then dereferencing it at the wrong time).
> 
> Now, in terms of implementation - we could do exactly as I describe, and add a 'managed pointer' interface that extends from pointer (and, I guess, same for arrays?).
> 
> Or, we could do a lump move, and use same interface for both managed and unmanaged case, plus a predicate which tells us if this is a managed pointer/array (or infer the managed-ness from the fact that there's no owning scope). And then add a projection which attaches some scope/size to an unmanaged pointer, therefore making it managed (but this would be an unsafe operation in general).
> 
> Maurizio
> 
> 


From jatin.bhateja at intel.com  Wed Sep 25 06:57:22 2019
From: jatin.bhateja at intel.com (jatin.bhateja at intel.com)
Date: Wed, 25 Sep 2019 06:57:22 +0000
Subject: hg: panama/dev: Summary: [vector][generic-opers] Converting
 instruction patterns for vector convert and compare operation
 to use generic operands.
Message-ID: <201909250657.x8P6vNWI019249@aojmv0008.oracle.com>

Changeset: f8456fb3927a
Author:    Jatin Bhateja <jatin.bhateja at intel.com>
Date:      2019-09-25 12:30 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/f8456fb3927a

Summary: [vector][generic-opers] Converting instruction patterns for vector convert and compare operation to use generic operands.
Contributed-by: jatin.bhateja at intel.com

! src/hotspot/cpu/x86/x86.ad
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java


From nick.gasson at arm.com  Wed Sep 25 08:24:54 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Wed, 25 Sep 2019 16:24:54 +0800
Subject: [foreign-abi] On invokers
In-Reply-To: <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
Message-ID: <fda21db3-b572-5c5e-b808-322999be7e85@arm.com>

Hi Jorn,

> 
> If you want to do a SysV port that would be much appreciated :). In
> principle everything in the `programmable` package, except for
> CallArranger is a part of the API, though there should be no need to
> interact directly with BindingInterpreter and BufferLayout. So, if you
> want to do a port the only thing you should have to do is add a SysV
> version of CallArranger, (which I based on CallingSequenceBuilderImpl,
> so that's probably a good place to start) and then call that from
> SysVx64ABI.
> 

I can look at the AArch64 part, but I'm on vacation for the next two 
weeks so it won't be anytime soon unfortunately. I like how this patch 
removes a lot of duplication from the different architecture backends in 
the hotspot C++ code.

A slightly unrelated question, is there any way we can support some kind 
of "fallback" invoker for hotspot ports that either don't have a 
universal/direct invoker backed yet (e.g. 32bit Arm) or can't have one 
(Zero)? I was thinking about something that would delegate to libffi, 
but I'm not sure how practical that would be.

Thanks,
Nick

From maurizio.cimadamore at oracle.com  Wed Sep 25 10:03:47 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 25 Sep 2019 11:03:47 +0100
Subject: [foreign] RFR: 8229857: scope inference on pointer to pointer is
 not friendly
In-Reply-To: <B6EE0502-F99E-4242-8441-6098221F4BCB@oracle.com>
References: <7AD9968F-A226-47E8-9F88-DE016D592A2C@oracle.com>
 <33478d46-7bbd-b3a3-83c0-c51226cce66a@oracle.com>
 <8A03245A-91D6-4AF3-B482-8FDE887232C5@oracle.com>
 <8c5fd30e-84a4-7a73-6b10-85aef361dd99@oracle.com>
 <3682de37-8494-4100-d31c-465fdd36109f@oracle.com>
 <09f84600-e583-3e88-c3dd-5f4b7600b39d@oracle.com>
 <B6EE0502-F99E-4242-8441-6098221F4BCB@oracle.com>
Message-ID: <9adef21c-8d57-0347-f177-f788190893e2@oracle.com>

Hi Henry - some comments:

* I think I'd still prefer, in terms of code hygiene, to have a static, 
well-known UNCHECKED scope, rather than just null. Doesn't cost anything 
in terms of memory, and you still have a quick way to check (but then we 
have to protect clients not to use the unchecked scope to allocate 
themselves)

* I'm on the fence with function pointers and with their relationship 
with assertScope. The idea behind management of VM stubs is that the 
stub keeps a weak reference to the upcall handler that should be used to 
make the Java upcall; the upcall handler is kept there by the scope (a 
scope keeps a list of all the stubs allocated within it with 
Scope::allocateCallback). When the scope is closed, the list is cleared, 
the upcall handler becomes unreachable, and this triggers a cleaner 
which will get rid of the sub (this cleaner is registered when clients 
call SystemABI::upcallStub - which is in turn called by 
Scope::allocateCallback).

In other words, if you allocate a callback in a scope, then save the 
callback onto some native struct, then close the scope, there's no 
guarantee that the callback will still be there to call (depending on 
how soon, or late the GC calls the cleaner).

So, in a way, if you read a function pointer from native that originally 
comes from Java (e.g. a callback) and you give it the 'unchecked' scope 
- I think one might have an expectation that the stub will be there 
forever, which is fundamentally not the case. The stub is still 
logically associated with its originating scope, and will cease to exist 
when the original scope has gone away.

To me, this seems to suggest that for callbacks our strategy has to be 
more nuanced:

- if you read a function pointer that doesn't come from Java (e.g. is 
not a lambda passed to some native function) - then returning an 
unchecked function pointer is fine

- if you read a function pointer that comes from Java, its original 
scope should be restored (and probably checked again) - after all the 
stub is saved _inside_ the stub; I believe we could similarly save a 
weak reference to the scope in there w/o wasting too much space. With 
pointers, of course, we don't have this luxury (*).

In other words, I think unmanaged should be == native.

(*) I half-lied when I said that with pointer we don't have luxury to do 
something similar - in fact we do, but we don't currently do much in 
that direction; that is, a native scope is, essentially, also an 
allocator. Since this allocator allocates big chunks of memory and then 
allocates from there, there is in principle nothing stopping us from 
saving a scope weak reference into a reserved portion of the allocated 
memory - and then have some scheme to get back the scope refernce given 
an address that falls within the allocator range. This is hard to do 
now, because all the allocations we do are independent mallocs, but 
might not be so hard to do if we allocated memory in a different way; in 
any case this is worth keeping in the back of our minds for later.

Maurizio


On 25/09/2019 03:52, Henry Jen wrote:
> I revised the webrev[1] based on feedbacks, here is a quick summary:
>
> - Stick with a single Pointer interface, with a isUnmanaged() predicate to allow check if the pointer is not associated with a Scope
> - The method assertScope() still with same limitation that only allow an unmanaged Pointer to be associate with a Scope. It?s developer?s responsibility to make sure it?s proper. However, use of this method is mostly unnecessary.
> - Relax the pointer assignment requirement derived based on scope inference. This is somewhat significant, but as we seems to agree that the scope inference is not working well, we take this out from Pointer API and expect usage not involving native code but only native memory be using MemAccess API instead. Case in point, when a native function returns a struct by value, the struct has it?s own scope, while we still need to work out a better approach for that, the limitation will create a subtle difference that?s not obvious for developer, see ScopeTest.java:214-215.
> - Same scope inference change apply to Callback as well
>
> Also I include another small change worth mentioning,
> - Scope.allocateCString will allow null and return a Pointer.ofNull() in that case instead of cause NPE. This make it easier to make call to native functions more transparent where null pointer is accepted. We can keep it strict, but that would make more verbose code with null check when calling native functions take a null.
>
> [1] http://cr.openjdk.java.net/~henryjen/panama/8229857/1/webrev/
>
> Cheers,
> Henry
>
>
>> On Aug 28, 2019, at 12:56 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>>
>> On 28/08/2019 18:23, Maurizio Cimadamore wrote:
>>> Do we agree on the description of the issue here? Then we can talk on how to fix it.
>> Since we agree on the problem statement, let's dissect the problem a little more.
>>
>> In my view this discussion raises the issue that there are two (very different) kind of pointer - I'll be using the terminology managed/unmanaged.
>>
>> * managed pointers are created in Java code, typically via a Scope::allocate operation. They always have a finite region size, and a finite temporal range.
>>
>> * unmanaged pointers are created by native code (or synthesized by the Panama runtime e.g. during struct access). They have an unknown region size and unknown range.
>>
>> To me, this suggests (at least a design level) that this distinction between managed and unmanaged should perhaps be surfaced in the API. That is, there should be a top type Pointer<X> which is the common root for all pointers, both managed and unmanaged. As such it will NOT feature a scope() method.
>>
>> Unmanaged or UncheckedPointer will only be available in the binder internals, but not available outside. They are not attached to any scope.
>>
>> Then you have a ManagedPointer underneath, which does have a scope() method. These are the pointers returned by the Scope allocation methods.
>>
>> As long as you remain in the ManagedPointer realm, you are safe - ownership keeps your pointer in check and so forth. We could even apply scope inference, if a struct's return type is ManagedPointer<X>, and get same strict semantics we have now. But, in the general case, jextracted types will be unmanaged (e.g. just Pointer<X>), meaning that to go from an unmanaged pointer to a managed one some magic trick is needed (there could be an API point for this... or not), in which case all safety guarantees are abandoned (e.g. it will be possible to crash the VM by assigning the wrong scope to an unmanaged pointer and then dereferencing it at the wrong time).
>>
>> Now, in terms of implementation - we could do exactly as I describe, and add a 'managed pointer' interface that extends from pointer (and, I guess, same for arrays?).
>>
>> Or, we could do a lump move, and use same interface for both managed and unmanaged case, plus a predicate which tells us if this is a managed pointer/array (or infer the managed-ness from the fact that there's no owning scope). And then add a projection which attaches some scope/size to an unmanaged pointer, therefore making it managed (but this would be an unsafe operation in general).
>>
>> Maurizio
>>
>>

From maurizio.cimadamore at oracle.com  Wed Sep 25 10:13:26 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 25 Sep 2019 11:13:26 +0100
Subject: [foreign-abi] On invokers
In-Reply-To: <fda21db3-b572-5c5e-b808-322999be7e85@arm.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
 <fda21db3-b572-5c5e-b808-322999be7e85@arm.com>
Message-ID: <408afad7-950a-1905-03b0-e730f3905305@oracle.com>


On 25/09/2019 09:24, Nick Gasson wrote:
> Hi Jorn,
>
>>
>> If you want to do a SysV port that would be much appreciated :). In
>> principle everything in the `programmable` package, except for
>> CallArranger is a part of the API, though there should be no need to
>> interact directly with BindingInterpreter and BufferLayout. So, if you
>> want to do a port the only thing you should have to do is add a SysV
>> version of CallArranger, (which I based on CallingSequenceBuilderImpl,
>> so that's probably a good place to start) and then call that from
>> SysVx64ABI.
>>
>
> I can look at the AArch64 part, but I'm on vacation for the next two 
> weeks so it won't be anytime soon unfortunately. I like how this patch 
> removes a lot of duplication from the different architecture backends 
> in the hotspot C++ code.
>
> A slightly unrelated question, is there any way we can support some 
> kind of "fallback" invoker for hotspot ports that either don't have a 
> universal/direct invoker backed yet (e.g. 32bit Arm) or can't have one 
> (Zero)? I was thinking about something that would delegate to libffi, 
> but I'm not sure how practical that would be.

When prototyping different approaches I've used libffi many times to 
implement SystemABI, so... it can be done. That said, I'd be wary of 
creating "yet another invoker". As for ports that can't have an invoker 
implemented (Zero) because lack of support for assembly, I think nothing 
prevents these efforts from using a radically different SystemABI 
implementation which, instead of being based on assembly tricks can be 
based, as you say, on some 3rd party library (as they probably already 
do for JNI).

Maurizio

>
> Thanks,
> Nick

From samuel.audet at gmail.com  Wed Sep 25 10:35:06 2019
From: samuel.audet at gmail.com (Samuel Audet)
Date: Wed, 25 Sep 2019 19:35:06 +0900
Subject: [foreign-abi] On invokers
In-Reply-To: <38EF2152-43E5-464C-A66F-CE70B12B5164@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
 <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>
 <259447E3-19EC-49D3-BCB4-C20F0E5BF010@oracle.com>
 <821ff859-362e-6121-d4e3-4565ea4b7870@oracle.com>
 <38EF2152-43E5-464C-A66F-CE70B12B5164@oracle.com>
Message-ID: <cf501b0e-367f-f2a2-219a-c477b12d1290@gmail.com>

Hi, John,

I must say, I really like the work you guys are doing on the vector and 
ABI fronts, it's really great. I sincerely wish Panama could focus more 
on that instead of also working on higher-level framework-ish APIs.

I have one question though. Where are those "vigourous conversation" 
happening? I don't have any quarrel with the work being discussed on 
this thread, but it does give me the impression that a lot of the work 
related to Panama is done in secret and that we're not getting the full 
picture, about other things that I worry about like C++. If that's the 
case, that's fine, OpenJDK doesn't need to be "open", but it would help 
the community if you could be honest about it.

Samuel

On 9/25/19 9:25 AM, John Rose wrote:
> (*Mature*  non-generalization appears when you have a road map with an endpoint, so you can say things like,
> ?You might ask my API to do extra task X, but you should really use a different API for that.?  Folks vary by
> temperament which kind of premature-ness they are more likely to fall into.  Y'all know I?m an (a), so of course
> I?m always on the lookout for signs of (b), whether they exist or not.  The Vector API is currently having a
> vigourous conversation about such choices.)

From maurizio.cimadamore at oracle.com  Wed Sep 25 11:32:48 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 25 Sep 2019 12:32:48 +0100
Subject: [foreign-abi] On invokers
In-Reply-To: <cf501b0e-367f-f2a2-219a-c477b12d1290@gmail.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
 <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>
 <259447E3-19EC-49D3-BCB4-C20F0E5BF010@oracle.com>
 <821ff859-362e-6121-d4e3-4565ea4b7870@oracle.com>
 <38EF2152-43E5-464C-A66F-CE70B12B5164@oracle.com>
 <cf501b0e-367f-f2a2-219a-c477b12d1290@gmail.com>
Message-ID: <af290c98-647a-c27d-0af3-a0a54ff4ffb5@oracle.com>

I'd like to point out the irony of your comment: you are complaining 
about lack of transparency on a thread which is discussing future 
directions for SystemABI support (where the currently proposed patch 
only works for Windows, only for downcalls). Speaking about open-ness, I 
think this is pretty much the best you can get?

I will disregard your comment on "you should do X instead of Y" - which, 
as been pointed out previously, is not helpful, and I will also 
disregard your "framework-ish APIs" remark, which is deliberately 
inflammatory. I think we can do better than that?

As for vectors, I believe the discussion John is referring to 
happened/is happening on the CSR front:

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

(again, discussion publicly available).

And yes, there are times where, as normal people do, we need to stop and 
think about what we wanna do before starting a public debate on it. This 
is about the evolution of the Java platform, not about conducting 
opinion polls (although sometimes it helps to have dedicated surveys on 
specific topics, as we have done in the past [1]) - and it is a job that 
we take very seriously.

Maurizio

[1] - 
https://mail.openjdk.java.net/pipermail/amber-dev/2018-February/002669.html


On 25/09/2019 11:35, Samuel Audet wrote:
> Hi, John,
>
> I must say, I really like the work you guys are doing on the vector 
> and ABI fronts, it's really great. I sincerely wish Panama could focus 
> more on that instead of also working on higher-level framework-ish APIs.
>
> I have one question though. Where are those "vigourous conversation" 
> happening? I don't have any quarrel with the work being discussed on 
> this thread, but it does give me the impression that a lot of the work 
> related to Panama is done in secret and that we're not getting the 
> full picture, about other things that I worry about like C++. If 
> that's the case, that's fine, OpenJDK doesn't need to be "open", but 
> it would help the community if you could be honest about it.
>
> Samuel
>
> On 9/25/19 9:25 AM, John Rose wrote:
>> (*Mature*? non-generalization appears when you have a road map with 
>> an endpoint, so you can say things like,
>> ?You might ask my API to do extra task X, but you should really use a 
>> different API for that.?? Folks vary by
>> temperament which kind of premature-ness they are more likely to fall 
>> into.? Y'all know I?m an (a), so of course
>> I?m always on the lookout for signs of (b), whether they exist or 
>> not.? The Vector API is currently having a
>> vigourous conversation about such choices.)

From jorn.vernee at oracle.com  Wed Sep 25 11:53:21 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Wed, 25 Sep 2019 13:53:21 +0200
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
In-Reply-To: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
References: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
Message-ID: <e4be9b32-ab29-e6e1-18bb-ead4031cba8d@oracle.com>

Hi,

Patch looks good!

Some minor comments:

MemorySegment.java
 ? - Minor typo @58: "using the one of the provided factory methods"
 ? - You removed the SecurityManager check from ofByteBuffer. Isn't it 
needed?

Cheers,
Jorn

On 24/09/2019 16:06, Maurizio Cimadamore wrote:
> Hi,
> as the subject says, the implementation classes of the layout API do 
> not always store their properties into final fields, and they resort 
> to lazy computation, etc. This negatively impacts C2 scrutability of 
> same data structures.
>
> This patch fixes this situation, by changing size/alignment to be 
> final fields in AbstractLayout - so that they will have to be provided 
> before hand. I've added, for clarity, and extra 'default' constructor 
> to all layout implementation classes which allows to create a layout 
> with standard alignment and empty name.
>
> There are also few minor changes:
>
> * I've tweaked VM to also trust final fields in the layout package
>
> * I've rearranged some some scope classes so that their creation is 
> less straightforward, more transparent and requires less reflective 
> checks. This is particularly evident in HeapScope and BufferScope. 
> Note that I also changed the public API of MemorySegment::ofArray and 
> replaced that with multiple overloads (one per primitive array). This 
> is good because it makes the code more 'static' and also because it 
> removes the possibility for the user to pass in a wrong array type.
>
> * I've re-ordered the way in which scope vs. segment is created - that 
> is, instead of this
>
> new XYZSegment(.., ..., ..., new XYZScope(...))
>
> We now do this:
>
> XYZScope scope = new XYZScope(...);
> new XYZSegment(.., ..., ..., scope)
>
> As this makes a difference for C2 (Vlad pointed this out).
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8231402_v2/
>
>
> With this patch, the level of performances of the memory access API is 
> virtually on par with Unsafe in our suite of synthetic benchmarks, at 
> least when using the Graal compiler (*). With C2 there are still 
> issues which have to do mainly with (i) escape analysis not being 
> aggressive enough (a VM patch is required) and (ii) inlining not 
> working well in relatively 'cold' code (e.g. segment 
> creation/closure), so that some manual sprinkling of @ForceInline 
> annotations is? required. I will pursue these in a follow up patch.
>
> Maurizio
>
> (*) the only exception to this is a test which performs indexed 
> access, in which Graal compiler is not able to vectorize the loop when 
> using the memory access API (because of the presence of address 
> operation on longs); that said, performance of code compiled by the 
> Graal compiler with the memory access API is still superior than that 
> of C2 using unsafe (I'm also following up with the Graal compiler team 
> on this issue). There also seems to be an issue with the liveness 
> check which is never hoisted out of hot loops - leading to slightly 
> slower performances; in C2 we have a similar issue and it's caused by 
> the fact that the VM puts a memory barrier after Unsafe memory access 
> calls (since the Unsafe call could touch the loop invariant itself!). 
> We obviously need to relax some of these checks if the Unsafe call 
> occurs from within the memory access API (which does not allow 
> arbitrary read/write of Java fields).
>
>
>

From maurizio.cimadamore at oracle.com  Wed Sep 25 12:09:30 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 25 Sep 2019 13:09:30 +0100
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
In-Reply-To: <e4be9b32-ab29-e6e1-18bb-ead4031cba8d@oracle.com>
References: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
 <e4be9b32-ab29-e6e1-18bb-ead4031cba8d@oracle.com>
Message-ID: <814da627-60d9-6986-1b70-b0181a346652@oracle.com>


On 25/09/2019 12:53, Jorn Vernee wrote:
> Hi,
>
> Patch looks good!
>
> Some minor comments:
>
> MemorySegment.java
> ? - Minor typo @58: "using the one of the provided factory methods"
> ? - You removed the SecurityManager check from ofByteBuffer. Isn't it 
> needed?

my feeling/reasoning on the security check - the buffer has already been 
created - how creating another view is more 'insecure' ?

Maurizio

>
> Cheers,
> Jorn
>
> On 24/09/2019 16:06, Maurizio Cimadamore wrote:
>> Hi,
>> as the subject says, the implementation classes of the layout API do 
>> not always store their properties into final fields, and they resort 
>> to lazy computation, etc. This negatively impacts C2 scrutability of 
>> same data structures.
>>
>> This patch fixes this situation, by changing size/alignment to be 
>> final fields in AbstractLayout - so that they will have to be 
>> provided before hand. I've added, for clarity, and extra 'default' 
>> constructor to all layout implementation classes which allows to 
>> create a layout with standard alignment and empty name.
>>
>> There are also few minor changes:
>>
>> * I've tweaked VM to also trust final fields in the layout package
>>
>> * I've rearranged some some scope classes so that their creation is 
>> less straightforward, more transparent and requires less reflective 
>> checks. This is particularly evident in HeapScope and BufferScope. 
>> Note that I also changed the public API of MemorySegment::ofArray and 
>> replaced that with multiple overloads (one per primitive array). This 
>> is good because it makes the code more 'static' and also because it 
>> removes the possibility for the user to pass in a wrong array type.
>>
>> * I've re-ordered the way in which scope vs. segment is created - 
>> that is, instead of this
>>
>> new XYZSegment(.., ..., ..., new XYZScope(...))
>>
>> We now do this:
>>
>> XYZScope scope = new XYZScope(...);
>> new XYZSegment(.., ..., ..., scope)
>>
>> As this makes a difference for C2 (Vlad pointed this out).
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/8231402_v2/
>>
>>
>> With this patch, the level of performances of the memory access API 
>> is virtually on par with Unsafe in our suite of synthetic benchmarks, 
>> at least when using the Graal compiler (*). With C2 there are still 
>> issues which have to do mainly with (i) escape analysis not being 
>> aggressive enough (a VM patch is required) and (ii) inlining not 
>> working well in relatively 'cold' code (e.g. segment 
>> creation/closure), so that some manual sprinkling of @ForceInline 
>> annotations is? required. I will pursue these in a follow up patch.
>>
>> Maurizio
>>
>> (*) the only exception to this is a test which performs indexed 
>> access, in which Graal compiler is not able to vectorize the loop 
>> when using the memory access API (because of the presence of address 
>> operation on longs); that said, performance of code compiled by the 
>> Graal compiler with the memory access API is still superior than that 
>> of C2 using unsafe (I'm also following up with the Graal compiler 
>> team on this issue). There also seems to be an issue with the 
>> liveness check which is never hoisted out of hot loops - leading to 
>> slightly slower performances; in C2 we have a similar issue and it's 
>> caused by the fact that the VM puts a memory barrier after Unsafe 
>> memory access calls (since the Unsafe call could touch the loop 
>> invariant itself!). We obviously need to relax some of these checks 
>> if the Unsafe call occurs from within the memory access API (which 
>> does not allow arbitrary read/write of Java fields).
>>
>>
>>

From jorn.vernee at oracle.com  Wed Sep 25 13:28:03 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Wed, 25 Sep 2019 15:28:03 +0200
Subject: [foreign-memaccess] RFR 8231402: layout API implementation is not
 constant enough
In-Reply-To: <814da627-60d9-6986-1b70-b0181a346652@oracle.com>
References: <1a3c3c9e-4f7e-f58b-6a20-18889fd4cf7d@oracle.com>
 <e4be9b32-ab29-e6e1-18bb-ead4031cba8d@oracle.com>
 <814da627-60d9-6986-1b70-b0181a346652@oracle.com>
Message-ID: <1a3f701e-7034-dc66-c868-22e9edccbd89@oracle.com>


On 25/09/2019 14:09, Maurizio Cimadamore wrote:
>
> On 25/09/2019 12:53, Jorn Vernee wrote:
>> Hi,
>>
>> Patch looks good!
>>
>> Some minor comments:
>>
>> MemorySegment.java
>> ? - Minor typo @58: "using the one of the provided factory methods"
>> ? - You removed the SecurityManager check from ofByteBuffer. Isn't it 
>> needed?
>
> my feeling/reasoning on the security check - the buffer has already 
> been created - how creating another view is more 'insecure' ?

Ok. I was just wondering if this was something that got removed during 
testing and then forgotten to be added back :)

Jorn

>
> Maurizio
>
>>
>> Cheers,
>> Jorn
>>
>> On 24/09/2019 16:06, Maurizio Cimadamore wrote:
>>> Hi,
>>> as the subject says, the implementation classes of the layout API do 
>>> not always store their properties into final fields, and they resort 
>>> to lazy computation, etc. This negatively impacts C2 scrutability of 
>>> same data structures.
>>>
>>> This patch fixes this situation, by changing size/alignment to be 
>>> final fields in AbstractLayout - so that they will have to be 
>>> provided before hand. I've added, for clarity, and extra 'default' 
>>> constructor to all layout implementation classes which allows to 
>>> create a layout with standard alignment and empty name.
>>>
>>> There are also few minor changes:
>>>
>>> * I've tweaked VM to also trust final fields in the layout package
>>>
>>> * I've rearranged some some scope classes so that their creation is 
>>> less straightforward, more transparent and requires less reflective 
>>> checks. This is particularly evident in HeapScope and BufferScope. 
>>> Note that I also changed the public API of MemorySegment::ofArray 
>>> and replaced that with multiple overloads (one per primitive array). 
>>> This is good because it makes the code more 'static' and also 
>>> because it removes the possibility for the user to pass in a wrong 
>>> array type.
>>>
>>> * I've re-ordered the way in which scope vs. segment is created - 
>>> that is, instead of this
>>>
>>> new XYZSegment(.., ..., ..., new XYZScope(...))
>>>
>>> We now do this:
>>>
>>> XYZScope scope = new XYZScope(...);
>>> new XYZSegment(.., ..., ..., scope)
>>>
>>> As this makes a difference for C2 (Vlad pointed this out).
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/panama/8231402_v2/
>>>
>>>
>>> With this patch, the level of performances of the memory access API 
>>> is virtually on par with Unsafe in our suite of synthetic 
>>> benchmarks, at least when using the Graal compiler (*). With C2 
>>> there are still issues which have to do mainly with (i) escape 
>>> analysis not being aggressive enough (a VM patch is required) and 
>>> (ii) inlining not working well in relatively 'cold' code (e.g. 
>>> segment creation/closure), so that some manual sprinkling of 
>>> @ForceInline annotations is required. I will pursue these in a 
>>> follow up patch.
>>>
>>> Maurizio
>>>
>>> (*) the only exception to this is a test which performs indexed 
>>> access, in which Graal compiler is not able to vectorize the loop 
>>> when using the memory access API (because of the presence of address 
>>> operation on longs); that said, performance of code compiled by the 
>>> Graal compiler with the memory access API is still superior than 
>>> that of C2 using unsafe (I'm also following up with the Graal 
>>> compiler team on this issue). There also seems to be an issue with 
>>> the liveness check which is never hoisted out of hot loops - leading 
>>> to slightly slower performances; in C2 we have a similar issue and 
>>> it's caused by the fact that the VM puts a memory barrier after 
>>> Unsafe memory access calls (since the Unsafe call could touch the 
>>> loop invariant itself!). We obviously need to relax some of these 
>>> checks if the Unsafe call occurs from within the memory access API 
>>> (which does not allow arbitrary read/write of Java fields).
>>>
>>>
>>>

From maurizio.cimadamore at oracle.com  Wed Sep 25 22:04:08 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 25 Sep 2019 22:04:08 +0000
Subject: hg: panama/dev: 98 new changesets
Message-ID: <201909252204.x8PM4Flt025911@aojmv0008.oracle.com>

Changeset: 778fc2dcbdaa
Author:    dcubed
Date:      2019-09-18 20:49 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/778fc2dcbdaa

8231210: [BACKOUT] JDK-8207266 ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread
Reviewed-by: phh, dholmes

! src/hotspot/share/include/jmm.h
! src/hotspot/share/services/management.cpp
! src/java.management/share/classes/java/lang/management/ThreadMXBean.java
! src/java.management/share/classes/sun/management/ThreadImpl.java
! src/java.management/share/native/libmanagement/ThreadImpl.c
! src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java
! src/jdk.management/share/classes/com/sun/management/internal/HotSpotThreadImpl.java
! test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java

Changeset: 94f71d633542
Author:    jwilhelm
Date:      2019-09-19 00:19 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/94f71d633542

Added tag jdk-14+15 for changeset 778fc2dcbdaa

! .hgtags

Changeset: 4eebb9aadbe3
Author:    shade
Date:      2019-09-19 09:50 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/4eebb9aadbe3

8231201: hs_err should print coalesced safepoint operations in Events section
Reviewed-by: phh, dholmes

! src/hotspot/share/runtime/vmThread.cpp

Changeset: 408c445d04e8
Author:    rehn
Date:      2019-09-19 10:52 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/408c445d04e8

8226705: [REDO] Deoptimize with handshakes
Reviewed-by: eosterlund, dcubed, dlong, pchilanomate

! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/aot/aotCompiledMethod.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/compiledMethod.cpp
! src/hotspot/share/code/compiledMethod.hpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp
! src/hotspot/share/gc/z/zNMethod.cpp
! src/hotspot/share/jvmci/jvmciEnv.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/prims/jvmtiEventController.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/biasedLocking.cpp
! src/hotspot/share/runtime/biasedLocking.hpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/deoptimization.hpp
! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/tieredThresholdPolicy.cpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/services/dtraceAttacher.cpp
+ test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java

Changeset: 722a19a45994
Author:    pliden
Date:      2019-09-19 16:05 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/722a19a45994

8231113: Remove CollectedHeap::check_oop_location()
Reviewed-by: stefank, eosterlund, tschatzl

! src/hotspot/share/gc/cms/cmsHeap.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/serial/markSweep.inline.hpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zCollectedHeap.hpp
! src/hotspot/share/oops/compressedOops.inline.hpp
! src/hotspot/share/oops/oop.cpp

Changeset: 0ff1aeedc338
Author:    joehw
Date:      2019-09-19 16:53 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/0ff1aeedc338

8230814: Enable SAX ContentHandler to handle XML Declaration
Reviewed-by: lancea, dfuchs, alanb

! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java
! src/java.xml/share/classes/org/xml/sax/ContentHandler.java
+ test/jaxp/javax/xml/jaxp/unittest/sax/DeclarationTest.java

Changeset: 13e041be4e5c
Author:    shade
Date:      2019-09-19 20:26 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/13e041be4e5c

8231197: Shenandoah: JVMTI heap walking cleanup crashes with NULL forwardee
Reviewed-by: zgu, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: de9d23469c68
Author:    shade
Date:      2019-09-19 20:26 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/de9d23469c68

8231198: Shenandoah: heap walking should visit all roots most of the time
Reviewed-by: zgu, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 89033e6641ed
Author:    shade
Date:      2019-09-19 20:26 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/89033e6641ed

8231244: Shenandoah: all-roots heap walking misses some weak roots
Reviewed-by: zgu, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp

Changeset: 0cc0fd308822
Author:    bpb
Date:      2019-09-19 12:01 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/0cc0fd308822

8231149: (fs) Small verbiage errors in java.nio.file package documentation
Reviewed-by: lancea, alanb

! src/java.base/share/classes/java/nio/file/package-info.java

Changeset: 932b94295034
Author:    stefank
Date:      2019-09-10 17:07 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/932b94295034

8230756: ZGC: Remove redundant memset in ZStatValue
Reviewed-by: tschatzl, pliden

! src/hotspot/share/gc/z/zStat.cpp

Changeset: 312126722609
Author:    stefank
Date:      2019-09-10 17:07 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/312126722609

8230758: ZGC: Add missing precompiled include and fix friend declaration
Reviewed-by: tschatzl, pliden

! src/hotspot/share/gc/z/zForwardingEntry.hpp
! src/hotspot/share/gc/z/zNUMA.cpp

Changeset: 944b58cbaf93
Author:    stefank
Date:      2019-09-11 09:47 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/944b58cbaf93

8230759: ZGC: Fix integer types
Reviewed-by: pliden

! src/hotspot/share/gc/z/zAttachedArray.hpp
! src/hotspot/share/gc/z/zAttachedArray.inline.hpp
! src/hotspot/share/gc/z/zForwarding.cpp
! src/hotspot/share/gc/z/zForwarding.hpp
! src/hotspot/share/gc/z/zForwarding.inline.hpp
! src/hotspot/share/gc/z/zNMethodData.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zUncommitter.cpp
! test/hotspot/gtest/gc/z/test_zForwarding.cpp

Changeset: 3386b9a8ef4d
Author:    redestad
Date:      2019-09-19 23:38 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/3386b9a8ef4d

8230768: Arrays of SoftReferences in MethodTypeForm should not be @Stable
Reviewed-by: mchung

! src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java

Changeset: 046533575954
Author:    cito
Date:      2019-01-26 15:47 +0900
URL:       https://hg.openjdk.java.net/panama/dev/rev/046533575954

8216565: Specifying the same path creates a new directory in JFR.configure
Reviewed-by: ysuenaga, egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
! test/jdk/jdk/jfr/jcmd/TestJcmdConfigure.java

Changeset: 33de7752835c
Author:    tschatzl
Date:      2019-09-20 11:33 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/33de7752835c

8231242: G1CollectedHeap::print_regions_on() does not print description for "OA" and "CA" regions
Reviewed-by: tschatzl, jiangli
Contributed-by: huangjia at loongson.cn

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: 94bb65cb37d3
Author:    jboes
Date:      2019-09-20 11:07 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/94bb65cb37d3

8230648: Replace @exception tag with @throws in java.base
Summary: Minor coding style update of javadoc tag in any file in java.base
Reviewed-by: prappo, lancea

! src/java.base/share/classes/java/io/BufferedInputStream.java
! src/java.base/share/classes/java/io/BufferedOutputStream.java
! src/java.base/share/classes/java/io/BufferedReader.java
! src/java.base/share/classes/java/io/BufferedWriter.java
! src/java.base/share/classes/java/io/CharArrayReader.java
! src/java.base/share/classes/java/io/CharArrayWriter.java
! src/java.base/share/classes/java/io/DataInput.java
! src/java.base/share/classes/java/io/DataInputStream.java
! src/java.base/share/classes/java/io/DataOutputStream.java
! src/java.base/share/classes/java/io/Externalizable.java
! src/java.base/share/classes/java/io/FileDescriptor.java
! src/java.base/share/classes/java/io/FileInputStream.java
! src/java.base/share/classes/java/io/FileOutputStream.java
! src/java.base/share/classes/java/io/FilePermission.java
! src/java.base/share/classes/java/io/FileReader.java
! src/java.base/share/classes/java/io/FilterInputStream.java
! src/java.base/share/classes/java/io/FilterOutputStream.java
! src/java.base/share/classes/java/io/FilterReader.java
! src/java.base/share/classes/java/io/FilterWriter.java
! src/java.base/share/classes/java/io/InputStream.java
! src/java.base/share/classes/java/io/InputStreamReader.java
! src/java.base/share/classes/java/io/LineNumberInputStream.java
! src/java.base/share/classes/java/io/ObjectInput.java
! src/java.base/share/classes/java/io/ObjectInputValidation.java
! src/java.base/share/classes/java/io/ObjectOutput.java
! src/java.base/share/classes/java/io/OutputStream.java
! src/java.base/share/classes/java/io/OutputStreamWriter.java
! src/java.base/share/classes/java/io/PipedInputStream.java
! src/java.base/share/classes/java/io/PipedOutputStream.java
! src/java.base/share/classes/java/io/PipedReader.java
! src/java.base/share/classes/java/io/PipedWriter.java
! src/java.base/share/classes/java/io/PushbackInputStream.java
! src/java.base/share/classes/java/io/PushbackReader.java
! src/java.base/share/classes/java/io/RandomAccessFile.java
! src/java.base/share/classes/java/io/Reader.java
! src/java.base/share/classes/java/io/SequenceInputStream.java
! src/java.base/share/classes/java/io/StreamTokenizer.java
! src/java.base/share/classes/java/io/StringReader.java
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Package.java
! src/java.base/share/classes/java/lang/ProcessHandleImpl.java
! src/java.base/share/classes/java/lang/SecurityManager.java
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleInfo.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/VarForm.java
! src/java.base/share/classes/java/lang/reflect/Array.java
! src/java.base/share/classes/java/lang/reflect/Constructor.java
! src/java.base/share/classes/java/lang/reflect/Field.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/net/ContentHandler.java
! src/java.base/share/classes/java/net/DatagramPacket.java
! src/java.base/share/classes/java/net/DatagramSocket.java
! src/java.base/share/classes/java/net/DatagramSocketImpl.java
! src/java.base/share/classes/java/net/HttpURLConnection.java
! src/java.base/share/classes/java/net/InetAddress.java
! src/java.base/share/classes/java/net/JarURLConnection.java
! src/java.base/share/classes/java/net/MulticastSocket.java
! src/java.base/share/classes/java/net/NetworkInterface.java
! src/java.base/share/classes/java/net/ProxySelector.java
! src/java.base/share/classes/java/net/ServerSocket.java
! src/java.base/share/classes/java/net/Socket.java
! src/java.base/share/classes/java/net/SocketImpl.java
! src/java.base/share/classes/java/net/SocketInputStream.java
! src/java.base/share/classes/java/net/SocketOptions.java
! src/java.base/share/classes/java/net/SocketOutputStream.java
! src/java.base/share/classes/java/net/SocketPermission.java
! src/java.base/share/classes/java/net/URL.java
! src/java.base/share/classes/java/net/URLClassLoader.java
! src/java.base/share/classes/java/net/URLConnection.java
! src/java.base/share/classes/java/net/URLPermission.java
! src/java.base/share/classes/java/net/URLStreamHandler.java
! src/java.base/share/classes/java/nio/Buffer.java
! src/java.base/share/classes/java/nio/MappedByteBuffer.java
! src/java.base/share/classes/java/security/AccessControlContext.java
! src/java.base/share/classes/java/security/AccessController.java
! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java
! src/java.base/share/classes/java/security/AlgorithmParameterGeneratorSpi.java
! src/java.base/share/classes/java/security/AlgorithmParameters.java
! src/java.base/share/classes/java/security/AlgorithmParametersSpi.java
! src/java.base/share/classes/java/security/AllPermission.java
! src/java.base/share/classes/java/security/BasicPermission.java
! src/java.base/share/classes/java/security/Certificate.java
! src/java.base/share/classes/java/security/DigestInputStream.java
! src/java.base/share/classes/java/security/DigestOutputStream.java
! src/java.base/share/classes/java/security/DomainLoadStoreParameter.java
! src/java.base/share/classes/java/security/Guard.java
! src/java.base/share/classes/java/security/GuardedObject.java
! src/java.base/share/classes/java/security/Identity.java
! src/java.base/share/classes/java/security/IdentityScope.java
! src/java.base/share/classes/java/security/KeyFactory.java
! src/java.base/share/classes/java/security/KeyFactorySpi.java
! src/java.base/share/classes/java/security/KeyPairGenerator.java
! src/java.base/share/classes/java/security/KeyPairGeneratorSpi.java
! src/java.base/share/classes/java/security/KeyRep.java
! src/java.base/share/classes/java/security/KeyStore.java
! src/java.base/share/classes/java/security/KeyStoreSpi.java
! src/java.base/share/classes/java/security/MessageDigest.java
! src/java.base/share/classes/java/security/MessageDigestSpi.java
! src/java.base/share/classes/java/security/PKCS12Attribute.java
! src/java.base/share/classes/java/security/PermissionCollection.java
! src/java.base/share/classes/java/security/Permissions.java
! src/java.base/share/classes/java/security/Policy.java
! src/java.base/share/classes/java/security/Provider.java
! src/java.base/share/classes/java/security/SecureClassLoader.java
! src/java.base/share/classes/java/security/Signature.java
! src/java.base/share/classes/java/security/SignatureSpi.java
! src/java.base/share/classes/java/security/SignedObject.java
! src/java.base/share/classes/java/security/Signer.java
! src/java.base/share/classes/java/security/URIParameter.java
! src/java.base/share/classes/java/security/cert/CertPath.java
! src/java.base/share/classes/java/security/cert/CertPathValidator.java
! src/java.base/share/classes/java/security/cert/CertPathValidatorSpi.java
! src/java.base/share/classes/java/security/cert/Certificate.java
! src/java.base/share/classes/java/security/cert/CertificateFactory.java
! src/java.base/share/classes/java/security/cert/CertificateFactorySpi.java
! src/java.base/share/classes/java/security/cert/CollectionCertStoreParameters.java
! src/java.base/share/classes/java/security/cert/Extension.java
! src/java.base/share/classes/java/security/cert/LDAPCertStoreParameters.java
! src/java.base/share/classes/java/security/cert/PKIXCertPathChecker.java
! src/java.base/share/classes/java/security/cert/PolicyQualifierInfo.java
! src/java.base/share/classes/java/security/cert/X509CRL.java
! src/java.base/share/classes/java/security/cert/X509CRLEntry.java
! src/java.base/share/classes/java/security/cert/X509Certificate.java
! src/java.base/share/classes/java/security/interfaces/DSAKeyPairGenerator.java
! src/java.base/share/classes/java/security/spec/DSAGenParameterSpec.java
! src/java.base/share/classes/java/security/spec/ECFieldF2m.java
! src/java.base/share/classes/java/security/spec/ECFieldFp.java
! src/java.base/share/classes/java/security/spec/ECParameterSpec.java
! src/java.base/share/classes/java/security/spec/ECPoint.java
! src/java.base/share/classes/java/security/spec/ECPrivateKeySpec.java
! src/java.base/share/classes/java/security/spec/ECPublicKeySpec.java
! src/java.base/share/classes/java/security/spec/EllipticCurve.java
! src/java.base/share/classes/java/security/spec/MGF1ParameterSpec.java
! src/java.base/share/classes/java/security/spec/PSSParameterSpec.java
! src/java.base/share/classes/java/security/spec/RSAOtherPrimeInfo.java
! src/java.base/share/classes/java/text/AttributedString.java
! src/java.base/share/classes/java/text/BreakIterator.java
! src/java.base/share/classes/java/text/ChoiceFormat.java
! src/java.base/share/classes/java/text/CollationKey.java
! src/java.base/share/classes/java/text/Collator.java
! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DateFormat.java
! src/java.base/share/classes/java/text/DateFormatSymbols.java
! src/java.base/share/classes/java/text/DecimalFormat.java
! src/java.base/share/classes/java/text/DecimalFormatSymbols.java
! src/java.base/share/classes/java/text/DigitList.java
! src/java.base/share/classes/java/text/Format.java
! src/java.base/share/classes/java/text/MergeCollation.java
! src/java.base/share/classes/java/text/MessageFormat.java
! src/java.base/share/classes/java/text/NumberFormat.java
! src/java.base/share/classes/java/text/RBTableBuilder.java
! src/java.base/share/classes/java/text/RuleBasedCollator.java
! src/java.base/share/classes/java/text/SimpleDateFormat.java
! src/java.base/share/classes/java/text/spi/BreakIteratorProvider.java
! src/java.base/share/classes/java/text/spi/CollatorProvider.java
! src/java.base/share/classes/java/text/spi/DateFormatProvider.java
! src/java.base/share/classes/java/text/spi/DateFormatSymbolsProvider.java
! src/java.base/share/classes/java/text/spi/DecimalFormatSymbolsProvider.java
! src/java.base/share/classes/java/text/spi/NumberFormatProvider.java
! src/java.base/share/classes/java/util/Calendar.java
! src/java.base/share/classes/java/util/Currency.java
! src/java.base/share/classes/java/util/Date.java
! src/java.base/share/classes/java/util/Dictionary.java
! src/java.base/share/classes/java/util/Enumeration.java
! src/java.base/share/classes/java/util/GregorianCalendar.java
! src/java.base/share/classes/java/util/Hashtable.java
! src/java.base/share/classes/java/util/JapaneseImperialCalendar.java
! src/java.base/share/classes/java/util/Locale.java
! src/java.base/share/classes/java/util/Properties.java
! src/java.base/share/classes/java/util/PropertyPermission.java
! src/java.base/share/classes/java/util/ResourceBundle.java
! src/java.base/share/classes/java/util/SimpleTimeZone.java
! src/java.base/share/classes/java/util/StringTokenizer.java
! src/java.base/share/classes/java/util/TimeZone.java
! src/java.base/share/classes/java/util/jar/Attributes.java
! src/java.base/share/classes/java/util/jar/JarEntry.java
! src/java.base/share/classes/java/util/jar/JarInputStream.java
! src/java.base/share/classes/java/util/jar/JarOutputStream.java
! src/java.base/share/classes/java/util/jar/Manifest.java
! src/java.base/share/classes/java/util/jar/Pack200.java
! src/java.base/share/classes/java/util/regex/Matcher.java
! src/java.base/share/classes/java/util/spi/CurrencyNameProvider.java
! src/java.base/share/classes/java/util/spi/LocaleNameProvider.java
! src/java.base/share/classes/java/util/spi/TimeZoneNameProvider.java
! src/java.base/share/classes/java/util/zip/CheckedInputStream.java
! src/java.base/share/classes/java/util/zip/CheckedOutputStream.java
! src/java.base/share/classes/java/util/zip/Deflater.java
! src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java
! src/java.base/share/classes/java/util/zip/GZIPInputStream.java
! src/java.base/share/classes/java/util/zip/GZIPOutputStream.java
! src/java.base/share/classes/java/util/zip/InflaterInputStream.java
! src/java.base/share/classes/java/util/zip/ZipInputStream.java
! src/java.base/share/classes/java/util/zip/ZipOutputStream.java

Changeset: c67f514fdd54
Author:    coleenp
Date:      2019-09-20 10:23 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/c67f514fdd54

8225628: Remove unused Thread::muxAcquireW function
Reviewed-by: dcubed, hseigel

! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: da8673f61e94
Author:    darcy
Date:      2019-09-20 09:32 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/da8673f61e94

8199424: consider removing ObjectInputStream and ObjectOutputStream native methods
Reviewed-by: bpb, rriggs, redestad

! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/io/ObjectOutputStream.java
- src/java.base/share/native/libjava/ObjectInputStream.c
- src/java.base/share/native/libjava/ObjectOutputStream.c

Changeset: bff49841aabe
Author:    lmesnik
Date:      2019-09-20 13:14 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/bff49841aabe

8229853: Problemlist compiler/codecache/jmx/PoolsIndependenceTest.java
Reviewed-by: thartmann

! test/hotspot/jtreg/ProblemList.txt

Changeset: 3c8f89e2ec03
Author:    valeriep
Date:      2019-09-20 21:33 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/3c8f89e2ec03

8176837: SunPKCS11 provider needs to check more details on PKCS11 Mechanism
Summary: Disable mechanisms with partial support, e.g. can decrypt but cannot encrypt
Reviewed-by: xuelei

! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java

Changeset: 3aef3bccfae3
Author:    joehw
Date:      2019-09-20 22:11 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/3aef3bccfae3

8231083: Clarify SAX documentation
Reviewed-by: lancea, alanb

! src/java.xml/share/classes/org/xml/sax/AttributeList.java
! src/java.xml/share/classes/org/xml/sax/Attributes.java
! src/java.xml/share/classes/org/xml/sax/ContentHandler.java
! src/java.xml/share/classes/org/xml/sax/DTDHandler.java
! src/java.xml/share/classes/org/xml/sax/DocumentHandler.java
! src/java.xml/share/classes/org/xml/sax/EntityResolver.java
! src/java.xml/share/classes/org/xml/sax/ErrorHandler.java
! src/java.xml/share/classes/org/xml/sax/HandlerBase.java
! src/java.xml/share/classes/org/xml/sax/InputSource.java
! src/java.xml/share/classes/org/xml/sax/Locator.java
! src/java.xml/share/classes/org/xml/sax/Parser.java
! src/java.xml/share/classes/org/xml/sax/SAXException.java
! src/java.xml/share/classes/org/xml/sax/SAXNotRecognizedException.java
! src/java.xml/share/classes/org/xml/sax/SAXNotSupportedException.java
! src/java.xml/share/classes/org/xml/sax/SAXParseException.java
! src/java.xml/share/classes/org/xml/sax/XMLFilter.java
! src/java.xml/share/classes/org/xml/sax/XMLReader.java
! src/java.xml/share/classes/org/xml/sax/ext/Attributes2.java
! src/java.xml/share/classes/org/xml/sax/ext/Attributes2Impl.java
! src/java.xml/share/classes/org/xml/sax/ext/DeclHandler.java
! src/java.xml/share/classes/org/xml/sax/ext/DefaultHandler2.java
! src/java.xml/share/classes/org/xml/sax/ext/EntityResolver2.java
! src/java.xml/share/classes/org/xml/sax/ext/LexicalHandler.java
! src/java.xml/share/classes/org/xml/sax/ext/Locator2.java
! src/java.xml/share/classes/org/xml/sax/ext/Locator2Impl.java
! src/java.xml/share/classes/org/xml/sax/ext/package-info.java
! src/java.xml/share/classes/org/xml/sax/helpers/AttributeListImpl.java
! src/java.xml/share/classes/org/xml/sax/helpers/AttributesImpl.java
! src/java.xml/share/classes/org/xml/sax/helpers/DefaultHandler.java
! src/java.xml/share/classes/org/xml/sax/helpers/LocatorImpl.java
! src/java.xml/share/classes/org/xml/sax/helpers/NamespaceSupport.java
! src/java.xml/share/classes/org/xml/sax/helpers/NewInstance.java
! src/java.xml/share/classes/org/xml/sax/helpers/ParserAdapter.java
! src/java.xml/share/classes/org/xml/sax/helpers/ParserFactory.java
! src/java.xml/share/classes/org/xml/sax/helpers/XMLFilterImpl.java
! src/java.xml/share/classes/org/xml/sax/helpers/XMLReaderAdapter.java
! src/java.xml/share/classes/org/xml/sax/helpers/XMLReaderFactory.java
! src/java.xml/share/classes/org/xml/sax/helpers/package-info.java
! src/java.xml/share/classes/org/xml/sax/package-info.java

Changeset: e6231dbaa862
Author:    jjiang
Date:      2019-09-21 08:06 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/e6231dbaa862

8180837: SunPKCS11-NSS tests failing with CKR_ATTRIBUTE_READ_ONLY and CKR_MECHANISM_PARAM_INVALID
Reviewed-by: xuelei

! test/jdk/ProblemList.txt
! test/jdk/sun/security/pkcs11/PKCS11Test.java
! test/jdk/sun/security/pkcs11/Secmod/AddTrustedCert.java
! test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java

Changeset: 14c1ff687621
Author:    dcubed
Date:      2019-09-21 10:13 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/14c1ff687621

8231323: ProblemList jdk/jfr/jcmd/TestJcmdConfigure.java
Reviewed-by: ysuenaga

! test/jdk/ProblemList.txt

Changeset: 704e4ff399a2
Author:    iklam
Date:      2019-09-22 17:16 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/704e4ff399a2

8231125: Improve testing of parallel loading of shared classes by the boot class loader
Reviewed-by: ccheung, coleenp, dholmes

! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/oops/klass.hpp
! test/hotspot/jtreg/runtime/cds/appcds/ParallelLoadTest.java
! test/hotspot/jtreg/runtime/cds/appcds/test-classes/ParallelLoad.java

Changeset: 01c5971b0a2c
Author:    iklam
Date:      2019-09-22 17:17 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/01c5971b0a2c

8231275: Remove null check in the beginning of SystemDictionary::load_shared_class()
Reviewed-by: ccheung, coleenp

! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 001153ffc143
Author:    tschatzl
Date:      2019-09-23 11:36 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/001153ffc143

8231117: Remove G1EvacuationRootClosures::raw_strong_oops()
Reviewed-by: kbarrett, sjohanss

! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1RootClosures.cpp
! src/hotspot/share/gc/g1/g1RootClosures.hpp

Changeset: 4fbc534fdf69
Author:    tschatzl
Date:      2019-09-23 11:37 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/4fbc534fdf69

8159984: Remove call to ClassLoaderDataGraph::clear_claimed_marks during the initial mark pause
Summary: The CLDG is only iterated once during garbage collection, so we do not need to claim CLDs any more.
Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
! src/hotspot/share/gc/g1/g1OopClosures.cpp
! src/hotspot/share/gc/g1/g1OopClosures.hpp
! src/hotspot/share/gc/g1/g1RootClosures.cpp
! src/hotspot/share/gc/g1/g1RootClosures.hpp
! src/hotspot/share/gc/g1/g1RootProcessor.cpp
! src/hotspot/share/gc/g1/g1RootProcessor.hpp
! src/hotspot/share/gc/g1/g1SharedClosures.hpp
! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java
! test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java

Changeset: 4e96939a5746
Author:    tschatzl
Date:      2019-09-23 11:37 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/4e96939a5746

8231189: Rename worker_i parameters to worker_id
Reviewed-by: kbarrett, sjohanss

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
! src/hotspot/share/gc/g1/g1HotCardCache.cpp
! src/hotspot/share/gc/g1/g1HotCardCache.hpp
! src/hotspot/share/gc/g1/g1OopClosures.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1RemSet.hpp
! src/hotspot/share/gc/g1/g1RootProcessor.cpp
! src/hotspot/share/gc/g1/g1RootProcessor.hpp

Changeset: 577e17cab93f
Author:    clanger
Date:      2019-09-23 12:32 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/577e17cab93f

8230857: Avoid reflection in sun.tools.common.ProcessHelper
Reviewed-by: sspitsyn, dholmes

- src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java
+ src/jdk.jcmd/linux/classes/sun/tools/common/ProcessHelper.java
! src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java
! src/jdk.jcmd/share/classes/sun/tools/common/ProcessHelper.java
! test/jdk/sun/tools/jcmd/TestProcessHelper.java

Changeset: 501df37ce76b
Author:    zgu
Date:      2019-09-23 07:45 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/501df37ce76b

8231293: Shenandoah: Traversal should not revive dead weak roots
Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp

Changeset: acc7ea6bf0b4
Author:    thartmann
Date:      2019-09-23 14:30 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/acc7ea6bf0b4

8231058: VerifyOops crashes with assert(_offset >= 0) failed: offset for non comment?
Summary: Offset method should only be called for comments.
Reviewed-by: roland, dholmes

! src/hotspot/share/asm/codeBuffer.cpp
+ test/hotspot/jtreg/runtime/CheckUnhandledOops/TestVerifyOops.java

Changeset: bc696d87d032
Author:    shade
Date:      2019-09-23 16:24 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/bc696d87d032

8231249: Shenandoah: GC retries are too aggressive for tests that expect OOME
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 7a8de392f9e1
Author:    erikj
Date:      2019-09-23 09:00 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/7a8de392f9e1

8150741: make <module> not equivalent to make <module-dependencies> <module>
Reviewed-by: mchung

! make/Main.gmk

Changeset: 2921ee5e9881
Author:    erikj
Date:      2019-09-23 08:52 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/2921ee5e9881

8206125: [windows] cannot pass relative path to --with-boot-jdk
Reviewed-by: tbell

! make/autoconf/basics.m4
! make/autoconf/basics_windows.m4

Changeset: e27564cd10e3
Author:    zgu
Date:      2019-09-23 14:39 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/e27564cd10e3

8231250: Shenandoah: Traversal GC should keep alive weak load from heap
Reviewed-by: rkennke

! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp

Changeset: 08a5148e7c4e
Author:    lfoltan
Date:      2019-09-23 14:49 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/08a5148e7c4e

8230505: Replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type
Summary: Consistently use is_reference_type when comparing type for T_OBJECT or T_ARRAY.
Reviewed-by: dlong, coleenp, hseigel
Contributed-by: lois.foltan at oracle.com, john.r.rose at oracle.com

! src/hotspot/cpu/aarch64/c1_FrameMap_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shared/modRefBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/sparc/c1_FrameMap_sparc.cpp
! src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp
! src/hotspot/cpu/sparc/c1_LIRGenerator_sparc.cpp
! src/hotspot/cpu/sparc/gc/g1/g1BarrierSetAssembler_sparc.cpp
! src/hotspot/cpu/sparc/gc/shared/modRefBarrierSetAssembler_sparc.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/x86/c1_FrameMap_x86.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Optimizer.cpp
! src/hotspot/share/ci/bcEscapeAnalyzer.cpp
! src/hotspot/share/ci/ciArray.cpp
! src/hotspot/share/ci/ciConstant.cpp
! src/hotspot/share/ci/ciConstant.hpp
! src/hotspot/share/ci/ciField.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/ci/ciType.cpp
! src/hotspot/share/ci/ciType.hpp
! src/hotspot/share/ci/ciTypeFlow.cpp
! src/hotspot/share/classfile/bytecodeAssembler.cpp
! src/hotspot/share/gc/shared/c1/barrierSetC1.hpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.hpp
! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp
! src/hotspot/share/gc/z/zBarrierSet.cpp
! src/hotspot/share/interpreter/bytecodeTracer.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/memory/heapShared.cpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/oops/methodData.cpp
! src/hotspot/share/opto/arraycopynode.cpp
! src/hotspot/share/opto/doCall.cpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/macroArrayCopy.cpp
! src/hotspot/share/opto/parse3.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/runtime/fieldDescriptor.cpp
! src/hotspot/share/runtime/frame.cpp
! src/hotspot/share/runtime/javaCalls.cpp
! src/hotspot/share/runtime/reflection.cpp

Changeset: 71f50513d5e6
Author:    shade
Date:      2019-09-23 21:46 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/71f50513d5e6

8231375: AArch64 build failure after JDK-8230505
Reviewed-by: dcubed

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp

Changeset: 2dedeaa537a2
Author:    erikj
Date:      2019-09-23 12:56 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/2dedeaa537a2

8210794: Incorrect escaping of  in native test libraries
Reviewed-by: tbell

! make/common/TestFilesCompilation.gmk

Changeset: 1e57d3774190
Author:    bpb
Date:      2019-09-23 13:59 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/1e57d3774190

8231254: (fs) Add test for macOS Catalina changes to protect system software
Reviewed-by: alanb

+ test/jdk/java/nio/file/etc/MacVolumesTest.java

Changeset: 00a98f0aa1b3
Author:    iklam
Date:      2019-09-23 19:54 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/00a98f0aa1b3

8231257: Avoid calling FileMapInfo::write_region twice
Reviewed-by: ccheung

! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/filemap.hpp
! src/hotspot/share/memory/metaspaceShared.cpp

Changeset: e47b459b315c
Author:    iklam
Date:      2019-09-23 19:55 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/e47b459b315c

8231278: Rename FileMapHeader::_read_only_tables_start to _serialized_data_start
Reviewed-by: ccheung

! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/filemap.hpp
! src/hotspot/share/memory/metaspaceShared.cpp

Changeset: 448fe2bfd505
Author:    rehn
Date:      2019-09-24 08:54 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/448fe2bfd505

8229778: TestJstatdDefaults.java failed due to "fatal error: LEAF method calling lock?"
Reviewed-by: dholmes, dcubed

! src/hotspot/share/runtime/thread.cpp

Changeset: ef8c8cf9256a
Author:    mbaesken
Date:      2019-09-20 10:28 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/ef8c8cf9256a

8231171: remove remaining sun.java.launcher.pid references
Reviewed-by: alanb, dholmes

! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/arguments.hpp
! src/java.base/macosx/native/libjli/java_md_macosx.m
! src/java.base/share/native/libjli/java.c
! src/java.base/share/native/libjli/java.h
! src/java.base/unix/native/libjli/java_md_solinux.c
! src/java.base/windows/native/libjli/java_md.c
! test/jdk/tools/launcher/TestSpecialArgs.java

Changeset: 49836127542b
Author:    mbaesken
Date:      2019-09-23 17:02 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/49836127542b

8231222: fix pkcs11 P11_DEBUG guarded native traces
Reviewed-by: clanger

! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_convert.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_general.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_sessmgmt.c
! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c

Changeset: 03fce7b04b42
Author:    dholmes
Date:      2019-09-24 03:28 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/03fce7b04b42

8230395: Code checks for NULL value returned from NEW_C_HEAP_ARRAY which can not happen
Reviewed-by: lkorinth, hseigel, thartmann, dnsimon

! src/hotspot/os/aix/os_perf_aix.cpp
! src/hotspot/os/bsd/os_perf_bsd.cpp
! src/hotspot/os/linux/os_perf_linux.cpp
! src/hotspot/os/solaris/os_perf_solaris.cpp
! src/hotspot/os/windows/os_perf_windows.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/aot/aotLoader.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java

Changeset: cdce40c3286f
Author:    shade
Date:      2019-09-24 09:38 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/cdce40c3286f

8231395: Backout JDK-8231249
Reviewed-by: tschatzl

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 59f7c242ccb8
Author:    rpatil
Date:      2019-09-24 10:16 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/59f7c242ccb8

8231098: (tz) Upgrade time-zone data to tzdata2019c
Reviewed-by: martin, naoto

! make/data/tzdata/VERSION
! make/data/tzdata/asia
! make/data/tzdata/australasia
! make/data/tzdata/europe
! make/data/tzdata/leapseconds
! make/data/tzdata/northamerica
! make/data/tzdata/southamerica

Changeset: 1182ff8929cc
Author:    roland
Date:      2019-08-28 15:51 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/1182ff8929cc

8230061: # assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node
Reviewed-by: thartmann, neliasso

! src/hotspot/share/opto/loopopts.cpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp
+ test/hotspot/jtreg/compiler/loopstripmining/DeadNodesInOuterLoopAtLoopCloning.java

Changeset: e4d90117c5de
Author:    hannesw
Date:      2019-09-24 11:49 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/e4d90117c5de

8231122: @index tag with newline causes tag search to fail
Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java
! test/langtools/jdk/javadoc/doclet/testSearchScript/TestSearchScript.java
! test/langtools/jdk/javadoc/doclet/testSearchScript/listpkg/Nolist.java
! test/langtools/jdk/javadoc/doclet/testSearchScript/mapmodule/mappkg/Map.java

Changeset: a7f16447085e
Author:    eosterlund
Date:      2019-09-24 10:04 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/a7f16447085e

8224820: ZGC: Support discontiguous heap reservations
Reviewed-by: pliden, stefank

- src/hotspot/os/linux/gc/z/zVirtualMemory_linux.cpp
+ src/hotspot/os/posix/gc/z/zVirtualMemory_posix.cpp
! src/hotspot/share/gc/z/zPageAllocator.cpp
! src/hotspot/share/gc/z/zVirtualMemory.cpp
! src/hotspot/share/gc/z/zVirtualMemory.hpp

Changeset: 48e480e56aad
Author:    jboes
Date:      2019-09-24 09:43 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/48e480e56aad

8231186: Replace html tag <code>foo</code> with javadoc tag {@code foo} in java.base
Summary: Minor coding style update of javadoc tag in any file in java.base
Reviewed-by: bchristi, lancea

! src/java.base/share/classes/java/io/BufferedInputStream.java
! src/java.base/share/classes/java/io/BufferedOutputStream.java
! src/java.base/share/classes/java/io/BufferedReader.java
! src/java.base/share/classes/java/io/CharArrayReader.java
! src/java.base/share/classes/java/io/DataInputStream.java
! src/java.base/share/classes/java/io/DataOutput.java
! src/java.base/share/classes/java/io/DataOutputStream.java
! src/java.base/share/classes/java/io/EOFException.java
! src/java.base/share/classes/java/io/File.java
! src/java.base/share/classes/java/io/FileFilter.java
! src/java.base/share/classes/java/io/FileInputStream.java
! src/java.base/share/classes/java/io/FileNotFoundException.java
! src/java.base/share/classes/java/io/FileOutputStream.java
! src/java.base/share/classes/java/io/FilePermission.java
! src/java.base/share/classes/java/io/FileSystem.java
! src/java.base/share/classes/java/io/FilenameFilter.java
! src/java.base/share/classes/java/io/FilterInputStream.java
! src/java.base/share/classes/java/io/FilterOutputStream.java
! src/java.base/share/classes/java/io/FilterReader.java
! src/java.base/share/classes/java/io/FilterWriter.java
! src/java.base/share/classes/java/io/InputStream.java
! src/java.base/share/classes/java/io/InputStreamReader.java
! src/java.base/share/classes/java/io/InterruptedIOException.java
! src/java.base/share/classes/java/io/InvalidObjectException.java
! src/java.base/share/classes/java/io/ObjectInputStream.java
! src/java.base/share/classes/java/io/ObjectOutputStream.java
! src/java.base/share/classes/java/io/ObjectStreamClass.java
! src/java.base/share/classes/java/io/ObjectStreamField.java
! src/java.base/share/classes/java/io/OptionalDataException.java
! src/java.base/share/classes/java/io/OutputStream.java
! src/java.base/share/classes/java/io/OutputStreamWriter.java
! src/java.base/share/classes/java/io/PipedInputStream.java
! src/java.base/share/classes/java/io/PipedOutputStream.java
! src/java.base/share/classes/java/io/PipedReader.java
! src/java.base/share/classes/java/io/PipedWriter.java
! src/java.base/share/classes/java/io/PushbackInputStream.java
! src/java.base/share/classes/java/io/PushbackReader.java
! src/java.base/share/classes/java/io/Reader.java
! src/java.base/share/classes/java/io/SequenceInputStream.java
! src/java.base/share/classes/java/io/Serializable.java
! src/java.base/share/classes/java/io/SerializablePermission.java
! src/java.base/share/classes/java/io/StringBufferInputStream.java
! src/java.base/share/classes/java/io/StringReader.java
! src/java.base/share/classes/java/io/UTFDataFormatException.java
! src/java.base/share/classes/java/lang/AbstractMethodError.java
! src/java.base/share/classes/java/lang/ArrayStoreException.java
! src/java.base/share/classes/java/lang/AssertionError.java
! src/java.base/share/classes/java/lang/ClassCastException.java
! src/java.base/share/classes/java/lang/ClassFormatError.java
! src/java.base/share/classes/java/lang/ClassNotFoundException.java
! src/java.base/share/classes/java/lang/CloneNotSupportedException.java
! src/java.base/share/classes/java/lang/Cloneable.java
! src/java.base/share/classes/java/lang/ConditionalSpecialCasing.java
! src/java.base/share/classes/java/lang/ExceptionInInitializerError.java
! src/java.base/share/classes/java/lang/IllegalAccessError.java
! src/java.base/share/classes/java/lang/IllegalAccessException.java
! src/java.base/share/classes/java/lang/IllegalArgumentException.java
! src/java.base/share/classes/java/lang/IllegalMonitorStateException.java
! src/java.base/share/classes/java/lang/IllegalStateException.java
! src/java.base/share/classes/java/lang/IllegalThreadStateException.java
! src/java.base/share/classes/java/lang/IncompatibleClassChangeError.java
! src/java.base/share/classes/java/lang/InstantiationError.java
! src/java.base/share/classes/java/lang/InternalError.java
! src/java.base/share/classes/java/lang/InterruptedException.java
! src/java.base/share/classes/java/lang/NegativeArraySizeException.java
! src/java.base/share/classes/java/lang/NoClassDefFoundError.java
! src/java.base/share/classes/java/lang/NoSuchFieldError.java
! src/java.base/share/classes/java/lang/NoSuchMethodError.java
! src/java.base/share/classes/java/lang/NoSuchMethodException.java
! src/java.base/share/classes/java/lang/NumberFormatException.java
! src/java.base/share/classes/java/lang/Runnable.java
! src/java.base/share/classes/java/lang/RuntimePermission.java
! src/java.base/share/classes/java/lang/SecurityManager.java
! src/java.base/share/classes/java/lang/StackOverflowError.java
! src/java.base/share/classes/java/lang/UnknownError.java
! src/java.base/share/classes/java/lang/UnsatisfiedLinkError.java
! src/java.base/share/classes/java/lang/UnsupportedClassVersionError.java
! src/java.base/share/classes/java/lang/UnsupportedOperationException.java
! src/java.base/share/classes/java/lang/VerifyError.java
! src/java.base/share/classes/java/lang/VirtualMachineError.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/package-info.java
! src/java.base/share/classes/java/lang/ref/Reference.java
! src/java.base/share/classes/java/text/AttributedString.java
! src/java.base/share/classes/java/text/Bidi.java
! src/java.base/share/classes/java/text/BreakIterator.java
! src/java.base/share/classes/java/text/CharacterIteratorFieldDelegate.java
! src/java.base/share/classes/java/text/ChoiceFormat.java
! src/java.base/share/classes/java/text/CollationElementIterator.java
! src/java.base/share/classes/java/text/CollationKey.java
! src/java.base/share/classes/java/text/Collator.java
! src/java.base/share/classes/java/text/DateFormat.java
! src/java.base/share/classes/java/text/DateFormatSymbols.java
! src/java.base/share/classes/java/text/DigitList.java
! src/java.base/share/classes/java/text/FieldPosition.java
! src/java.base/share/classes/java/text/Format.java
! src/java.base/share/classes/java/text/MessageFormat.java
! src/java.base/share/classes/java/text/Normalizer.java
! src/java.base/share/classes/java/text/NumberFormat.java
! src/java.base/share/classes/java/text/ParsePosition.java
! src/java.base/share/classes/java/text/RuleBasedCollator.java
! src/java.base/share/classes/java/text/SimpleDateFormat.java
! src/java.base/share/classes/java/text/StringCharacterIterator.java
! src/java.base/share/classes/java/text/spi/BreakIteratorProvider.java
! src/java.base/share/classes/java/text/spi/CollatorProvider.java
! src/java.base/share/classes/java/text/spi/DateFormatProvider.java
! src/java.base/share/classes/java/text/spi/DateFormatSymbolsProvider.java
! src/java.base/share/classes/java/text/spi/DecimalFormatSymbolsProvider.java
! src/java.base/share/classes/java/text/spi/NumberFormatProvider.java
! src/java.base/share/classes/java/time/ZoneId.java
! src/java.base/share/classes/java/util/Calendar.java
! src/java.base/share/classes/java/util/ConcurrentModificationException.java
! src/java.base/share/classes/java/util/Currency.java
! src/java.base/share/classes/java/util/GregorianCalendar.java
! src/java.base/share/classes/java/util/IllformedLocaleException.java
! src/java.base/share/classes/java/util/ListResourceBundle.java
! src/java.base/share/classes/java/util/Locale.java
! src/java.base/share/classes/java/util/PropertyPermission.java
! src/java.base/share/classes/java/util/PropertyResourceBundle.java
! src/java.base/share/classes/java/util/ResourceBundle.java
! src/java.base/share/classes/java/util/SimpleTimeZone.java
! src/java.base/share/classes/java/util/TimeZone.java
! src/java.base/share/classes/java/util/TooManyListenersException.java
! src/java.base/share/classes/java/util/jar/JarEntry.java
! src/java.base/share/classes/java/util/jar/JarInputStream.java
! src/java.base/share/classes/java/util/jar/JarOutputStream.java
! src/java.base/share/classes/java/util/jar/package-info.java
! src/java.base/share/classes/java/util/regex/Pattern.java
! src/java.base/share/classes/java/util/regex/package-info.java
! src/java.base/share/classes/java/util/spi/CalendarNameProvider.java
! src/java.base/share/classes/java/util/spi/CurrencyNameProvider.java
! src/java.base/share/classes/java/util/spi/LocaleNameProvider.java
! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java
! src/java.base/share/classes/java/util/spi/TimeZoneNameProvider.java
! src/java.base/share/classes/java/util/zip/CheckedInputStream.java
! src/java.base/share/classes/java/util/zip/GZIPInputStream.java
! src/java.base/share/classes/java/util/zip/InflaterInputStream.java
! src/java.base/share/classes/java/util/zip/ZipException.java
! src/java.base/share/classes/java/util/zip/ZipInputStream.java

Changeset: 3a79d4cccbcb
Author:    pconcannon
Date:      2019-09-23 16:53 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/3a79d4cccbcb

8217825: Verify @AfterTest is used correctly in WebSocket tests
Summary: Remove @AfterTest tags; added in explicit closing of resources e.g. httpServer, webSocket, etc
Reviewed-by: dfuchs, prappo

! test/jdk/java/net/httpclient/websocket/Abort.java
! test/jdk/java/net/httpclient/websocket/AutomaticPong.java
! test/jdk/java/net/httpclient/websocket/SendTest.java
! test/jdk/java/net/httpclient/websocket/WebSocketTest.java

Changeset: a013100f7a35
Author:    coleenp
Date:      2019-09-24 10:12 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/a013100f7a35

8213150: Add verification for locking by VMThread
Summary: extend verification for all locking not just VMOperations, and fix CLDG lock to not be taken by VM thread.
Reviewed-by: rehn, dholmes

! src/hotspot/share/classfile/classLoaderDataGraph.cpp
! src/hotspot/share/classfile/classLoaderDataGraph.hpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/runtime/mutex.cpp
! src/hotspot/share/runtime/mutex.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vmThread.cpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! src/hotspot/share/utilities/events.hpp

Changeset: a8f06f2b84b0
Author:    pliden
Date:      2019-09-24 17:08 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/a8f06f2b84b0

8231251: ZGC: Fix ZHeap includes
Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zHeap.hpp
! src/hotspot/share/gc/z/zHeap.inline.hpp

Changeset: f2bd6a3993a7
Author:    pliden
Date:      2019-09-24 17:08 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/f2bd6a3993a7

8231266: ZGC: Minor cleanups in ZCollectedHeap and ZHeap
Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zHeap.hpp
! src/hotspot/share/gc/z/zHeap.inline.hpp

Changeset: 872465abbfe3
Author:    pliden
Date:      2019-09-24 17:08 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/872465abbfe3

8231270: ZGC: Remove ZAddressSpace* and ZAddressReserved*
Reviewed-by: stefank, eosterlund

! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.hpp
! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp
! src/hotspot/cpu/x86/gc/z/zGlobals_x86.hpp
! src/hotspot/share/gc/z/vmStructs_z.hpp
! src/hotspot/share/gc/z/zAddress.cpp
! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zDebug.gdb
! src/hotspot/share/gc/z/zGlobals.cpp
! src/hotspot/share/gc/z/zGlobals.hpp

Changeset: 7973073dd048
Author:    michaelm
Date:      2019-09-24 16:19 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/7973073dd048

8231187: SelectorProvider.inheritedChannel() returns TCP socket channel for Unix domain socket
Reviewed-by: alanb, chegar

! src/java.base/macosx/classes/sun/nio/ch/KQueueSelectorProvider.java
! src/java.base/unix/classes/sun/nio/ch/InheritedChannel.java
+ src/java.base/unix/classes/sun/nio/ch/UnixDomainSocketChannelImpl.java
! src/java.base/unix/native/libnio/ch/InheritedChannel.c
! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/InheritedChannelTest.java
! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java
+ test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/UnixDomainChannelTest.java
! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/UnixDomainSocket.java
! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c

Changeset: 7b534a5088d9
Author:    erikj
Date:      2019-09-24 11:39 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/7b534a5088d9

8231351: Add notes for PKCS11 tests in the test doc
Reviewed-by: erikj, jjiang
Contributed-by: huangjia at loongson.cn

! doc/testing.html
! doc/testing.md

Changeset: 01f7ba3a4905
Author:    naoto
Date:      2019-09-24 08:55 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/01f7ba3a4905

8230531: API Doc for CharsetEncoder.maxBytesPerChar() should be clearer about BOMs
Reviewed-by: martin, alanb

! src/java.base/share/classes/java/nio/charset/Charset-X-Coder.java.template

Changeset: 0152ad7b38b8
Author:    epavlova
Date:      2019-09-24 08:54 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/0152ad7b38b8

8231376: Unproblem list compiler/unsafe/Unsafe{Off,On}HeapBooleanTest.java tests
Reviewed-by: iignatyev

! test/hotspot/jtreg/ProblemList-graal.txt

Changeset: 6df94ce3ab2f
Author:    dlong
Date:      2019-09-24 12:47 -0400
URL:       https://hg.openjdk.java.net/panama/dev/rev/6df94ce3ab2f

8229201: Update Graal
Reviewed-by: kvn

! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java
! src/jdk.aot/share/classes/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/NativeOrderOutputStreamTest.java
! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Collector.java
! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MarkId.java
! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java
! src/jdk.internal.vm.compiler.management/share/classes/org.graalvm.compiler.hotspot.management/src/org/graalvm/compiler/hotspot/management/HotSpotGraalManagement.java
! src/jdk.internal.vm.compiler.management/share/classes/org.graalvm.compiler.hotspot.management/src/org/graalvm/compiler/hotspot/management/HotSpotGraalRuntimeMBean.java
! src/jdk.internal.vm.compiler.management/share/classes/org.graalvm.compiler.hotspot.management/src/org/graalvm/compiler/hotspot/management/package-info.java
! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.libgraal/src/jdk/internal/vm/compiler/libgraal/LibGraal.java
! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.libgraal/src/jdk/internal/vm/compiler/libgraal/LibGraalScope.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/BlackholeDirectiveTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/ControlFlowAnchorDirectiveTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/IterationDirectiveTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/OpaqueDirectiveTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Assembler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64MacroAssembler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64AsmOptions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64Assembler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64BaseAssembler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64MacroAssembler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.sparc/src/org/graalvm/compiler/asm/sparc/SPARCAssembler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.test/src/org/graalvm/compiler/asm/test/AssemblerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm/src/org/graalvm/compiler/asm/Assembler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm/src/org/graalvm/compiler/asm/Buffer.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm/src/org/graalvm/compiler/asm/Label.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.code/src/org/graalvm/compiler/code/CompilationResult.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.code/src/org/graalvm/compiler/code/DataSection.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.code/src/org/graalvm/compiler/code/HexCodeFileDisassemblerProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64CbzTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64LIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64LoweringProviderMixin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64ReadNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64SuitesCreator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64.test/src/org/graalvm/compiler/core/amd64/test/AMD64MatchRuleTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64ArithmeticLIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64LIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64LoweringProviderMixin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64NodeMatchRules.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/Fields.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/FieldsScanner.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/GraalOptions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/LIRKind.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/SpeculativeExecutionAttacksMitigations.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/calc/CanonicalCondition.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/cfg/AbstractBlockBase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/cfg/CFGVerifier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/cfg/Loop.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/spi/ForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/AbstractObjectStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/AbstractPointerStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/FloatStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/IllegalStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/IntegerStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/PrimitiveStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/Stamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/VoidStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/TypeReader.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/TypeWriter.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeArrayTypeReader.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsignedLong.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.match.processor/src/org/graalvm/compiler/core/match/processor/MatchProcessor.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.sparc/src/org/graalvm/compiler/core/sparc/SPARCLIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.sparc/src/org/graalvm/compiler/core/sparc/SPARCNodeMatchRules.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.sparc/src/org/graalvm/compiler/core/sparc/SparcLoweringProviderMixin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/BasePhaseBinaryGraphTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CanonicalizedConversionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CheckGraalInvariants.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CompareCanonicalizerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CompareCanonicalizerTest2.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CompareCanonicalizerTest3.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest10.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest13.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest14.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest15.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTest2.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationTestBase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalNodeTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CopyOfVirtualizationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CountedLoopTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CustomizedBytecodePatternTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/DumpPathTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/EnumSwitchTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/FinalizableSubclassTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/FindUniqueConcreteMethodBugTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/FloatingReadTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraalCompilerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraphEncoderTest.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraphPrinterTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraphResetDebugTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GuardPrioritiesTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/IfCanonicalizerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ImplicitNullCheckTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/IntegerEqualsCanonicalizerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LockEliminationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LoopFullUnrollTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/LoopUnswitchTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/MergeCanonicalizerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/NestedLoopTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/NewInstanceTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/NodePropertiesTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/OptionsVerifierTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/PushNodesThroughPiTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/PushThroughIfTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ReadAfterCheckCastTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ReassociateAndCanonicalTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ReferenceGetLoopTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ScalarTypeSystemTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SchedulingTest2.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/StampCanonicalizerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/StraighteningTest.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SubprocessTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SwitchCanonicalizerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SwitchDyingLoopTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/TypeSystemTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/TypeWriterTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnbalancedMonitorsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnsafeReadEliminationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnsafeVirtualizationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnusedArray.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyBailoutUsage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyCallerSensitiveMethods.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyDebugUsage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyFoldableMethods.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyGetOptionsUsage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyGraphAddUsage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyInstanceOfUsage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifySystemPropertyUsage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyUpdateUsages.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyUsageWithEquals.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyVirtualizableUsage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/backend/BackendTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/deopt/CompiledMethodTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/deopt/RethrowDeoptMaterializeTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/deopt/SynchronizedMethodDeoptimizationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/EATestBase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/EscapeAnalysisTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/PoorMansEATest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/UnsafeCompareAndSwapVirtualizationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/NestedLoopEffectsPhaseComplexityTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/PolymorphicInliningTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/tutorial/StaticAnalysis.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/tutorial/StaticAnalysisTests.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/CompilationPrinter.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/CompilationWrapper.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalCompilerOptions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/LIRGenerationPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/DebugInfoBuilder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/LIRCompilerBackend.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/LIRGenerationProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/NodeMatchRules.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/match/MatchContext.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/match/MatchPattern.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/match/MatchStatement.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/match/MatchableNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/EconomyLowTier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/EconomyMidTier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/GraphChangeMonitoringPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/HighTier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/LowTier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/phases/MidTier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/target/Backend.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugContext.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugOptions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/GlobalMetrics.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/IgvDumpChannel.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/MemUseTrackerKey.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/PathUtilities.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/TTY.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/Edges.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/Graph.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/IterableNodeType.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/Node.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeClass.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeList.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeMap.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeSourcePosition.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackend.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackendFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotJumpToExceptionHandlerInCallerOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64IndirectCallOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64.test/src/org/graalvm/compiler/hotspot/amd64/test/StubAVXTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64.test/src/org/graalvm/compiler/hotspot/amd64/test/UnaryMathStubTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64ArrayIndexOfStub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotBackend.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotBackendFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotJumpToExceptionHandlerInCallerOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotLIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotStrategySwitchOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64X87MathIntrinsicNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64X87MathSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.jdk9.test/src/org/graalvm/compiler/hotspot/jdk9/test/MathDoubleFMATest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.jdk9.test/src/org/graalvm/compiler/hotspot/jdk9/test/MathFMAConstantInputTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.jdk9.test/src/org/graalvm/compiler/hotspot/jdk9/test/MathFloatFMATest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.jdk9.test/src/org/graalvm/compiler/hotspot/jdk9/test/StringUTF16ToBytesGetCharsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.lir.test/src/org/graalvm/compiler/hotspot/lir/test/BenchmarkCounterOverflowTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotBackend.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotBackendFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotLIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotLoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotMove.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/AheadOfTimeCompilationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ArrayCopyIntrinsificationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CRC32CSubstitutionsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompilationWrapperTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompileTheWorld.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompileTheWorldTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompressedOopTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ConstantPoolSubstitutionsTests.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/EliminateRedundantInitializationPhaseTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/GraalOSRTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/GraalOSRTestBase.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotClassInitializationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotCryptoSubstitutionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotGraalCompilerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotGraalManagementTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotInvokeDynamicPluginTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotLazyInitializationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HsErrLogTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/JVMCIInfopointErrorTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/LoadJavaMirrorWithKlassTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/MemoryUsageBenchmark.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ObjectHashCodeInliningTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/OptionsInFileTest.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/PolymorphicInliningTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ReplaceConstantNodesPhaseTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ReservedStackAccessTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/TestIntrinsicCompiles.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/WriteBarrierAdditionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/BootstrapWatchDog.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilationCounters.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilationTask.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilationWatchDog.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilerConfigurationFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfigVersioned.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotBackend.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotBackendFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotCompiledCodeBuilder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotForeignCallLinkage.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotForeignCallLinkageImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalCompiler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalJVMCIServiceLocator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalOptionValues.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntime.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalServices.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotHostBackend.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotLIRGenerationResult.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotReplacementsImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotTTYStreamProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/SymbolicSnippetEncoder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/debug/BenchmarkCounters.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/lir/HotSpotZapRegistersPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/AddressLoweringHotSpotSuitesProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotAOTClassInitializationPlugin.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotClassInitializationPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotForeignCallsProviderImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraalConstantFieldProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotHostForeignCallsProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotInvocationPlugins.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotJITClassInitializationPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotProviders.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotStampProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotSuitesProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotUnsafeSubstitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotWordOperationPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/AllocaNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DimensionsNode.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/KlassBeingInitializedCheckNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/MonitorCounterNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/type/KlassPointerStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/AheadOfTimeVerificationPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/LoadJavaMirrorWithKlassPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/aot/AOTInliningPolicy.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/aot/EliminateRedundantInitializationPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/aot/ReplaceConstantNodesPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/phases/profiling/FinalizeProfileNodesPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/AssertionSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotClassSubstitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/InstanceOfSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/MonitorSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/NewObjectSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ObjectCloneNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/SHA2Substitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/SHA5Substitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/SHASubstitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/StringUTF16Substitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ThreadSubstitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/UnsafeLoadSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/CreateExceptionStub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/ExceptionHandlerStub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/ForeignCallStub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/OutOfBoundsExceptionStub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/SnippetStub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/Stub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/StubUtil.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/UnwindExceptionToCallerStub.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BciBlockMapping.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParser.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/FrameStateBuilder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/GraphBuilderPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/JsrScope.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/jdk/System_currentTimeMillis02.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/jdk/System_nanoTime02.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/lang/Math_log10.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/lang/UnaryMath.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/optimize/IfNodeCanonicalizationsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/optimize/NestedLoop_EA.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/SynchronizedLoopExit01.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ArithmeticLIRGeneratorTool.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Call.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Compare.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ControlFlow.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Move.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64RestoreRegistersOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64SaveRegistersOp.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ZeroMemoryOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayCompareToOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayEqualsOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayIndexOfOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Binary.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64BinaryConsumer.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathCosOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathExpOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathIntrinsicBinaryOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathIntrinsicUnaryOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathLog10Op.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathLogOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathPowOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathSinOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64MathTanOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Move.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64RestoreRegistersOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64SaveRegistersOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64StringLatin1InflateOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64StringUTF16CompressOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64VZeroUpper.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ZapRegistersOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/vector/AMD64VectorCompareOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/vector/AMD64VectorMove.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.sparc/src/org/graalvm/compiler/lir/sparc/SPARCSaveRegistersOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/BailoutAndRestartBackendException.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/LIR.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/LIRInstructionVerifier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/LIRVerifier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/StandardOp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/lsra/LinearScanWalker.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/asm/CompilationResultBuilder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/asm/CompilationResultBuilderFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/constopt/ConstantLoadOptimization.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/dfa/LocationMarkerPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/framemap/FrameMap.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/framemap/FrameMapBuilder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/framemap/FrameMapBuilderImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/framemap/VirtualStackSlotRange.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/ArithmeticLIRGeneratorTool.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/DiagnosticLIRGeneratorTool.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/LIRGenerationResult.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/LIRGenerator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/LIRGeneratorTool.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/ssa/SSAVerifier.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/stackslotalloc/LSStackSlotAllocator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/stackslotalloc/SimpleStackSlotAllocator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/ContextlessLoopPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/ConvertDeoptimizeToGuardPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopFullUnrollPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopPartialUnrollPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopPeelingPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopSafepointEliminationPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopTransformations.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.test/src/org/graalvm/compiler/loop/test/LoopPartialUnrollTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/CountedLoopInfo.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/DefaultLoopPolicies.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopEx.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopFragmentInside.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/ConditionalEliminationBenchmark.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/lir/GraalCompilerState.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes.test/src/org/graalvm/compiler/nodes/test/IfNodeCanonicalizationTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes.test/src/org/graalvm/compiler/nodes/test/LoopPhiCanonicalizerTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes.test/src/org/graalvm/compiler/nodes/test/PrimitiveStampBoundaryTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes.test/src/org/graalvm/compiler/nodes/test/ShortCircuitOrNodeTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/AbstractFixedGuardNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/CallTargetNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ComputeObjectAddressNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ControlSplitNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/DeoptimizingNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/FixedGuardNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/FrameState.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/GraphEncoder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/IfNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/Invoke.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/InvokeNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/InvokeWithExceptionNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/LogicNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/LoopBeginNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/LoopExitNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/PiNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/SimplifyingGraphDecoder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/StructuredGraph.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/ValueNode.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/AbstractNormalizeCompareNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/CompareNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/ConditionalNode.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/FloatNormalizeCompareNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerConvertNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerDivRemNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerEqualsNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerLessThanNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerLowerThanNode.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerNormalizeCompareNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerTestNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IsNullNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NarrowNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NormalizeCompareNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/PointerEqualsNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/ReinterpretNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/cfg/Block.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/cfg/ControlFlowGraph.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/ArrayRangeWrite.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/BranchProbabilityNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/ForeignCallNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/GuardedUnsafeLoadNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/IntegerSwitchNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/JavaWriteNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/LoadHubNode.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/LoadHubOrNullNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/MultiGuardNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/SwitchNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GeneratedInvocationPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderConfiguration.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderContext.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderTool.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/InlineInvokePlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/IntrinsicContext.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/InvocationPlugins.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/MethodSubstitutionPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/AbstractNewObjectNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/ArrayLengthNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/LoadIndexedNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/MonitorExitNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/NewArrayNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/NewInstanceNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/StoreFieldNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/StoreIndexedNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/TypeSwitchNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/AbstractWriteNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/FixedAccessNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/HeapAccess.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/address/IndexAddressNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/DelegatingReplacements.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/LoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/LoweringTool.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/Replacements.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/StampProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/type/NarrowOopStamp.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/util/GraphUtil.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/util/IntegerHelper.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/util/SignedIntegerHelper.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/util/UnsignedIntegerHelper.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options.processor/src/org/graalvm/compiler/options/processor/OptionProcessor.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/ModuleSupport.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/Option.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionDescriptor.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionKey.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionValues.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionsParser.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/AddressLoweringByUsePhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/CanonicalizerPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ConditionalEliminationPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/DeoptimizationGroupingPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ExpandLogicPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/FixReadsPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/FrameStateAssignmentPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/IncrementalCanonicalizerPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/LoweringPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/NodeCounterPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/OptimizeDivPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/PropagateDeoptimizeProbabilityPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/RemoveValueProxyPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/UseTrappingNullChecksPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/InliningUtil.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/info/elem/InlineableGraph.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/AbstractInliningPolicy.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/GreedyInliningPolicy.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/InlineEverythingPolicy.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/InlineMethodSubstitutionsPolicy.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/InliningPolicy.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/util/EconomicSetNodeEventListener.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/PhaseSuite.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/VerifyPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/graph/ReentrantBlockIterator.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/tiers/HighTierContext.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/tiers/LowTierContext.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/tiers/MidTierContext.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/util/GraphOrder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/util/Providers.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/BinaryGraphPrinter.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/CFGPrinterObserver.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/GraalDebugHandlersFactory.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/GraphPrinter.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/GraphPrinterDumpHandler.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64IntegerArithmeticSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64ArrayIndexOf.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64ArrayIndexOfNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64GraphBuilderPlugins.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringLatin1Substitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringSubstitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64StringUTF16Substitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.processor/src/org/graalvm/compiler/replacements/processor/GeneratedFoldPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.processor/src/org/graalvm/compiler/replacements/processor/GeneratedPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ArraysSubstitutionsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/DeoptimizeOnExceptionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/DeoptimizeOnIntegerExactTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/DerivedOopTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/FoldTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/IntegerExactExceptionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/IntegerExactFoldTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/InvokerSignatureMismatchTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/MethodSubstitutionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/PEGraphDecoderTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ReplacementsParseTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/SnippetsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StandardMethodSubstitutionsTest.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringCompareToAVX512Test.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringCompareToTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringCompressInflateTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringIndexOfCharTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringIndexOfConstantTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringIndexOfTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringIndexOfTestBase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringSubstitutionTestBase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringSubstitutionsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/SubstitutionNodeSourcePositionTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/SubstitutionsTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/classfile/ClassfileBytecodeProviderTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/classfile/RedefineIntrinsicTest.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/ArraySubstitutions.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/CachingPEGraphDecoder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/ConstantBindingParameterPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/ConstantStringIndexOfSnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/DefaultJavaLoweringProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/GraphKit.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/InlineDuringParsingPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/IntrinsicGraphBuilder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/MethodHandlePlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/PEGraphDecoder.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/ReplacementsImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetCounter.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetCounterNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetTemplate.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/TargetGraphBuilderPlugins.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyCallNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopySnippets.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/ClassfileBytecodeProvider.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayEqualsNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayRegionEqualsNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/BasicArrayCopyNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/BasicObjectCloneNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/MacroNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/MethodHandleNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ReadRegisterNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/WriteRegisterNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ZeroMemoryNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/arithmetic/IntegerAddExactNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/arithmetic/IntegerExactArithmeticSplitNode.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/SpeculationEncodingAdapter.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/UnencodedSpeculationReason.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/GraalTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java
+ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ModuleSupport.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/SubprocessUtil.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/EarlyReadEliminationPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/EffectsClosure.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/EffectsPhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/GraphEffectList.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/PEReadEliminationClosure.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/PartialEscapeClosure.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/PartialEscapePhase.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/VirtualizerToolImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/Word.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/WordOperationPlugin.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/WordTypes.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.graphio/src/org/graalvm/graphio/GraphOutput.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.graphio/src/org/graalvm/graphio/GraphProtocol.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.graphio/src/org/graalvm/graphio/ProtocolImpl.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.graphio/src/org/graalvm/graphio/package-info.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.util.test/src/org/graalvm/util/test/CollectionSizeTest.java

Changeset: c3b93d6603f5
Author:    iklam
Date:      2019-09-24 10:36 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/c3b93d6603f5

8231367: [TESTBUG] ParallelLoadTest.java fails with "test.dynamic.dump not supported"
Reviewed-by: ccheung

! test/hotspot/jtreg/runtime/cds/appcds/ParallelLoadTest.java
! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java

Changeset: b7192797f434
Author:    prappo
Date:      2019-09-24 22:57 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/b7192797f434

8228580: DnsClient TCP socket timeout
Reviewed-by: vtewari, chegar, prappo
Contributed-by: Milan Mimica <milan.mimica at gmail.com>

! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java
! src/jdk.naming.dns/share/classes/module-info.java
+ test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.dns
+ test/jdk/com/sun/jndi/dns/ConfigTests/TcpTimeout.java

Changeset: c6f8b2c3dc66
Author:    darcy
Date:      2019-09-24 18:25 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/c6f8b2c3dc66

8231334: Suppress warnings on non-serializable instance fields in client libs serializable classes
Reviewed-by: prr

! src/java.desktop/share/classes/java/applet/Applet.java
! src/java.desktop/share/classes/java/awt/Component.java
! src/java.desktop/share/classes/java/awt/Container.java
! src/java.desktop/share/classes/java/awt/Event.java
! src/java.desktop/share/classes/java/awt/FileDialog.java
! src/java.desktop/share/classes/java/awt/MediaTracker.java
! src/java.desktop/share/classes/java/awt/MenuComponent.java
! src/java.desktop/share/classes/java/awt/ScrollPaneAdjustable.java
! src/java.desktop/share/classes/java/awt/SentEvent.java
! src/java.desktop/share/classes/java/awt/SequencedEvent.java
! src/java.desktop/share/classes/java/awt/Window.java
! src/java.desktop/share/classes/java/awt/desktop/FilesEvent.java
! src/java.desktop/share/classes/java/awt/event/AdjustmentEvent.java
! src/java.desktop/share/classes/java/awt/event/InvocationEvent.java
! src/java.desktop/share/classes/java/awt/event/ItemEvent.java
! src/java.desktop/share/classes/java/beans/PropertyChangeEvent.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextChildSupport.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextEvent.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java
! src/java.desktop/share/classes/javax/imageio/metadata/IIOInvalidTreeException.java
! src/java.desktop/share/classes/javax/imageio/spi/DigraphNode.java
! src/java.desktop/share/classes/javax/print/attribute/AttributeSetUtilities.java
! src/java.desktop/share/classes/javax/print/event/PrintJobAttributeEvent.java
! src/java.desktop/share/classes/javax/print/event/PrintServiceAttributeEvent.java
! src/java.desktop/share/classes/javax/sound/sampled/LineEvent.java
! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java

Changeset: 81134def991d
Author:    ccheung
Date:      2019-09-24 20:16 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/81134def991d

8231097: [TESTBUG] runtime/cds/appcds/DirClasspathTest.java can fail with a mapping error
Summary: Check output for mapping failure and throw a SkippedException.
Reviewed-by: iklam, dholmes

! test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java

Changeset: 88fce7eea1f6
Author:    roland
Date:      2019-09-23 16:49 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/88fce7eea1f6

8229483: Sinking load out of loop may trigger: assert(found_sfpt) failed: no node in loop that's not input to safepoint
Reviewed-by: thartmann, neliasso

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopstripmining/AntiDependentLoadInOuterStripMinedLoop.java

Changeset: ce960527ecee
Author:    alanb
Date:      2019-09-25 09:17 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/ce960527ecee

8231413: Several test/hotspot/jtreg/runtime tests updates to run with --illegal-access=deny
Reviewed-by: hseigel, lfoltan, dholmes

! test/hotspot/jtreg/runtime/InvocationTests/invocationC1Tests.java
! test/hotspot/jtreg/runtime/InvocationTests/invocationGraalTests.java
! test/hotspot/jtreg/runtime/InvocationTests/invokeinterfaceTests.java
! test/hotspot/jtreg/runtime/InvocationTests/invokespecialTests.java
! test/hotspot/jtreg/runtime/InvocationTests/invokevirtualTests.java
! test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java

Changeset: 8a2bc12d2a9a
Author:    michaelm
Date:      2019-09-25 09:38 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/8a2bc12d2a9a

8231450: Copyright header line omitted from 8231187 changeset
Reviewed-by: chegar

! test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java

Changeset: 170b727a240a
Author:    psadhukhan
Date:      2019-08-26 11:20 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/170b727a240a

Merge

- make/jdk/src/classes/build/tools/tzdb/ZoneRules.java
- src/hotspot/cpu/aarch64/aarch64_call.cpp
- src/hotspot/cpu/aarch64/aarch64_linkage.S
- src/hotspot/cpu/aarch64/cpustate_aarch64.hpp
- src/hotspot/cpu/aarch64/decode_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/linux_aarch64.S
- src/hotspot/share/gc/parallel/gcTaskManager.cpp
- src/hotspot/share/gc/parallel/gcTaskManager.hpp
- src/hotspot/share/gc/parallel/gcTaskThread.cpp
- src/hotspot/share/gc/parallel/gcTaskThread.hpp
- src/hotspot/share/gc/parallel/pcTasks.cpp
- src/hotspot/share/gc/parallel/pcTasks.hpp
- src/hotspot/share/gc/parallel/psTasks.cpp
- src/hotspot/share/gc/parallel/psTasks.hpp
- src/hotspot/share/oops/markOop.cpp
- src/hotspot/share/oops/markOop.hpp
- src/hotspot/share/oops/markOop.inline.hpp
- src/java.base/share/classes/java/security/acl/Acl.java
- src/java.base/share/classes/java/security/acl/AclEntry.java
- src/java.base/share/classes/java/security/acl/AclNotFoundException.java
- src/java.base/share/classes/java/security/acl/Group.java
- src/java.base/share/classes/java/security/acl/LastOwnerException.java
- src/java.base/share/classes/java/security/acl/NotOwnerException.java
- src/java.base/share/classes/java/security/acl/Owner.java
- src/java.base/share/classes/java/security/acl/Permission.java
- src/java.base/share/classes/java/security/acl/package-info.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/ArchiveDoesNotExist.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/BootAppendTests.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentCompactStrings.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CdsSameObjectAlignment.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CheckDefaultArchiveFile.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/CheckSharingWithDefaultArchive.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSharedDictionary.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/DumpSymbolAndStringTable.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/LoadClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/MaxMetaspaceSize.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/NonBootLoaderClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedArchiveFile.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedBaseAddress.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStrings.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsDedup.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsRunAuto.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedStringsWb.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SharedSymbolTableBucketSize.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/SpaceUtilizationCheck.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/TestInterpreterMethodEntries.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/javax/annotation/processing/FilerException.jasm
- test/hotspot/jtreg/runtime/SharedArchiveFile/javax/sound/sampled/MyClass.jasm
- test/hotspot/jtreg/runtime/SharedArchiveFile/nonjdk/myPackage/MyClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClassesForSubgraphs.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/Implementor.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/Interface.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/SubClass.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/SuperClazz.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TestEntry.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformInterfaceAndImplementor.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformRelatedClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformSuperAndSubClasses.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformSuperSubTwoPckgs.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/TransformTestCommon.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/myPkg1/SuperClazz.java
- test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/transformRelatedClasses/myPkg2/SubClass.java
- test/hotspot/jtreg/runtime/appcds/AppCDSOptions.java
- test/hotspot/jtreg/runtime/appcds/AppendClasspath.java
- test/hotspot/jtreg/runtime/appcds/BootClassPathMismatch.java
- test/hotspot/jtreg/runtime/appcds/CDSandJFR.java
- test/hotspot/jtreg/runtime/appcds/CaseSensitiveClassPath.java
- test/hotspot/jtreg/runtime/appcds/ClassLoaderTest.java
- test/hotspot/jtreg/runtime/appcds/ClassPathAttr.java
- test/hotspot/jtreg/runtime/appcds/CommandLineFlagCombo.java
- test/hotspot/jtreg/runtime/appcds/CommandLineFlagComboNegative.java
- test/hotspot/jtreg/runtime/appcds/CompilerUtils.java
- test/hotspot/jtreg/runtime/appcds/DirClasspathTest.java
- test/hotspot/jtreg/runtime/appcds/DumpClassList.java
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_1.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_2.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.invalid_3.txt
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.java
- test/hotspot/jtreg/runtime/appcds/ExtraSymbols.symbols.txt
- test/hotspot/jtreg/runtime/appcds/FieldAnnotationsTest.java
- test/hotspot/jtreg/runtime/appcds/FreeUnusedMetadata.java
- test/hotspot/jtreg/runtime/appcds/GraalWithLimitedMetaspace.java
- test/hotspot/jtreg/runtime/appcds/HelloExtTest.java
- test/hotspot/jtreg/runtime/appcds/HelloTest.java
- test/hotspot/jtreg/runtime/appcds/IgnoreEmptyClassPaths.java
- test/hotspot/jtreg/runtime/appcds/JarBuilder.java
- test/hotspot/jtreg/runtime/appcds/JvmtiAddPath.java
- test/hotspot/jtreg/runtime/appcds/LongClassListPath.java
- test/hotspot/jtreg/runtime/appcds/LotsOfClasses.java
- test/hotspot/jtreg/runtime/appcds/MissingSuperTest.java
- test/hotspot/jtreg/runtime/appcds/MoveJDKTest.java
- test/hotspot/jtreg/runtime/appcds/MultiProcessSharing.java
- test/hotspot/jtreg/runtime/appcds/MultiReleaseJars.java
- test/hotspot/jtreg/runtime/appcds/OldClassTest.java
- test/hotspot/jtreg/runtime/appcds/PackageSealing.java
- test/hotspot/jtreg/runtime/appcds/ParallelLoad2.java
- test/hotspot/jtreg/runtime/appcds/ParallelLoadTest.java
- test/hotspot/jtreg/runtime/appcds/PrintSharedArchiveAndExit.java
- test/hotspot/jtreg/runtime/appcds/ProhibitedPackage.java
- test/hotspot/jtreg/runtime/appcds/ProtectionDomain.java
- test/hotspot/jtreg/runtime/appcds/RelativePath.java
- test/hotspot/jtreg/runtime/appcds/RewriteBytecodesTest.java
- test/hotspot/jtreg/runtime/appcds/SharedArchiveConsistency.java
- test/hotspot/jtreg/runtime/appcds/SharedBaseAddress.java
- test/hotspot/jtreg/runtime/appcds/SharedPackages.java
- test/hotspot/jtreg/runtime/appcds/SignedJar.java
- test/hotspot/jtreg/runtime/appcds/SpecifySysLoaderProp.java
- test/hotspot/jtreg/runtime/appcds/TestCommon.java
- test/hotspot/jtreg/runtime/appcds/TestWithProfiler.java
- test/hotspot/jtreg/runtime/appcds/TraceLongClasspath.java
- test/hotspot/jtreg/runtime/appcds/UnusedCPDuringDump.java
- test/hotspot/jtreg/runtime/appcds/UseAppCDS_Test.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_0.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_1A.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_1B.java
- test/hotspot/jtreg/runtime/appcds/VerifierTest_2.java
- test/hotspot/jtreg/runtime/appcds/WideIloadTest.java
- test/hotspot/jtreg/runtime/appcds/WrongClasspath.java
- test/hotspot/jtreg/runtime/appcds/XShareAutoWithChangedJar.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedIntegerCacheTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleComboTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleCompareTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckArchivedModuleApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedMirrorApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedMirrorTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferences.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckCachedResolvedReferencesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/CheckIntegerCacheApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.config.txt
- test/hotspot/jtreg/runtime/appcds/cacheObject/DumpTimeVerifyFailure.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStress.config.txt
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/GCStressTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/InstrumentationAgent.mf
- test/hotspot/jtreg/runtime/appcds/cacheObject/MirrorWithReferenceFieldsApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MirrorWithReferenceFieldsTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MyException.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/MyOuter.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/OpenArchiveRegion.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrimitiveTypesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrimitiveTypesTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/PrintSystemModulesApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassApp.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/RedefineClassTest.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/src/test/jdk/test/Test.java
- test/hotspot/jtreg/runtime/appcds/cacheObject/src/test/module-info.java
- test/hotspot/jtreg/runtime/appcds/cdsutils/DynamicDumpHelper.java
- test/hotspot/jtreg/runtime/appcds/condy/CondyHello.jasm
- test/hotspot/jtreg/runtime/appcds/condy/CondyHelloApp.java
- test/hotspot/jtreg/runtime/appcds/condy/CondyHelloTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatA.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatB.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatBase.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatC.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatD.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ClassListFormatE.java
- test/hotspot/jtreg/runtime/appcds/customLoader/CustomLoaderApp.java
- test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom.java
- test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom_JFR.java
- test/hotspot/jtreg/runtime/appcds/customLoader/LoaderSegregationTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestBase.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestMultiFP.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ParallelTestSingleFP.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ProhibitedPackageNamesTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/ProtectionDomain.java
- test/hotspot/jtreg/runtime/appcds/customLoader/SameNameInTwoLoadersTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnintendedLoadersTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnloadUnregisteredLoaderTest.java
- test/hotspot/jtreg/runtime/appcds/customLoader/UnsupportedPlatforms.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomInterface2_ia.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomInterface2_ib.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee2.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee3.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/CustomLoadee3Child.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/Hello.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/HelloUnload.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/InProhibitedPkg.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/LoaderAPI.mf
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/LoaderSegregation.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/OnlyBuiltin.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/OnlyUnregistered.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/ProtDomain.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/SameNameUnrelatedLoaders.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/SimpleHello.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/UnintendedLoaders.java
- test/hotspot/jtreg/runtime/appcds/customLoader/test-classes/UnloadUnregisteredLoader.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/AppendClasspath.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/ArchiveConsistency.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/ArrayKlasses.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/ClassResolutionFailure.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/DynamicArchiveTestBase.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/DynamicFlag.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/DynamicLotsOfClasses.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/ExcludedClasses.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/HelloDynamic.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/HelloDynamicCustom.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/HelloDynamicCustomUnload.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/JITInteraction.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/MainModuleOnly.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/MethodSorting.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/MissingArchive.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/NoClassToArchive.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/RelativePath.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/SharedArchiveFileOption.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/UnsupportedBaseArchive.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/UnusedCPDuringDump.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/WrongTopClasspath.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/ArrayKlassesApp.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/ExcludedClassesApp.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/LoadClasses.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/MethodSortingApp.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/MissingDependent.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/StrConcatApp.java
- test/hotspot/jtreg/runtime/appcds/dynamicArchive/test-classes/TestJIT.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/AnonVmClassesDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTest.java
- test/hotspot/jtreg/runtime/appcds/javaldr/ArrayTestHelper.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/javaldr/GCSharedStringsDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/GCSharedStringsDuringDumpWb.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDump.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDumpTransformer.java
- test/hotspot/jtreg/runtime/appcds/javaldr/HumongousDuringDumpTransformer.mf
- test/hotspot/jtreg/runtime/appcds/jigsaw/CheckUnsupportedDumpingOptions.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/JigsawOptionsCombo.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/AppClassInCP.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/CustomPackage.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/MismatchedPatchModule.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchDir.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchJavaBase.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/PatchMain.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/Simple.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/SubClassOfPatchedClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/PatchModule/TwoJars.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/BootAppendTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/ClassPathTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/com/sun/tools/javac/Main.jasm
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/com/sun/tools/javac/MyMain.jasm
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/jdk/test/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/sun/nio/cs/ext/MyClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/classpathtests/src/sun/nio/cs/ext1/MyClass.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddModules.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddOpens.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/AddReads.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ExportModule.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/JvmtiAddPath.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/MainModuleOnly.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.greetings/com/greetings/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.greetings/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.hello/com/hello/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.hello/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.nomodule/com/nomodule/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.norequires/com/norequires/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.norequires/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.simple/com/simple/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/com.simple/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/org.astro/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/src/org.astro/org/astro/World.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/OverrideTests.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/java.net.http/java/net/http/HttpTimeoutException.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/java.net.http/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/jdk.compiler/com/sun/tools/javac/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/jdk.compiler/module-info.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/test/jdk/test/Main.java
- test/hotspot/jtreg/runtime/appcds/jigsaw/overridetests/src/test/module-info.java
- test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHook.java
- test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHookTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationAgent.mf
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationApp.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationClassFileTransformer.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationRegisterClassFileTransformer.java
- test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/DumpingWithJavaAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/DumpingWithJvmtiAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/SimpleAgent.java
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/SimpleAgent.mf
- test/hotspot/jtreg/runtime/appcds/jvmti/dumpingWithAgent/libAddToSystemCLSearchOnLoad.c
- test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelClassesTransform.java
- test/hotspot/jtreg/runtime/appcds/jvmti/parallelLoad/ParallelLoadAndTransformTest.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformInterfaceImplementorAppCDS.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformRelatedClassesAppCDS.java
- test/hotspot/jtreg/runtime/appcds/jvmti/transformRelatedClasses/TransformSuperSubAppCDS.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasic.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineBasicTest.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_Shared.java
- test/hotspot/jtreg/runtime/appcds/redefineClass/RedefineRunningMethods_SharedHelper.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/ExerciseGC.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/ExtraSharedInput.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/FlagCombo.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloString.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloStringGC.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloStringPlus.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InternSharedString.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InternStringTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/InvalidFileFormat.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LargePages.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockSharedStrings.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockStringTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/LockStringValueTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasic.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsBasicPlus.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsHumongous.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsStress.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsUtils.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWb.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SharedStringsWbTest.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/SysDictCrash.java
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/CorruptDataLine.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidDataType.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidHeader.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidString.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidStringFormat.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidSymbol.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidSymbolFormat.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/InvalidVersion.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/LengthOverflow.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/OverflowPrefix.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/TruncatedString.txt
- test/hotspot/jtreg/runtime/appcds/sharedStrings/invalidFormat/UnrecognizedPrefix.txt
- test/hotspot/jtreg/runtime/appcds/test-classes/ArrayListTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/BootClassPathAppendHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/C1.java
- test/hotspot/jtreg/runtime/appcds/test-classes/C2.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Child.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr1.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr2.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr3.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr4.java
- test/hotspot/jtreg/runtime/appcds/test-classes/CpAttr5.java
- test/hotspot/jtreg/runtime/appcds/test-classes/DummyClassHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/EmptyClassHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/FieldAnnotationsApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ForNameTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/GenericTestApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/GetFlightRecorder.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Greet.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Hello.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExt.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExtApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloExtExt.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloMore.java
- test/hotspot/jtreg/runtime/appcds/test-classes/HelloWB.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Hi.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Iloadw.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/IloadwMain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JimageClassPackage.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JimageClassProtDomain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/JvmtiApp.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MethodNoReturn.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/MissingSuper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MultiProcClass.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MyAnnotation.java
- test/hotspot/jtreg/runtime/appcds/test-classes/MyThread.java
- test/hotspot/jtreg/runtime/appcds/test-classes/PackageSealingTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/PackageTest.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ParallelClasses.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ParallelLoad.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Prohibited.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/ProhibitedHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ProtDomain.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ProtDomainB.java
- test/hotspot/jtreg/runtime/appcds/test-classes/ReportMyLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/RewriteBytecodes.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Super.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TestClassLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TestWithProfilerHelper.java
- test/hotspot/jtreg/runtime/appcds/test-classes/TrySwitchMyLoader.java
- test/hotspot/jtreg/runtime/appcds/test-classes/Util.java
- test/hotspot/jtreg/runtime/appcds/test-classes/VerifierTest0.java
- test/hotspot/jtreg/runtime/appcds/test-classes/com/sun/tools/javac/Main.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr1.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr1_long.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr2.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr3.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr4.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/cpattr5_extra_long.mf
- test/hotspot/jtreg/runtime/appcds/test-classes/java/net/HttpCookie.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/javax/transaction/InvalidTransactionException.jasm
- test/hotspot/jtreg/runtime/appcds/test-classes/package_seal.mf
- test/hotspot/jtreg/serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeArray.java
- test/hotspot/jtreg/serviceability/sa/LingeredAppWithLargeStringArray.java
- test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java
! test/jdk/ProblemList.txt
- test/jdk/java/net/Socket/reset/Test.java
- test/jdk/sun/util/calendar/zi/tzdata/VERSION
- test/jdk/sun/util/calendar/zi/tzdata/africa
- test/jdk/sun/util/calendar/zi/tzdata/antarctica
- test/jdk/sun/util/calendar/zi/tzdata/asia
- test/jdk/sun/util/calendar/zi/tzdata/australasia
- test/jdk/sun/util/calendar/zi/tzdata/backward
- test/jdk/sun/util/calendar/zi/tzdata/etcetera
- test/jdk/sun/util/calendar/zi/tzdata/europe
- test/jdk/sun/util/calendar/zi/tzdata/factory
- test/jdk/sun/util/calendar/zi/tzdata/gmt
- test/jdk/sun/util/calendar/zi/tzdata/iso3166.tab
- test/jdk/sun/util/calendar/zi/tzdata/jdk11_backward
- test/jdk/sun/util/calendar/zi/tzdata/leapseconds
- test/jdk/sun/util/calendar/zi/tzdata/northamerica
- test/jdk/sun/util/calendar/zi/tzdata/pacificnew
- test/jdk/sun/util/calendar/zi/tzdata/solar87
- test/jdk/sun/util/calendar/zi/tzdata/solar88
- test/jdk/sun/util/calendar/zi/tzdata/solar89
- test/jdk/sun/util/calendar/zi/tzdata/southamerica
- test/jdk/sun/util/calendar/zi/tzdata/systemv
- test/jdk/sun/util/calendar/zi/tzdata/zone.tab
- test/jdk/sun/util/calendar/zi/tzdata_jdk/gmt
- test/jdk/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward

Changeset: 07556f8cd819
Author:    serb
Date:      2019-08-27 04:43 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/07556f8cd819

8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts
Reviewed-by: prr, avu

! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLSurfaceData.m
! src/java.desktop/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/java.desktop/share/native/common/java2d/opengl/OGLSurfaceData.c
! src/java.desktop/share/native/common/java2d/opengl/OGLSurfaceData.h
! src/java.desktop/unix/classes/sun/java2d/opengl/GLXSurfaceData.java
! src/java.desktop/unix/native/common/java2d/opengl/GLXSurfaceData.c
! src/java.desktop/windows/classes/sun/java2d/opengl/WGLSurfaceData.java
! src/java.desktop/windows/native/libawt/java2d/opengl/WGLSurfaceData.c

Changeset: 718496767a7d
Author:    prr
Date:      2019-08-28 09:13 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/718496767a7d

8229800: WindowsServerCore 1809 does not provide d2d1.dll library required by awt.dll
Reviewed-by: jdv, serb, aaivanov

! src/java.desktop/windows/native/common/awt/systemscale/systemScale.cpp
! src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp

Changeset: ddd26bd764e8
Author:    psadhukhan
Date:      2019-08-29 16:11 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/ddd26bd764e8

Merge

- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingFile_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zBackingPath_linux_x86.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zPhysicalMemoryBacking_linux_x86.hpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.cpp
- src/hotspot/share/classfile/sharedPathsMiscInfo.hpp
! test/jdk/ProblemList.txt
- test/jdk/javax/xml/jaxp/testng/validation/jdk8037819/BasicTest1.java

Changeset: f39420849ae9
Author:    trebari
Date:      2019-09-04 22:18 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/f39420849ae9

8194944: Regression automated test 'open/test/jdk/javax/swing/JInternalFrame/8145896/TestJInternalFrameMaximize.java' fails
Reviewed-by: jdv, arapte

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JInternalFrame/8145896/TestJInternalFrameMaximize.java

Changeset: 18e7ed2cd7d1
Author:    mbaesken
Date:      2019-09-04 10:12 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/18e7ed2cd7d1

8230480: check malloc/calloc results in java.desktop
Reviewed-by: rriggs

! src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp
! src/java.desktop/unix/native/common/awt/X11Color.c
! src/java.desktop/unix/native/common/awt/fontpath.c
! src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c

Changeset: 3020baa4efa4
Author:    serb
Date:      2019-09-07 11:38 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/3020baa4efa4

8229515: [macos] access to window property of NSView on wrong thread
Reviewed-by: prr, dmarkov

! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m

Changeset: 7f55aad34ac4
Author:    lbourges
Date:      2019-09-10 21:20 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/7f55aad34ac4

8230728: Thin stroked shapes are not rendered if affine transform has flip bit
Summary: use abs(at.getDeterminant()) in userSpaceLineWidth() to ensure positive value
Reviewed-by: prr, jdv

! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java
! src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java
! src/java.desktop/share/classes/sun/java2d/marlin/Version.java
+ test/jdk/sun/java2d/marlin/FlipBitTest.java

Changeset: 5028ccc17275
Author:    pbansal
Date:      2019-09-11 15:58 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/5028ccc17275

8225805: Java Access Bridge does not close the logger
Reviewed-by: dmarkov, jdv

! src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.cpp

Changeset: 7b3101216e61
Author:    serb
Date:      2019-09-12 22:20 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/7b3101216e61

8225101: Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map
Reviewed-by: prr, pbansal

! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java

Changeset: 0aba35254e00
Author:    serb
Date:      2019-09-13 17:35 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/0aba35254e00

8229896: Delete an unused code in the BufferedContext
Reviewed-by: prr, jdv

! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/java.desktop/share/classes/sun/java2d/opengl/OGLContext.java
! src/java.desktop/share/classes/sun/java2d/pipe/BufferedContext.java
! src/java.desktop/share/classes/sun/java2d/pipe/BufferedOpCodes.java
! src/java.desktop/share/native/common/java2d/opengl/OGLRenderQueue.c
! src/java.desktop/unix/classes/sun/java2d/opengl/GLXGraphicsConfig.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java
! src/java.desktop/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
! src/java.desktop/windows/native/libawt/java2d/d3d/D3DContext.cpp
! src/java.desktop/windows/native/libawt/java2d/d3d/D3DContext.h
! src/java.desktop/windows/native/libawt/java2d/d3d/D3DRenderQueue.cpp
! test/jdk/sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java
- test/jdk/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java

Changeset: d32a3b1ca84a
Author:    serb
Date:      2019-09-09 12:23 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/d32a3b1ca84a

8225372: accessibility errors in tables in java.desktop files
Reviewed-by: aivanov

! src/java.desktop/share/classes/java/awt/BorderLayout.java
! src/java.desktop/share/classes/java/awt/Button.java
! src/java.desktop/share/classes/java/awt/Checkbox.java
! src/java.desktop/share/classes/java/awt/CheckboxGroup.java
! src/java.desktop/share/classes/java/awt/CheckboxMenuItem.java
! src/java.desktop/share/classes/java/awt/Choice.java
! src/java.desktop/share/classes/java/awt/FlowLayout.java
! src/java.desktop/share/classes/java/awt/Frame.java
! src/java.desktop/share/classes/java/awt/GridBagLayout.java
! src/java.desktop/share/classes/java/awt/GridLayout.java
! src/java.desktop/share/classes/java/awt/Label.java
! src/java.desktop/share/classes/java/awt/List.java
! src/java.desktop/share/classes/java/awt/MenuBar.java
! src/java.desktop/share/classes/java/awt/MenuItem.java
! src/java.desktop/share/classes/java/awt/Scrollbar.java
! src/java.desktop/share/classes/java/awt/TextArea.java
! src/java.desktop/share/classes/java/awt/TextField.java
! src/java.desktop/share/classes/java/awt/Window.java
! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html
! src/java.desktop/share/classes/java/awt/doc-files/Modality.html
! src/java.desktop/share/classes/java/awt/font/NumericShaper.java
! src/java.desktop/share/classes/java/awt/geom/Path2D.java
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html
! src/java.desktop/share/classes/javax/print/attribute/standard/Finishings.java
! src/java.desktop/share/classes/javax/swing/BoxLayout.java
! src/java.desktop/share/classes/javax/swing/JLayeredPane.java
! src/java.desktop/share/classes/javax/swing/JRootPane.java
! src/java.desktop/share/classes/javax/swing/JScrollPane.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html
! src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java

Changeset: 34b6db069d68
Author:    akolarkunnu
Date:      2019-09-18 07:18 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/34b6db069d68

8165828: [TEST_BUG] The reg case:javax/swing/plaf/metal/MetalIcons/MetalHiDPIIconsTest.java failed as No Metal Look and Feel
Reviewed-by: psadhukhan
Contributed-by: jagjot.singh at oracle.com

! test/jdk/javax/swing/plaf/metal/MetalIcons/MetalHiDPIIconsTest.java

Changeset: d07dea54170b
Author:    psadhukhan
Date:      2019-09-23 13:08 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/d07dea54170b

Merge

- src/hotspot/os_cpu/linux_aarch64/gc/z/zArguments_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.cpp
- src/hotspot/os_cpu/linux_aarch64/gc/z/zGlobals_linux_aarch64.hpp
- src/hotspot/os_cpu/linux_x86/gc/z/zArguments_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.cpp
- src/hotspot/os_cpu/linux_x86/gc/z/zGlobals_linux_x86.hpp
- src/hotspot/share/gc/g1/g1HeapSizingPolicy_ext.cpp
- src/hotspot/share/gc/z/zUtils.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp
- src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp
- src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp
- src/hotspot/share/logging/logTag_ext.hpp
- src/hotspot/share/oops/access.cpp
- src/hotspot/share/runtime/arguments_ext.cpp
- src/hotspot/share/runtime/globals_ext.hpp
- src/hotspot/share/runtime/os_ext.hpp
- src/java.base/share/native/libjava/ObjectInputStream.c
- src/java.base/share/native/libjava/ObjectOutputStream.c
! src/java.desktop/unix/native/common/awt/fontpath.c
- src/jdk.hotspot.agent/share/classes/META-INF/services/com.sun.jdi.connect.Connector
! test/jdk/ProblemList.txt
- test/jdk/java/lang/invoke/findclass.security.policy
- test/jdk/java/nio/charset/coders/SJISMappingPropTest.java
- test/jdk/java/nio/charset/coders/SJISPropTest.java
- test/jdk/java/nio/charset/coders/ref.windows-31j
- test/jdk/java/security/testlibrary/CertUtils.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java
- test/jdk/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java

Changeset: fe46ee1d42ee
Author:    dmarkov
Date:      2019-09-23 17:18 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/fe46ee1d42ee

8230782: Robot.createScreenCapture() fails if ?awt.robot.gtk? is set to false
Reviewed-by: prr, serb

! src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c

Changeset: 483f14c3e0a2
Author:    psadhukhan
Date:      2019-09-25 13:40 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/483f14c3e0a2

Merge

- src/hotspot/os/linux/gc/z/zVirtualMemory_linux.cpp
! src/java.desktop/share/classes/java/awt/Window.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/PolymorphicInliningTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotClassInitializationPlugin.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NormalizeCompareNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java
- src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java

Changeset: de8e08015d51
Author:    psadhukhan
Date:      2019-09-25 14:48 +0530
URL:       https://hg.openjdk.java.net/panama/dev/rev/de8e08015d51

Merge


Changeset: e4ce29f6094e
Author:    weijun
Date:      2019-09-25 17:54 +0800
URL:       https://hg.openjdk.java.net/panama/dev/rev/e4ce29f6094e

8228659: Record which Java methods are called by native codes in JGSS and JAAS
Reviewed-by: mullan

! src/java.security.jgss/macosx/native/libosxkrb5/nativeccache.c
! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSCredElement.java
! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSLibStub.java
! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java
! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java
! src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java
! src/java.security.jgss/share/classes/sun/security/krb5/EncryptionKey.java
! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddresses.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/KerberosTime.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/Krb5.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/Ticket.java
! src/java.security.jgss/share/classes/sun/security/krb5/internal/TicketFlags.java
! src/java.security.jgss/windows/native/libw2k_lsa_auth/NativeCreds.c
! src/jdk.security.auth/share/classes/com/sun/security/auth/module/NTSystem.java
! src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java

Changeset: b311681bc3f9
Author:    roland
Date:      2019-09-17 15:58 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/b311681bc3f9

8231055: C2: arraycopy with same non escaping src and dest but different positions causes wrong execution
Reviewed-by: thartmann, vlivanov

! src/hotspot/share/opto/macro.cpp
! test/hotspot/jtreg/compiler/escapeAnalysis/TestSelfArrayCopy.java

Changeset: f642ad5c655f
Author:    rkennke
Date:      2019-09-25 12:33 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/f642ad5c655f

8231447: Shenandoah: Compilation-time regression after JDK-8231086
Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp

Changeset: cfef85f63f47
Author:    cito
Date:      2019-09-25 20:32 +0900
URL:       https://hg.openjdk.java.net/panama/dev/rev/cfef85f63f47

8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with "java.lang.RuntimeException: assertTrue: expected true, was false"
Reviewed-by: ysuenaga, dcubed

! test/jdk/ProblemList.txt
! test/jdk/jdk/jfr/jcmd/TestJcmdConfigure.java

Changeset: 8573d94a3a00
Author:    azeller
Date:      2019-09-24 14:46 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/8573d94a3a00

8230110: TestLinkageErrorInGenerateOopMap times out
Reviewed-by: stuefe, clanger, thartmann

! test/hotspot/jtreg/compiler/linkage/TestLinkageErrorInGenerateOopMap.java

Changeset: 270abce77942
Author:    phh
Date:      2019-09-25 08:29 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/270abce77942

8231387: java.security.Provider.getService returns random result due to race condition with mutating methods in the same class
Summary: Synchronize access to legacyMap in Provider.getService.
Reviewed-by: valeriep
Contributed-by: Tianmin Shi <tianshi at amazon.com>

! src/java.base/share/classes/java/security/Provider.java
+ test/jdk/java/security/Provider/GetServiceRace.java

Changeset: faf791c5a710
Author:    darcy
Date:      2019-09-25 09:37 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/faf791c5a710

8231442: Suppress warnings on non-serializable instance fields in java.sql.* modules
Reviewed-by: lancea

! src/java.sql.rowset/share/classes/javax/sql/rowset/BaseRowSet.java
! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialArray.java
! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java
! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java
! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialJavaObject.java
! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialRef.java
! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialStruct.java
! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncProviderException.java
! src/java.sql/share/classes/java/sql/SQLClientInfoException.java
! src/java.sql/share/classes/javax/sql/StatementEvent.java

Changeset: c7d9df2e470c
Author:    shade
Date:      2019-09-25 12:21 +0200
URL:       https://hg.openjdk.java.net/panama/dev/rev/c7d9df2e470c

8231410: Shenandoah: clone barrier should use base pointer
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp
+ test/hotspot/jtreg/gc/shenandoah/compiler/TestClone.java

Changeset: f4abe950c3b0
Author:    dtitov
Date:      2019-09-25 11:10 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/f4abe950c3b0

8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth)
Reviewed-by: sspitsyn, dholmes, dcubed, rehn

! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! src/hotspot/share/runtime/threadSMR.cpp
+ src/hotspot/share/services/threadIdTable.cpp
+ src/hotspot/share/services/threadIdTable.hpp

Changeset: 21a03fa2f6b6
Author:    bpb
Date:      2019-09-25 11:44 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/21a03fa2f6b6

8231174: (fs) FileTime should have 100ns resolution (win)
Reviewed-by: alanb

! src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java
! test/jdk/java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java

Changeset: d29f0181ba42
Author:    darcy
Date:      2019-09-25 13:37 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/d29f0181ba42

8231443: Add java.io.Serial to list of platform annotations for annotation processing
Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java

Changeset: ac24594d2c8c
Author:    bchristi
Date:      2019-09-25 14:33 -0700
URL:       https://hg.openjdk.java.net/panama/dev/rev/ac24594d2c8c

8221623: Add StackWalker micro benchmarks to jdk repo
Reviewed-by: dfuchs, mchung, redestad

+ test/micro/org/openjdk/bench/java/lang/StackWalkBench.java
+ test/micro/org/openjdk/bench/java/util/logging/LoggingRuntimeMicros.java
+ test/micro/org/openjdk/bench/vm/lang/ThrowableRuntimeMicros.java


From maurizio.cimadamore at oracle.com  Wed Sep 25 22:09:18 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 25 Sep 2019 22:09:18 +0000
Subject: hg: panama/dev: Automatic merge with default
Message-ID: <201909252209.x8PM9JoK001984@aojmv0008.oracle.com>

Changeset: 98da599656b6
Author:    mcimadamore
Date:      2019-09-25 22:09 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/98da599656b6

Automatic merge with default

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
- src/hotspot/os/linux/gc/z/zVirtualMemory_linux.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
- src/java.base/share/native/libjava/ObjectInputStream.c
- src/java.base/share/native/libjava/ObjectOutputStream.c
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/PolymorphicInliningTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotClassInitializationPlugin.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NormalizeCompareNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java
- src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java
- test/jdk/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java


From maurizio.cimadamore at oracle.com  Wed Sep 25 22:09:44 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 25 Sep 2019 22:09:44 +0000
Subject: hg: panama/dev: Automatic merge with default
Message-ID: <201909252209.x8PM9i05002398@aojmv0008.oracle.com>

Changeset: 876c018ca527
Author:    mcimadamore
Date:      2019-09-25 22:09 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/876c018ca527

Automatic merge with default

! make/autoconf/basics.m4
- src/hotspot/os/linux/gc/z/zVirtualMemory_linux.cpp
! src/java.base/share/classes/java/lang/ClassLoader.java
! src/java.base/share/classes/java/nio/Buffer.java
- src/java.base/share/native/libjava/ObjectInputStream.c
- src/java.base/share/native/libjava/ObjectOutputStream.c
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/PolymorphicInliningTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotClassInitializationPlugin.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NormalizeCompareNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java
- src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java
- test/jdk/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java


From maurizio.cimadamore at oracle.com  Wed Sep 25 22:10:11 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 25 Sep 2019 22:10:11 +0000
Subject: hg: panama/dev: Automatic merge with default
Message-ID: <201909252210.x8PMABfC002885@aojmv0008.oracle.com>

Changeset: e2b9997a423d
Author:    mcimadamore
Date:      2019-09-25 22:09 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/e2b9997a423d

Automatic merge with default

- src/hotspot/os/linux/gc/z/zVirtualMemory_linux.cpp
! src/hotspot/share/ci/ciField.cpp
! src/hotspot/share/opto/library_call.cpp
! src/java.base/share/classes/java/nio/Buffer.java
- src/java.base/share/native/libjava/ObjectInputStream.c
- src/java.base/share/native/libjava/ObjectOutputStream.c
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/PolymorphicInliningTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotClassInitializationPlugin.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NormalizeCompareNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java
- src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java
- test/jdk/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java


From maurizio.cimadamore at oracle.com  Wed Sep 25 22:10:42 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 25 Sep 2019 22:10:42 +0000
Subject: hg: panama/dev: Automatic merge with foreign
Message-ID: <201909252210.x8PMAhfu003295@aojmv0008.oracle.com>

Changeset: f332e21fee1b
Author:    mcimadamore
Date:      2019-09-25 22:10 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/f332e21fee1b

Automatic merge with foreign

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/sparc/sharedRuntime_sparc.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
- src/hotspot/os/linux/gc/z/zVirtualMemory_linux.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/code/compiledMethod.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/thread.hpp
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
- src/java.base/share/native/libjava/ObjectInputStream.c
- src/java.base/share/native/libjava/ObjectOutputStream.c
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/PolymorphicInliningTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotClassInitializationPlugin.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NormalizeCompareNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java
- src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java
- test/jdk/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java


From maurizio.cimadamore at oracle.com  Wed Sep 25 22:11:05 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 25 Sep 2019 22:11:05 +0000
Subject: hg: panama/dev: Automatic merge with linkToNative
Message-ID: <201909252211.x8PMB58n003770@aojmv0008.oracle.com>

Changeset: 63c5aaeb5cc1
Author:    mcimadamore
Date:      2019-09-25 22:10 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/63c5aaeb5cc1

Automatic merge with linkToNative

! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java


From maurizio.cimadamore at oracle.com  Wed Sep 25 22:11:30 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 25 Sep 2019 22:11:30 +0000
Subject: hg: panama/dev: Automatic merge with foreign-memaccess
Message-ID: <201909252211.x8PMBU2O004238@aojmv0008.oracle.com>

Changeset: e216db036ce9
Author:    mcimadamore
Date:      2019-09-25 22:11 +0000
URL:       https://hg.openjdk.java.net/panama/dev/rev/e216db036ce9

Automatic merge with foreign-memaccess

- src/hotspot/os/linux/gc/z/zVirtualMemory_linux.cpp
! src/hotspot/share/ci/ciField.cpp
! src/hotspot/share/opto/library_call.cpp
! src/java.base/share/classes/java/lang/ClassLoader.java
- src/java.base/share/native/libjava/ObjectInputStream.c
- src/java.base/share/native/libjava/ObjectOutputStream.c
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/PolymorphicInliningTest.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotClassInitializationPlugin.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/NormalizeCompareNode.java
- src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/JLModule.java
- src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java
- test/jdk/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java


From samuel.audet at gmail.com  Wed Sep 25 23:03:41 2019
From: samuel.audet at gmail.com (Samuel Audet)
Date: Thu, 26 Sep 2019 08:03:41 +0900
Subject: [foreign-abi] On invokers
In-Reply-To: <af290c98-647a-c27d-0af3-a0a54ff4ffb5@oracle.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
 <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>
 <259447E3-19EC-49D3-BCB4-C20F0E5BF010@oracle.com>
 <821ff859-362e-6121-d4e3-4565ea4b7870@oracle.com>
 <38EF2152-43E5-464C-A66F-CE70B12B5164@oracle.com>
 <cf501b0e-367f-f2a2-219a-c477b12d1290@gmail.com>
 <af290c98-647a-c27d-0af3-a0a54ff4ffb5@oracle.com>
Message-ID: <481d4f31-8f61-be2b-20fd-efb3bc0bd14d@gmail.com>

On 9/25/19 8:32 PM, Maurizio Cimadamore wrote:
> I'd like to point out the irony of your comment: you are complaining 
> about lack of transparency on a thread which is discussing future 
> directions for SystemABI support (where the currently proposed patch 
> only works for Windows, only for downcalls). Speaking about open-ness, I 
> think this is pretty much the best you can get?

Which is great for these parts, like I said, but the same isn't 
happening for other parts, such as anything related C++. Maybe it's 
because you do not have time? I don't know! You're not being transparent.

> I will disregard your comment on "you should do X instead of Y" - which, 
> as been pointed out previously, is not helpful, and I will also 
> disregard your "framework-ish APIs" remark, which is deliberately 
> inflammatory. I think we can do better than that?

I didn't mean it as inflammatory, just that it doesn't fit in the 
API/implementation separation that you're striving to achieve. I could 
elaborate, there are many technical issues with your approach, but since 
you haven't heard me out in the past, I just don't have the feeling that 
you'll hear me out this time around.

> As for vectors, I believe the discussion John is referring to 
> happened/is happening on the CSR front:
> 
> https://bugs.openjdk.java.net/browse/JDK-8223348
> 
> (again, discussion publicly available).

Thanks for the link! That's news to me. As usual, for anything related 
to vector APIs, that's looking great.

> And yes, there are times where, as normal people do, we need to stop and 
> think about what we wanna do before starting a public debate on it. This 
> is about the evolution of the Java platform, not about conducting 
> opinion polls (although sometimes it helps to have dedicated surveys on 
> specific topics, as we have done in the past [1]) - and it is a job that 
> we take very seriously.

I have no doubt of your seriousness, but I do hope you realize one day 
that accepting ideas from outside may be more effective in helping out 
with thorny issues.

Samuel

> 
> Maurizio
> 
> [1] - 
> https://mail.openjdk.java.net/pipermail/amber-dev/2018-February/002669.html
> 
> 
> On 25/09/2019 11:35, Samuel Audet wrote:
>> Hi, John,
>>
>> I must say, I really like the work you guys are doing on the vector 
>> and ABI fronts, it's really great. I sincerely wish Panama could focus 
>> more on that instead of also working on higher-level framework-ish APIs.
>>
>> I have one question though. Where are those "vigourous conversation" 
>> happening? I don't have any quarrel with the work being discussed on 
>> this thread, but it does give me the impression that a lot of the work 
>> related to Panama is done in secret and that we're not getting the 
>> full picture, about other things that I worry about like C++. If 
>> that's the case, that's fine, OpenJDK doesn't need to be "open", but 
>> it would help the community if you could be honest about it.
>>
>> Samuel
>>
>> On 9/25/19 9:25 AM, John Rose wrote:
>>> (*Mature*? non-generalization appears when you have a road map with an endpoint, so you can say things like,
>>> ?You might ask my API to do extra task X, but you should really use a different API for that.?? Folks vary by
>>> temperament which kind of premature-ness they are more likely to fall into.? Y'all know I?m an (a), so of course
>>> I?m always on the lookout for signs of (b), whether they exist or not.? The Vector API is currently having a
>>> vigourous conversation about such choices.)

From maurizio.cimadamore at oracle.com  Wed Sep 25 23:19:24 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 26 Sep 2019 00:19:24 +0100
Subject: [foreign-abi] On invokers
In-Reply-To: <481d4f31-8f61-be2b-20fd-efb3bc0bd14d@gmail.com>
References: <3deaefb5-b31b-5fda-a47a-bb32ce2841ff@oracle.com>
 <dad40974-97f5-dd88-6ae6-5eb8cc826496@oracle.com>
 <4e6cb9c3-4d6a-5027-d4ac-c0c8da9ce5ef@oracle.com>
 <8437467d-fe4e-6233-26f0-31909917d543@oracle.com>
 <ff14a080-e1b1-e02c-e6a4-bcb2814e239f@oracle.com>
 <259447E3-19EC-49D3-BCB4-C20F0E5BF010@oracle.com>
 <821ff859-362e-6121-d4e3-4565ea4b7870@oracle.com>
 <38EF2152-43E5-464C-A66F-CE70B12B5164@oracle.com>
 <cf501b0e-367f-f2a2-219a-c477b12d1290@gmail.com>
 <af290c98-647a-c27d-0af3-a0a54ff4ffb5@oracle.com>
 <481d4f31-8f61-be2b-20fd-efb3bc0bd14d@gmail.com>
Message-ID: <3fa89aec-8605-1c04-89e9-11367e94325b@oracle.com>


On 26/09/2019 00:03, Samuel Audet wrote:
> I didn't mean it as inflammatory, just that it doesn't fit in the 
> API/implementation separation that you're striving to achieve. I could 
> elaborate, there are many technical issues with your approach, but 
> since you haven't heard me out in the past, I just don't have the 
> feeling that you'll hear me out this time around. 

On the contrary, if you have specific feedback on the memory access API 
(foreign-memaccess) branch, or the low-level method handle based API 
(memacess-abi branch) for doing foreign calls, I'd love to hear it. 
Especially the memory access API is getting there in terms of being 
complete - so now would be a good time to provide feedback. But please 
do so on a different thread :-)

Maurizio


From Yang.Zhang at arm.com  Thu Sep 26 08:20:50 2019
From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China))
Date: Thu, 26 Sep 2019 08:20:50 +0000
Subject: [vector] Add test case for vector shuffle operations with C2
Message-ID: <VE1PR08MB4656186C6B629EB7F3E58EC38E860@VE1PR08MB4656.eurprd08.prod.outlook.com>

Hi all

Could anyone please help to review this patch?

Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.shuffletest/webrev.00/

When I add VectorLoadShuffle and VectorRearrange backend support for AArch64 platform, I find that these instructions are not tested fully. In this patch, I add iotaShuffle test case which can test VectorLoadShuffle instruction separately. 

Regards,
Yang





Regards
Yang

From maurizio.cimadamore at oracle.com  Thu Sep 26 16:03:15 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 26 Sep 2019 16:03:15 +0000
Subject: hg: panama/dev: 2 new changesets
Message-ID: <201909261603.x8QG3FTr004508@aojmv0008.oracle.com>

Changeset: 004042b6b07d
Author:    mcimadamore
Date:      2019-09-26 16:57 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/004042b6b07d

8231402: layout API implementation is not constant enough
Reviewed-by: jvernee

! src/hotspot/share/ci/ciField.cpp
! src/java.base/share/classes/java/nio/Buffer.java
! src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AbstractLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/PaddingLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SequenceLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/BufferScope.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapScope.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemoryScope.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemorySegmentImpl.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/NativeScope.java

Changeset: 024e97ca1e6d
Author:    mcimadamore
Date:      2019-09-26 16:59 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/024e97ca1e6d

merge

! src/hotspot/share/ci/ciField.cpp
! src/java.base/share/classes/java/nio/Buffer.java


From maurizio.cimadamore at oracle.com  Thu Sep 26 17:36:32 2019
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 26 Sep 2019 17:36:32 +0000
Subject: hg: panama/dev: manual merge with foreign-memaccess
Message-ID: <201909261736.x8QHaWpc006830@aojmv0008.oracle.com>

Changeset: 8b40230d7c23
Author:    mcimadamore
Date:      2019-09-26 18:30 +0100
URL:       https://hg.openjdk.java.net/panama/dev/rev/8b40230d7c23

manual merge with foreign-memaccess

! src/hotspot/share/ci/ciField.cpp
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/AbstractLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/GroupLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/PaddingLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SequenceLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ValueLayout.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapScope.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemorySegmentImpl.java


From maurizio.cimadamore at oracle.com  Thu Sep 26 18:10:22 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 26 Sep 2019 19:10:22 +0100
Subject: [foreign-memaccess] on shared segments
Message-ID: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>

Hi,
in a previous document [1] I explored the problem of allowing concurrent 
access to a memory segment in a safe fashion. From that exploration, it 
emerged that there was one type of race that was particularly nasty: 
that is, a race between a thread A attempting to close a segment S while 
a thread B is attempting to access (read or write) S.

The presence of this race makes it really hard to generalize the 
existing memory access API to cases where concurrent/shared access is 
needed. Of course one naive solution would be to synchronize every 
access on the liveness check, but that makes performance really poor - 
which would defeat the point of having such an API in the first place.

Instead, to solve that problem, in the document I posit about a solution 
which uses an explicit acquire/release mechanism - that is clients of a 
shared segment will need to explicitly acquire the segment in order to 
be able to operate on it, and release it when done. A shared segment can 
only be closed when all clients are done with the segment - this is what 
ensures temporal safety. Moreover, since each client works on its own 
'acquired' copy of the shared segment, everything is a constant and the 
JIT can see through the code and optimize it in the same way as it does 
for confined access. That said, we never fully committed to that 
solution, since the resulting API was very complex: for things to work, 
part of the MemorySegment API has to be moved under a new abstraction 
(in the document called MemoryHandle) - more specifically the bits that 
are responsible for creating addresses. While it's possible to devise a 
confined segment that is both a MemorySegment and a MemoryHandle (thus 
giving us back the old API), the general feedback I've received is that 
this solution seems a bit too convoluted.

When discussing about this problem with Jim, he pointed out a useful 
connection and a possible way out: after all, all these acquire/release 
and reference counting schemes are there to perform a job that a JVM 
knows exactly how to do at speed: determining whether an object is still 
used or not. So, instead of inventing new machinery, we could simply 
piggy back on the mechanisms we already have - that is GC and Cleaners.

The key realization, in the shared case, can be summarized as: 
performance, safety, deterministic deallocation, pick two! Since we're 
not willing to compromise on safety, or on performance, letting go of 
the deterministic de-allocation goal (only for shared segments) seems a 
reasonable conclusion.

In other words, there are now two kinds of segments: /confined/ segment 
and /shared/ segments. A segment always starts off as confined, and has 
an owning thread. You can update the owning thread - effectively nuking 
the existing segment and obtaining a new segment that is confined on a 
new thread. This allows clients to achieve serialized thread-confinement 
use cases - where multiple threads operate on a piece of memory one at a 
time. Confined segments are operated upon as usual: you allocate a 
segment, you use it, you close it (or you use a try with resources to do 
it all automagically).

If clients want more - e.g. full concurrent access, an API point is 
provided to turn a confined segment into a shared one. Again, what 
happens here is that the existing segment will be nuked, and a new 
shared segment will be created. But, this shared segment _cannot be 
closed_ (e.g. it is pinned, using the existing API terminology). So, how 
are off-heap resources released if we can't close the segment? Well, we 
let the GC take care of it - by registering the segment on a Cleaner, 
and have the cleaner call some cleanup code once the segment is no 
longer referenced (in reality, things are a bit different, in the sense 
that what we really? key on is the _scope_ of a segment, which might be 
shared across multiple views, but the essence is the same). In other 
words, deallocation for shared segments works pretty much the same way 
deallocation of direct buffer work.

With this move, we are able to retain the simplicity of the existing 
API, while also being able to support efficient and safe concurrent access.

A webrev implementing this change is available here:

http://cr.openjdk.java.net/~mcimadamore/panama/shared-segments_v2/

Implementation-wise things are, I think, quite straightforward. I took 
sometime to refactor the code, to make the various scope subclasses 
disappear. We now have a single memory segment implementation and two 
scopes: shared and confined. The confined scope takes a 'Runnable' 
cleanup action which is used (i) when closing the confined segment or 
(ii) passed onto the Cleaner by the shared scope if the segment is 
upgraded to 'shared' state. Also, since shared segment now can now be 
picked up by Cleaner when no longer referenced, it is crucial that we 
add in reachability fences around Unsafe operations (same way as direct 
buffer does really). This is because sometimes the GC can aggressively 
collect unused objects stored in local variables during method 
execution. Adding these fences doesn't negatively impact performances 
(in fact, I'm told these fences are a no-op in Hotspot).

I also took some effort to update some of the javadoc which are rendered 
invalid by this change.

Comments welcome

Maurizio

[1] - http://cr.openjdk.java.net/~mcimadamore/panama/confinement.html


From brian.goetz at oracle.com  Thu Sep 26 18:20:05 2019
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 26 Sep 2019 14:20:05 -0400
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
Message-ID: <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>

I think this approach balances the requirements cleanly.? It puts the 
cost of concurrent access on the current use cases -- by requiring an 
extra step to set up the shared buffer -- without perturbing the rest of 
the API or the performance of the confined use cases.

On 9/26/2019 2:10 PM, Maurizio Cimadamore wrote:
> Hi,
> in a previous document [1] I explored the problem of allowing 
> concurrent access to a memory segment in a safe fashion. From that 
> exploration, it emerged that there was one type of race that was 
> particularly nasty: that is, a race between a thread A attempting to 
> close a segment S while a thread B is attempting to access (read or 
> write) S.
>
> The presence of this race makes it really hard to generalize the 
> existing memory access API to cases where concurrent/shared access is 
> needed. Of course one naive solution would be to synchronize every 
> access on the liveness check, but that makes performance really poor - 
> which would defeat the point of having such an API in the first place.
>
> Instead, to solve that problem, in the document I posit about a 
> solution which uses an explicit acquire/release mechanism - that is 
> clients of a shared segment will need to explicitly acquire the 
> segment in order to be able to operate on it, and release it when 
> done. A shared segment can only be closed when all clients are done 
> with the segment - this is what ensures temporal safety. Moreover, 
> since each client works on its own 'acquired' copy of the shared 
> segment, everything is a constant and the JIT can see through the code 
> and optimize it in the same way as it does for confined access. That 
> said, we never fully committed to that solution, since the resulting 
> API was very complex: for things to work, part of the MemorySegment 
> API has to be moved under a new abstraction (in the document called 
> MemoryHandle) - more specifically the bits that are responsible for 
> creating addresses. While it's possible to devise a confined segment 
> that is both a MemorySegment and a MemoryHandle (thus giving us back 
> the old API), the general feedback I've received is that this solution 
> seems a bit too convoluted.
>
> When discussing about this problem with Jim, he pointed out a useful 
> connection and a possible way out: after all, all these 
> acquire/release and reference counting schemes are there to perform a 
> job that a JVM knows exactly how to do at speed: determining whether 
> an object is still used or not. So, instead of inventing new 
> machinery, we could simply piggy back on the mechanisms we already 
> have - that is GC and Cleaners.
>
> The key realization, in the shared case, can be summarized as: 
> performance, safety, deterministic deallocation, pick two! Since we're 
> not willing to compromise on safety, or on performance, letting go of 
> the deterministic de-allocation goal (only for shared segments) seems 
> a reasonable conclusion.
>
> In other words, there are now two kinds of segments: /confined/ 
> segment and /shared/ segments. A segment always starts off as 
> confined, and has an owning thread. You can update the owning thread - 
> effectively nuking the existing segment and obtaining a new segment 
> that is confined on a new thread. This allows clients to achieve 
> serialized thread-confinement use cases - where multiple threads 
> operate on a piece of memory one at a time. Confined segments are 
> operated upon as usual: you allocate a segment, you use it, you close 
> it (or you use a try with resources to do it all automagically).
>
> If clients want more - e.g. full concurrent access, an API point is 
> provided to turn a confined segment into a shared one. Again, what 
> happens here is that the existing segment will be nuked, and a new 
> shared segment will be created. But, this shared segment _cannot be 
> closed_ (e.g. it is pinned, using the existing API terminology). So, 
> how are off-heap resources released if we can't close the segment? 
> Well, we let the GC take care of it - by registering the segment on a 
> Cleaner, and have the cleaner call some cleanup code once the segment 
> is no longer referenced (in reality, things are a bit different, in 
> the sense that what we really? key on is the _scope_ of a segment, 
> which might be shared across multiple views, but the essence is the 
> same). In other words, deallocation for shared segments works pretty 
> much the same way deallocation of direct buffer work.
>
> With this move, we are able to retain the simplicity of the existing 
> API, while also being able to support efficient and safe concurrent 
> access.
>
> A webrev implementing this change is available here:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/shared-segments_v2/
>
> Implementation-wise things are, I think, quite straightforward. I took 
> sometime to refactor the code, to make the various scope subclasses 
> disappear. We now have a single memory segment implementation and two 
> scopes: shared and confined. The confined scope takes a 'Runnable' 
> cleanup action which is used (i) when closing the confined segment or 
> (ii) passed onto the Cleaner by the shared scope if the segment is 
> upgraded to 'shared' state. Also, since shared segment now can now be 
> picked up by Cleaner when no longer referenced, it is crucial that we 
> add in reachability fences around Unsafe operations (same way as 
> direct buffer does really). This is because sometimes the GC can 
> aggressively collect unused objects stored in local variables during 
> method execution. Adding these fences doesn't negatively impact 
> performances (in fact, I'm told these fences are a no-op in Hotspot).
>
> I also took some effort to update some of the javadoc which are 
> rendered invalid by this change.
>
> Comments welcome
>
> Maurizio
>
> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/confinement.html
>


From maurizio.cimadamore at oracle.com  Thu Sep 26 20:07:09 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 26 Sep 2019 21:07:09 +0100
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
Message-ID: <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>


On 26/09/2019 19:20, Brian Goetz wrote:
> I think this approach balances the requirements cleanly.? It puts the 
> cost of concurrent access on the current use cases -- by requiring an 
> extra step to set up the shared buffer -- without perturbing the rest 
> of the API or the performance of the confined use cases.

Thanks.

Btw, forgot to mention - this opens up another round of "how should the 
asXYZ" methods be called. Before we had:

slice(long, long) -> segment with smaller bounds

asReadOnly() -> read only segment
asPinned() -> non closeabe segment

Now we also have

asConfined(Thread) -> make a new confined segment with different owner
asShared() -> make a new shared segment


I think slice, asReadOnly and asPinned can be seen as 'views' - that is, 
their temporal scope is the same as the segment they come from. 
asConfined and asShared are different beasts.

For now I used the asXYZ for everything, but I'm conscious that maybe a 
better naming scheme exists.

Also, there is a question of what asConfined and asShared should do in 
the case where no change is needed - that is, if you call asConfined(A) 
on a segment already owned by A - what happens? Similarly, if you call 
asShared() on an already shared segment, what happens? I think we have 
three choices:

1) give an error - seems harsh
2) return same segment - less harsh, but seems irregular - sometimes the 
segment is killed, sometimes is not
3) kill current segment and return new segment every time - seems also a 
bit harsh

(the patch I shared is a bit inconsistent in that it does (2) for 
asShared, but (3) for asConfined)

I don't have any particular strong preference for any of the choices, 
other than I kind of dislike (3). (2) seems reasonable overall. Opinions?

Maurizio

>
> On 9/26/2019 2:10 PM, Maurizio Cimadamore wrote:
>> Hi,
>> in a previous document [1] I explored the problem of allowing 
>> concurrent access to a memory segment in a safe fashion. From that 
>> exploration, it emerged that there was one type of race that was 
>> particularly nasty: that is, a race between a thread A attempting to 
>> close a segment S while a thread B is attempting to access (read or 
>> write) S.
>>
>> The presence of this race makes it really hard to generalize the 
>> existing memory access API to cases where concurrent/shared access is 
>> needed. Of course one naive solution would be to synchronize every 
>> access on the liveness check, but that makes performance really poor 
>> - which would defeat the point of having such an API in the first place.
>>
>> Instead, to solve that problem, in the document I posit about a 
>> solution which uses an explicit acquire/release mechanism - that is 
>> clients of a shared segment will need to explicitly acquire the 
>> segment in order to be able to operate on it, and release it when 
>> done. A shared segment can only be closed when all clients are done 
>> with the segment - this is what ensures temporal safety. Moreover, 
>> since each client works on its own 'acquired' copy of the shared 
>> segment, everything is a constant and the JIT can see through the 
>> code and optimize it in the same way as it does for confined access. 
>> That said, we never fully committed to that solution, since the 
>> resulting API was very complex: for things to work, part of the 
>> MemorySegment API has to be moved under a new abstraction (in the 
>> document called MemoryHandle) - more specifically the bits that are 
>> responsible for creating addresses. While it's possible to devise a 
>> confined segment that is both a MemorySegment and a MemoryHandle 
>> (thus giving us back the old API), the general feedback I've received 
>> is that this solution seems a bit too convoluted.
>>
>> When discussing about this problem with Jim, he pointed out a useful 
>> connection and a possible way out: after all, all these 
>> acquire/release and reference counting schemes are there to perform a 
>> job that a JVM knows exactly how to do at speed: determining whether 
>> an object is still used or not. So, instead of inventing new 
>> machinery, we could simply piggy back on the mechanisms we already 
>> have - that is GC and Cleaners.
>>
>> The key realization, in the shared case, can be summarized as: 
>> performance, safety, deterministic deallocation, pick two! Since 
>> we're not willing to compromise on safety, or on performance, letting 
>> go of the deterministic de-allocation goal (only for shared segments) 
>> seems a reasonable conclusion.
>>
>> In other words, there are now two kinds of segments: /confined/ 
>> segment and /shared/ segments. A segment always starts off as 
>> confined, and has an owning thread. You can update the owning thread 
>> - effectively nuking the existing segment and obtaining a new segment 
>> that is confined on a new thread. This allows clients to achieve 
>> serialized thread-confinement use cases - where multiple threads 
>> operate on a piece of memory one at a time. Confined segments are 
>> operated upon as usual: you allocate a segment, you use it, you close 
>> it (or you use a try with resources to do it all automagically).
>>
>> If clients want more - e.g. full concurrent access, an API point is 
>> provided to turn a confined segment into a shared one. Again, what 
>> happens here is that the existing segment will be nuked, and a new 
>> shared segment will be created. But, this shared segment _cannot be 
>> closed_ (e.g. it is pinned, using the existing API terminology). So, 
>> how are off-heap resources released if we can't close the segment? 
>> Well, we let the GC take care of it - by registering the segment on a 
>> Cleaner, and have the cleaner call some cleanup code once the segment 
>> is no longer referenced (in reality, things are a bit different, in 
>> the sense that what we really? key on is the _scope_ of a segment, 
>> which might be shared across multiple views, but the essence is the 
>> same). In other words, deallocation for shared segments works pretty 
>> much the same way deallocation of direct buffer work.
>>
>> With this move, we are able to retain the simplicity of the existing 
>> API, while also being able to support efficient and safe concurrent 
>> access.
>>
>> A webrev implementing this change is available here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/panama/shared-segments_v2/
>>
>> Implementation-wise things are, I think, quite straightforward. I 
>> took sometime to refactor the code, to make the various scope 
>> subclasses disappear. We now have a single memory segment 
>> implementation and two scopes: shared and confined. The confined 
>> scope takes a 'Runnable' cleanup action which is used (i) when 
>> closing the confined segment or (ii) passed onto the Cleaner by the 
>> shared scope if the segment is upgraded to 'shared' state. Also, 
>> since shared segment now can now be picked up by Cleaner when no 
>> longer referenced, it is crucial that we add in reachability fences 
>> around Unsafe operations (same way as direct buffer does really). 
>> This is because sometimes the GC can aggressively collect unused 
>> objects stored in local variables during method execution. Adding 
>> these fences doesn't negatively impact performances (in fact, I'm 
>> told these fences are a no-op in Hotspot).
>>
>> I also took some effort to update some of the javadoc which are 
>> rendered invalid by this change.
>>
>> Comments welcome
>>
>> Maurizio
>>
>> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/confinement.html
>>
>

From vivek.r.deshpande at intel.com  Thu Sep 26 22:22:38 2019
From: vivek.r.deshpande at intel.com (Deshpande, Vivek R)
Date: Thu, 26 Sep 2019 22:22:38 +0000
Subject: [vector]: Unslice - modification of the argument vector
Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C527B@fmsmsx121.amr.corp.intel.com>

Hi

I have been experimenting with unslice(int origin, vector w, int part) version.
I noticed that the vector w gets modified after the execution of the API in the Java implementation.

This stems from usage of getElements() in unslicTemplate() and the res[] array points to the same array in the w vector.
The line System.arraycopy() causes the actual overwriting.

The code I tried is given below: (Here the values of ev vector are modified after execution of unslice method.)
            IntVector dv = IntVector.fromArray(SPECIES1, d, i);
            IntVector ev = IntVector.fromArray(SPECIES1, e, i);
            IntVector dv_v2 = dv.unslice(2, ev, 1);
            dv_v2.intoArray(f, i);

Regards,
Vivek

From john.r.rose at oracle.com  Thu Sep 26 22:27:29 2019
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 26 Sep 2019 15:27:29 -0700
Subject: [vector]: Unslice - modification of the argument vector
In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C527B@fmsmsx121.amr.corp.intel.com>
References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C527B@fmsmsx121.amr.corp.intel.com>
Message-ID: <41BC2512-F0B6-4798-B121-E9DBFA1A70AA@oracle.com>

On Sep 26, 2019, at 3:22 PM, Deshpande, Vivek R <vivek.r.deshpande at intel.com> wrote:
> 
> Hi
>  
> I have been experimenting with unslice(int origin, vector w, int part) version.
> I noticed that the vector w gets modified after the execution of the API in the Java implementation.
>  
> This stems from usage of getElements() in unslicTemplate() and the res[] array points to the same array in the w vector.
> The line System.arraycopy() causes the actual overwriting.
>  
> The code I tried is given below: (Here the values of ev vector are modified after execution of unslice method.)
>             IntVector dv = IntVector.fromArray(SPECIES1, d, i);
>             IntVector ev = IntVector.fromArray(SPECIES1, e, i);
>             IntVector dv_v2 = dv.unslice(2, ev, 1);
>             dv_v2.intoArray(f, i);
>  

Oops, that?s a bug (my bug).  I guess I forgot that getElements returns an unsafely aliased array.

Suggestion:  Change the name of getElements() to vec() since that?s what it really is, an access
to the raw ?vec? field in the vector implementation.  Nobody will mistake it for a high-level API
point, whereas ?getElements? looks like something formal and safe.

Then, revisit all uses to see if there are any other bugs like this.

? John

From jorn.vernee at oracle.com  Fri Sep 27 10:46:25 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Fri, 27 Sep 2019 12:46:25 +0200
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
 <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
Message-ID: <ce7db07b-0104-4e18-ed5e-bfea5421ca7d@oracle.com>

2) seems fine to me. We can phrase the doc to be vague about whether a 
newly created segment will be returned, and just say we will return 'a 
segment with properties XYZ', then returning the same segment in some 
cases will just be an implementation detail.

1) definitely seems wrong. If 2 different use sites want to make sure 
the segment is confined to the current thread, and that just so happens 
to be the same thread for both use sites we get an error. In that case I 
feel like we'd need to add predicates to test whether a thread is 
already confined to a given thread, or shared (we have the latter in the 
prototype), so users can avoid these errors without having to use 
try/catch around different asXYZ calls.

3) in that same vain, also seems harsh since a user might have to 
redundantly call asConfined() or asShared() to make sure they can use 
the segment. It seems reasonable that this does not incur any unneeded 
overhead. What are the motivations for doing 3 over 2? other than living 
up to an expectation that a new segment would be returned (which I 
believe is a question of not making that promise in the spec/doc).

Reading through the code, there is one caveat that doesn't seem to be 
addressed yet; only the owning thread can call asShared() or 
asConfined() (not being checked currently), and, at least for 
asConfined(), I think the owning thread has to submit to a full fence 
before transferring the segment to make sure no accesses 'spill over' 
into the new state.

Jorn

On 26/09/2019 22:07, Maurizio Cimadamore wrote:
>
> On 26/09/2019 19:20, Brian Goetz wrote:
>> I think this approach balances the requirements cleanly.? It puts the 
>> cost of concurrent access on the current use cases -- by requiring an 
>> extra step to set up the shared buffer -- without perturbing the rest 
>> of the API or the performance of the confined use cases.
>
> Thanks.
>
> Btw, forgot to mention - this opens up another round of "how should 
> the asXYZ" methods be called. Before we had:
>
> slice(long, long) -> segment with smaller bounds
>
> asReadOnly() -> read only segment
> asPinned() -> non closeabe segment
>
> Now we also have
>
> asConfined(Thread) -> make a new confined segment with different owner
> asShared() -> make a new shared segment
>
>
> I think slice, asReadOnly and asPinned can be seen as 'views' - that 
> is, their temporal scope is the same as the segment they come from. 
> asConfined and asShared are different beasts.
>
> For now I used the asXYZ for everything, but I'm conscious that maybe 
> a better naming scheme exists.
>
> Also, there is a question of what asConfined and asShared should do in 
> the case where no change is needed - that is, if you call 
> asConfined(A) on a segment already owned by A - what happens? 
> Similarly, if you call asShared() on an already shared segment, what 
> happens? I think we have three choices:
>
> 1) give an error - seems harsh
> 2) return same segment - less harsh, but seems irregular - sometimes 
> the segment is killed, sometimes is not
> 3) kill current segment and return new segment every time - seems also 
> a bit harsh
>
> (the patch I shared is a bit inconsistent in that it does (2) for 
> asShared, but (3) for asConfined)
>
> I don't have any particular strong preference for any of the choices, 
> other than I kind of dislike (3). (2) seems reasonable overall. Opinions?
>
> Maurizio
>
>>
>> On 9/26/2019 2:10 PM, Maurizio Cimadamore wrote:
>>> Hi,
>>> in a previous document [1] I explored the problem of allowing 
>>> concurrent access to a memory segment in a safe fashion. From that 
>>> exploration, it emerged that there was one type of race that was 
>>> particularly nasty: that is, a race between a thread A attempting to 
>>> close a segment S while a thread B is attempting to access (read or 
>>> write) S.
>>>
>>> The presence of this race makes it really hard to generalize the 
>>> existing memory access API to cases where concurrent/shared access 
>>> is needed. Of course one naive solution would be to synchronize 
>>> every access on the liveness check, but that makes performance 
>>> really poor - which would defeat the point of having such an API in 
>>> the first place.
>>>
>>> Instead, to solve that problem, in the document I posit about a 
>>> solution which uses an explicit acquire/release mechanism - that is 
>>> clients of a shared segment will need to explicitly acquire the 
>>> segment in order to be able to operate on it, and release it when 
>>> done. A shared segment can only be closed when all clients are done 
>>> with the segment - this is what ensures temporal safety. Moreover, 
>>> since each client works on its own 'acquired' copy of the shared 
>>> segment, everything is a constant and the JIT can see through the 
>>> code and optimize it in the same way as it does for confined access. 
>>> That said, we never fully committed to that solution, since the 
>>> resulting API was very complex: for things to work, part of the 
>>> MemorySegment API has to be moved under a new abstraction (in the 
>>> document called MemoryHandle) - more specifically the bits that are 
>>> responsible for creating addresses. While it's possible to devise a 
>>> confined segment that is both a MemorySegment and a MemoryHandle 
>>> (thus giving us back the old API), the general feedback I've 
>>> received is that this solution seems a bit too convoluted.
>>>
>>> When discussing about this problem with Jim, he pointed out a useful 
>>> connection and a possible way out: after all, all these 
>>> acquire/release and reference counting schemes are there to perform 
>>> a job that a JVM knows exactly how to do at speed: determining 
>>> whether an object is still used or not. So, instead of inventing new 
>>> machinery, we could simply piggy back on the mechanisms we already 
>>> have - that is GC and Cleaners.
>>>
>>> The key realization, in the shared case, can be summarized as: 
>>> performance, safety, deterministic deallocation, pick two! Since 
>>> we're not willing to compromise on safety, or on performance, 
>>> letting go of the deterministic de-allocation goal (only for shared 
>>> segments) seems a reasonable conclusion.
>>>
>>> In other words, there are now two kinds of segments: /confined/ 
>>> segment and /shared/ segments. A segment always starts off as 
>>> confined, and has an owning thread. You can update the owning thread 
>>> - effectively nuking the existing segment and obtaining a new 
>>> segment that is confined on a new thread. This allows clients to 
>>> achieve serialized thread-confinement use cases - where multiple 
>>> threads operate on a piece of memory one at a time. Confined 
>>> segments are operated upon as usual: you allocate a segment, you use 
>>> it, you close it (or you use a try with resources to do it all 
>>> automagically).
>>>
>>> If clients want more - e.g. full concurrent access, an API point is 
>>> provided to turn a confined segment into a shared one. Again, what 
>>> happens here is that the existing segment will be nuked, and a new 
>>> shared segment will be created. But, this shared segment _cannot be 
>>> closed_ (e.g. it is pinned, using the existing API terminology). So, 
>>> how are off-heap resources released if we can't close the segment? 
>>> Well, we let the GC take care of it - by registering the segment on 
>>> a Cleaner, and have the cleaner call some cleanup code once the 
>>> segment is no longer referenced (in reality, things are a bit 
>>> different, in the sense that what we really? key on is the _scope_ 
>>> of a segment, which might be shared across multiple views, but the 
>>> essence is the same). In other words, deallocation for shared 
>>> segments works pretty much the same way deallocation of direct 
>>> buffer work.
>>>
>>> With this move, we are able to retain the simplicity of the existing 
>>> API, while also being able to support efficient and safe concurrent 
>>> access.
>>>
>>> A webrev implementing this change is available here:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/panama/shared-segments_v2/
>>>
>>> Implementation-wise things are, I think, quite straightforward. I 
>>> took sometime to refactor the code, to make the various scope 
>>> subclasses disappear. We now have a single memory segment 
>>> implementation and two scopes: shared and confined. The confined 
>>> scope takes a 'Runnable' cleanup action which is used (i) when 
>>> closing the confined segment or (ii) passed onto the Cleaner by the 
>>> shared scope if the segment is upgraded to 'shared' state. Also, 
>>> since shared segment now can now be picked up by Cleaner when no 
>>> longer referenced, it is crucial that we add in reachability fences 
>>> around Unsafe operations (same way as direct buffer does really). 
>>> This is because sometimes the GC can aggressively collect unused 
>>> objects stored in local variables during method execution. Adding 
>>> these fences doesn't negatively impact performances (in fact, I'm 
>>> told these fences are a no-op in Hotspot).
>>>
>>> I also took some effort to update some of the javadoc which are 
>>> rendered invalid by this change.
>>>
>>> Comments welcome
>>>
>>> Maurizio
>>>
>>> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/confinement.html
>>>
>>

From james.laskey at oracle.com  Fri Sep 27 11:29:32 2019
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 27 Sep 2019 08:29:32 -0300
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
 <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
Message-ID: <74F01DC6-145F-490D-BF56-E9ECF2B68A1F@oracle.com>

Most definitely 2). If the developer creates generalized code, they may not have control of the origin. asShared/asConfined as no-ops are a form of guarantee. Of course, asConfined on a shared segment has an interesting story to tell. I think it has to be a copying semantic; not sure an error is helpful there.

> On Sep 26, 2019, at 5:07 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 26/09/2019 19:20, Brian Goetz wrote:
>> I think this approach balances the requirements cleanly.  It puts the cost of concurrent access on the current use cases -- by requiring an extra step to set up the shared buffer -- without perturbing the rest of the API or the performance of the confined use cases.
> 
> Thanks.
> 
> Btw, forgot to mention - this opens up another round of "how should the asXYZ" methods be called. Before we had:
> 
> slice(long, long) -> segment with smaller bounds
> 
> asReadOnly() -> read only segment
> asPinned() -> non closeabe segment
> 
> Now we also have
> 
> asConfined(Thread) -> make a new confined segment with different owner
> asShared() -> make a new shared segment
> 
> 
> I think slice, asReadOnly and asPinned can be seen as 'views' - that is, their temporal scope is the same as the segment they come from. asConfined and asShared are different beasts.
> 
> For now I used the asXYZ for everything, but I'm conscious that maybe a better naming scheme exists.
> 
> Also, there is a question of what asConfined and asShared should do in the case where no change is needed - that is, if you call asConfined(A) on a segment already owned by A - what happens? Similarly, if you call asShared() on an already shared segment, what happens? I think we have three choices:
> 
> 1) give an error - seems harsh
> 2) return same segment - less harsh, but seems irregular - sometimes the segment is killed, sometimes is not
> 3) kill current segment and return new segment every time - seems also a bit harsh
> 
> (the patch I shared is a bit inconsistent in that it does (2) for asShared, but (3) for asConfined)
> 
> I don't have any particular strong preference for any of the choices, other than I kind of dislike (3). (2) seems reasonable overall. Opinions?
> 
> Maurizio
> 
>> 
>> On 9/26/2019 2:10 PM, Maurizio Cimadamore wrote:
>>> Hi,
>>> in a previous document [1] I explored the problem of allowing concurrent access to a memory segment in a safe fashion. From that exploration, it emerged that there was one type of race that was particularly nasty: that is, a race between a thread A attempting to close a segment S while a thread B is attempting to access (read or write) S.
>>> 
>>> The presence of this race makes it really hard to generalize the existing memory access API to cases where concurrent/shared access is needed. Of course one naive solution would be to synchronize every access on the liveness check, but that makes performance really poor - which would defeat the point of having such an API in the first place.
>>> 
>>> Instead, to solve that problem, in the document I posit about a solution which uses an explicit acquire/release mechanism - that is clients of a shared segment will need to explicitly acquire the segment in order to be able to operate on it, and release it when done. A shared segment can only be closed when all clients are done with the segment - this is what ensures temporal safety. Moreover, since each client works on its own 'acquired' copy of the shared segment, everything is a constant and the JIT can see through the code and optimize it in the same way as it does for confined access. That said, we never fully committed to that solution, since the resulting API was very complex: for things to work, part of the MemorySegment API has to be moved under a new abstraction (in the document called MemoryHandle) - more specifically the bits that are responsible for creating addresses. While it's possible to devise a confined segment that is both a MemorySegment and a MemoryHandle (thus giving us back the old API), the general feedback I've received is that this solution seems a bit too convoluted.
>>> 
>>> When discussing about this problem with Jim, he pointed out a useful connection and a possible way out: after all, all these acquire/release and reference counting schemes are there to perform a job that a JVM knows exactly how to do at speed: determining whether an object is still used or not. So, instead of inventing new machinery, we could simply piggy back on the mechanisms we already have - that is GC and Cleaners.
>>> 
>>> The key realization, in the shared case, can be summarized as: performance, safety, deterministic deallocation, pick two! Since we're not willing to compromise on safety, or on performance, letting go of the deterministic de-allocation goal (only for shared segments) seems a reasonable conclusion.
>>> 
>>> In other words, there are now two kinds of segments: /confined/ segment and /shared/ segments. A segment always starts off as confined, and has an owning thread. You can update the owning thread - effectively nuking the existing segment and obtaining a new segment that is confined on a new thread. This allows clients to achieve serialized thread-confinement use cases - where multiple threads operate on a piece of memory one at a time. Confined segments are operated upon as usual: you allocate a segment, you use it, you close it (or you use a try with resources to do it all automagically).
>>> 
>>> If clients want more - e.g. full concurrent access, an API point is provided to turn a confined segment into a shared one. Again, what happens here is that the existing segment will be nuked, and a new shared segment will be created. But, this shared segment _cannot be closed_ (e.g. it is pinned, using the existing API terminology). So, how are off-heap resources released if we can't close the segment? Well, we let the GC take care of it - by registering the segment on a Cleaner, and have the cleaner call some cleanup code once the segment is no longer referenced (in reality, things are a bit different, in the sense that what we really  key on is the _scope_ of a segment, which might be shared across multiple views, but the essence is the same). In other words, deallocation for shared segments works pretty much the same way deallocation of direct buffer work.
>>> 
>>> With this move, we are able to retain the simplicity of the existing API, while also being able to support efficient and safe concurrent access.
>>> 
>>> A webrev implementing this change is available here:
>>> 
>>> http://cr.openjdk.java.net/~mcimadamore/panama/shared-segments_v2/
>>> 
>>> Implementation-wise things are, I think, quite straightforward. I took sometime to refactor the code, to make the various scope subclasses disappear. We now have a single memory segment implementation and two scopes: shared and confined. The confined scope takes a 'Runnable' cleanup action which is used (i) when closing the confined segment or (ii) passed onto the Cleaner by the shared scope if the segment is upgraded to 'shared' state. Also, since shared segment now can now be picked up by Cleaner when no longer referenced, it is crucial that we add in reachability fences around Unsafe operations (same way as direct buffer does really). This is because sometimes the GC can aggressively collect unused objects stored in local variables during method execution. Adding these fences doesn't negatively impact performances (in fact, I'm told these fences are a no-op in Hotspot).
>>> 
>>> I also took some effort to update some of the javadoc which are rendered invalid by this change.
>>> 
>>> Comments welcome
>>> 
>>> Maurizio
>>> 
>>> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/confinement.html
>>> 
>> 


From maurizio.cimadamore at oracle.com  Fri Sep 27 11:54:47 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 27 Sep 2019 12:54:47 +0100
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <ce7db07b-0104-4e18-ed5e-bfea5421ca7d@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
 <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
 <ce7db07b-0104-4e18-ed5e-bfea5421ca7d@oracle.com>
Message-ID: <d8b1ff16-1332-bb76-d7e1-45e23063fd28@oracle.com>


On 27/09/2019 11:46, Jorn Vernee wrote:
> Reading through the code, there is one caveat that doesn't seem to be 
> addressed yet; only the owning thread can call asShared() or 
> asConfined() (not being checked currently), and, at least for 
> asConfined(), I think the owning thread has to submit to a full fence 
> before transferring the segment to make sure no accesses 'spill over' 
> into the new state. 

Right, I should add the checks.

Not sure about the fence - I thought about that. We are creating a _new_ 
object, and invalidating an old one. Only the old thread has access to 
the old one, so it cannot possibly perform access on the old segment 
AFTER it is closed. And, the new thread cannot access the segment before 
the old thread is actually inside the transfer code (which means he's 
done with the segment already).

If we were modifying the ownership in place, I'd agree a fence would be 
in order - but here?

Maurizio


From maurizio.cimadamore at oracle.com  Fri Sep 27 11:57:22 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 27 Sep 2019 12:57:22 +0100
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <74F01DC6-145F-490D-BF56-E9ECF2B68A1F@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
 <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
 <74F01DC6-145F-490D-BF56-E9ECF2B68A1F@oracle.com>
Message-ID: <9ea48227-3479-7346-4cd9-7da64966dd7d@oracle.com>


On 27/09/2019 12:29, Jim Laskey wrote:
> Most definitely 2). If the developer creates generalized code, they may not have control of the origin. asShared/asConfined as no-ops are a form of guarantee. Of course, asConfined on a shared segment has an interesting story to tell. I think it has to be a copying semantic; not sure an error is helpful there.

Copying semantics seems odd - that would introduce synchronization 
requirements (how do you make sure what you copy is in a consistent 
state, since the segment is shared?) - which means locking which means 
poor performances (as access has to check if somebody is doing a copy).

Once you switch to the dark side (shared) there's no going back... copy 
can be implemented by the user, using whatever synchronization mechanism 
it wants.

Maurizio

>> On Sep 26, 2019, at 5:07 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>>
>> On 26/09/2019 19:20, Brian Goetz wrote:
>>> I think this approach balances the requirements cleanly.  It puts the cost of concurrent access on the current use cases -- by requiring an extra step to set up the shared buffer -- without perturbing the rest of the API or the performance of the confined use cases.
>> Thanks.
>>
>> Btw, forgot to mention - this opens up another round of "how should the asXYZ" methods be called. Before we had:
>>
>> slice(long, long) -> segment with smaller bounds
>>
>> asReadOnly() -> read only segment
>> asPinned() -> non closeabe segment
>>
>> Now we also have
>>
>> asConfined(Thread) -> make a new confined segment with different owner
>> asShared() -> make a new shared segment
>>
>>
>> I think slice, asReadOnly and asPinned can be seen as 'views' - that is, their temporal scope is the same as the segment they come from. asConfined and asShared are different beasts.
>>
>> For now I used the asXYZ for everything, but I'm conscious that maybe a better naming scheme exists.
>>
>> Also, there is a question of what asConfined and asShared should do in the case where no change is needed - that is, if you call asConfined(A) on a segment already owned by A - what happens? Similarly, if you call asShared() on an already shared segment, what happens? I think we have three choices:
>>
>> 1) give an error - seems harsh
>> 2) return same segment - less harsh, but seems irregular - sometimes the segment is killed, sometimes is not
>> 3) kill current segment and return new segment every time - seems also a bit harsh
>>
>> (the patch I shared is a bit inconsistent in that it does (2) for asShared, but (3) for asConfined)
>>
>> I don't have any particular strong preference for any of the choices, other than I kind of dislike (3). (2) seems reasonable overall. Opinions?
>>
>> Maurizio
>>
>>> On 9/26/2019 2:10 PM, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> in a previous document [1] I explored the problem of allowing concurrent access to a memory segment in a safe fashion. From that exploration, it emerged that there was one type of race that was particularly nasty: that is, a race between a thread A attempting to close a segment S while a thread B is attempting to access (read or write) S.
>>>>
>>>> The presence of this race makes it really hard to generalize the existing memory access API to cases where concurrent/shared access is needed. Of course one naive solution would be to synchronize every access on the liveness check, but that makes performance really poor - which would defeat the point of having such an API in the first place.
>>>>
>>>> Instead, to solve that problem, in the document I posit about a solution which uses an explicit acquire/release mechanism - that is clients of a shared segment will need to explicitly acquire the segment in order to be able to operate on it, and release it when done. A shared segment can only be closed when all clients are done with the segment - this is what ensures temporal safety. Moreover, since each client works on its own 'acquired' copy of the shared segment, everything is a constant and the JIT can see through the code and optimize it in the same way as it does for confined access. That said, we never fully committed to that solution, since the resulting API was very complex: for things to work, part of the MemorySegment API has to be moved under a new abstraction (in the document called MemoryHandle) - more specifically the bits that are responsible for creating addresses. While it's possible to devise a confined segment that is both a MemorySegment and a MemoryHandle (thus giving us back the old API), the general feedback I've received is that this solution seems a bit too convoluted.
>>>>
>>>> When discussing about this problem with Jim, he pointed out a useful connection and a possible way out: after all, all these acquire/release and reference counting schemes are there to perform a job that a JVM knows exactly how to do at speed: determining whether an object is still used or not. So, instead of inventing new machinery, we could simply piggy back on the mechanisms we already have - that is GC and Cleaners.
>>>>
>>>> The key realization, in the shared case, can be summarized as: performance, safety, deterministic deallocation, pick two! Since we're not willing to compromise on safety, or on performance, letting go of the deterministic de-allocation goal (only for shared segments) seems a reasonable conclusion.
>>>>
>>>> In other words, there are now two kinds of segments: /confined/ segment and /shared/ segments. A segment always starts off as confined, and has an owning thread. You can update the owning thread - effectively nuking the existing segment and obtaining a new segment that is confined on a new thread. This allows clients to achieve serialized thread-confinement use cases - where multiple threads operate on a piece of memory one at a time. Confined segments are operated upon as usual: you allocate a segment, you use it, you close it (or you use a try with resources to do it all automagically).
>>>>
>>>> If clients want more - e.g. full concurrent access, an API point is provided to turn a confined segment into a shared one. Again, what happens here is that the existing segment will be nuked, and a new shared segment will be created. But, this shared segment _cannot be closed_ (e.g. it is pinned, using the existing API terminology). So, how are off-heap resources released if we can't close the segment? Well, we let the GC take care of it - by registering the segment on a Cleaner, and have the cleaner call some cleanup code once the segment is no longer referenced (in reality, things are a bit different, in the sense that what we really  key on is the _scope_ of a segment, which might be shared across multiple views, but the essence is the same). In other words, deallocation for shared segments works pretty much the same way deallocation of direct buffer work.
>>>>
>>>> With this move, we are able to retain the simplicity of the existing API, while also being able to support efficient and safe concurrent access.
>>>>
>>>> A webrev implementing this change is available here:
>>>>
>>>> http://cr.openjdk.java.net/~mcimadamore/panama/shared-segments_v2/
>>>>
>>>> Implementation-wise things are, I think, quite straightforward. I took sometime to refactor the code, to make the various scope subclasses disappear. We now have a single memory segment implementation and two scopes: shared and confined. The confined scope takes a 'Runnable' cleanup action which is used (i) when closing the confined segment or (ii) passed onto the Cleaner by the shared scope if the segment is upgraded to 'shared' state. Also, since shared segment now can now be picked up by Cleaner when no longer referenced, it is crucial that we add in reachability fences around Unsafe operations (same way as direct buffer does really). This is because sometimes the GC can aggressively collect unused objects stored in local variables during method execution. Adding these fences doesn't negatively impact performances (in fact, I'm told these fences are a no-op in Hotspot).
>>>>
>>>> I also took some effort to update some of the javadoc which are rendered invalid by this change.
>>>>
>>>> Comments welcome
>>>>
>>>> Maurizio
>>>>
>>>> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/confinement.html
>>>>


From jorn.vernee at oracle.com  Fri Sep 27 11:59:44 2019
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Fri, 27 Sep 2019 13:59:44 +0200
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <d8b1ff16-1332-bb76-d7e1-45e23063fd28@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
 <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
 <ce7db07b-0104-4e18-ed5e-bfea5421ca7d@oracle.com>
 <d8b1ff16-1332-bb76-d7e1-45e23063fd28@oracle.com>
Message-ID: <60b2905f-6dd5-ebff-0c1d-178819a39a2a@oracle.com>

On 27/09/2019 13:54, Maurizio Cimadamore wrote:
>
> On 27/09/2019 11:46, Jorn Vernee wrote:
>> Reading through the code, there is one caveat that doesn't seem to be 
>> addressed yet; only the owning thread can call asShared() or 
>> asConfined() (not being checked currently), and, at least for 
>> asConfined(), I think the owning thread has to submit to a full fence 
>> before transferring the segment to make sure no accesses 'spill over' 
>> into the new state. 
>
> Right, I should add the checks.
>
> Not sure about the fence - I thought about that. We are creating a 
> _new_ object, and invalidating an old one. Only the old thread has 
> access to the old one, so it cannot possibly perform access on the old 
> segment AFTER it is closed. And, the new thread cannot access the 
> segment before the old thread is actually inside the transfer code 
> (which means he's done with the segment already).
>
> If we were modifying the ownership in place, I'd agree a fence would 
> be in order - but here?

To sketch the scenario I'm thinking of: Let's say ownership is 
transferred from thread A to thread B.

* A writes to the memory segment, but this ends up in the core's cache, 
due to no memory fencing.
* A transfers ownership to B
* B closes the segment, freeing the memory
* The cache of thread A is flushed to memory (BOOM)

Jorn

> Maurizio
>

From maurizio.cimadamore at oracle.com  Fri Sep 27 12:12:27 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 27 Sep 2019 13:12:27 +0100
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <d8b1ff16-1332-bb76-d7e1-45e23063fd28@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
 <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
 <ce7db07b-0104-4e18-ed5e-bfea5421ca7d@oracle.com>
 <d8b1ff16-1332-bb76-d7e1-45e23063fd28@oracle.com>
Message-ID: <116543a7-f64f-648d-1ea9-0a81d1e329e7@oracle.com>


On 27/09/2019 12:54, Maurizio Cimadamore wrote:
>
> On 27/09/2019 11:46, Jorn Vernee wrote:
>> Reading through the code, there is one caveat that doesn't seem to be 
>> addressed yet; only the owning thread can call asShared() or 
>> asConfined() (not being checked currently), and, at least for 
>> asConfined(), I think the owning thread has to submit to a full fence 
>> before transferring the segment to make sure no accesses 'spill over' 
>> into the new state. 
>
> Right, I should add the checks.
>
> Not sure about the fence - I thought about that. We are creating a 
> _new_ object, and invalidating an old one. Only the old thread has 
> access to the old one, so it cannot possibly perform access on the old 
> segment AFTER it is closed. And, the new thread cannot access the 
> segment before the old thread is actually inside the transfer code 
> (which means he's done with the segment already).
>
> If we were modifying the ownership in place, I'd agree a fence would 
> be in order - but here?

Yep - safe publication rules seem to cover it, see here

https://shipilev.net/blog/2014/safe-public-construction/

Since the Thread owner is a final field in the segment, the publication 
should be safe here...

Maurizio

>
> Maurizio
>

From maurizio.cimadamore at oracle.com  Fri Sep 27 12:36:07 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 27 Sep 2019 13:36:07 +0100
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <116543a7-f64f-648d-1ea9-0a81d1e329e7@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
 <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
 <ce7db07b-0104-4e18-ed5e-bfea5421ca7d@oracle.com>
 <d8b1ff16-1332-bb76-d7e1-45e23063fd28@oracle.com>
 <116543a7-f64f-648d-1ea9-0a81d1e329e7@oracle.com>
Message-ID: <21bf53b6-dd86-ef6e-7b0b-6a8ab0b2ea1c@oracle.com>

Ok, I've been looking at some HS code:

http://hg.openjdk.java.net/jdk/jdk/file/d10b732966ba/src/hotspot/share/opto/parse1.cpp#l1004

Seems like there's only a release fence there. So, yes, in principle 
reads from thread A might be reordered after B accesses memory.

Maurizio

On 27/09/2019 13:12, Maurizio Cimadamore wrote:
>
> On 27/09/2019 12:54, Maurizio Cimadamore wrote:
>>
>> On 27/09/2019 11:46, Jorn Vernee wrote:
>>> Reading through the code, there is one caveat that doesn't seem to 
>>> be addressed yet; only the owning thread can call asShared() or 
>>> asConfined() (not being checked currently), and, at least for 
>>> asConfined(), I think the owning thread has to submit to a full 
>>> fence before transferring the segment to make sure no accesses 
>>> 'spill over' into the new state. 
>>
>> Right, I should add the checks.
>>
>> Not sure about the fence - I thought about that. We are creating a 
>> _new_ object, and invalidating an old one. Only the old thread has 
>> access to the old one, so it cannot possibly perform access on the 
>> old segment AFTER it is closed. And, the new thread cannot access the 
>> segment before the old thread is actually inside the transfer code 
>> (which means he's done with the segment already).
>>
>> If we were modifying the ownership in place, I'd agree a fence would 
>> be in order - but here?
>
> Yep - safe publication rules seem to cover it, see here
>
> https://shipilev.net/blog/2014/safe-public-construction/
>
> Since the Thread owner is a final field in the segment, the 
> publication should be safe here...
>
> Maurizio
>
>>
>> Maurizio
>>

From maurizio.cimadamore at oracle.com  Fri Sep 27 12:45:36 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 27 Sep 2019 13:45:36 +0100
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <ce7db07b-0104-4e18-ed5e-bfea5421ca7d@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
 <163b1037-72e3-c223-0319-8464cd90604c@oracle.com>
 <c131cf79-99f2-8e25-b111-1fae6f3f72cf@oracle.com>
 <ce7db07b-0104-4e18-ed5e-bfea5421ca7d@oracle.com>
Message-ID: <6ef955a1-c535-a5bc-9ff1-a1b39b4844a4@oracle.com>


On 27/09/2019 11:46, Jorn Vernee wrote:
> 2) seems fine to me. We can phrase the doc to be vague about whether a 
> newly created segment will be returned, and just say we will return 'a 
> segment with properties XYZ', then returning the same segment in some 
> cases will just be an implementation detail.

I think the problem here is slightly different... yes, we can make the 
doc vague about the identity of the returned object - but we have to 
describe the side-effect of invalidating existing segment (because that 
effect will be visible to clients!). And that side-effect only happens 
if a 'new' segment is returned.

So, compared to (2), (3) applies the invalidation logic always.

Maurizio


From maurizio.cimadamore at oracle.com  Fri Sep 27 13:48:53 2019
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 27 Sep 2019 14:48:53 +0100
Subject: [foreign-memaccess] on shared segments
In-Reply-To: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
References: <478b5e34-64df-b9b2-32f0-a08775860a65@oracle.com>
Message-ID: <0df8d401-48ce-a212-3b0c-5f36ca90590e@oracle.com>

Uploaded new revision:

http://cr.openjdk.java.net/~mcimadamore/panama/shared-segments_v3/

Changes:

* Added full fences on asShared, asConfined
* Added new predicate for testing confinement
* restructured the calls to checkValidState - now basic accessors and 
predicates like byteSize, baseAddress, isPinned etc. do NOT check for 
confinement
* changed the javadoc of asConfined/asShared to reflect the option (2) - 
see below


 ?/**
 ???? * Obtains a confined copy of this memory segment whose owner 
thread is set to the given thread. If the new owner thread
 ???? * differs from the current owner thread, as a side-effect, this 
segment will be marked as <em>not alive</em>,
 ???? * and subsequent operations on this segment will result in runtime 
errors.
 ???? * @param newOwner the new owner thread.
 ???? * @return a confined copy of this segment with given owner thread.
 ???? * @throws UnsupportedOperationException if the segment is a shared 
segment (see {@link MemorySegment#isShared()}).
 ???? */
 ??? MemorySegment asConfined(Thread newOwner) throws 
UnsupportedOperationException;

 ??? /**
 ???? * Obtains a shared copy of this memory segment which can be 
accessed across multiple threads. If the current segment
 ???? * is not already shared (see {@link MemorySegment#isShared()}), as 
a side-effect, this segment will be marked as
 ???? * <em>not alive</em>, and subsequent operations on this segment 
will result in runtime errors.
 ???? * The shared copy will also be marked as <em>pinned</em> (see 
{@link MemorySegment#isPinned()});
 ???? * as such, any attempt to close the returned segment will result 
in a runtime error.
 ???? * @return a shared copy of this segment.
 ???? */
 ??? MemorySegment asShared();


I think we can't do much better if we go with (2) - that is we _have_ to 
say when the invalidating side-effect takes place. I'm still not 100% 
that (2) is the way to go; IMHO (2) supports a fiction that 'asConfined' 
can be used to assert confinement, rather than to proactively change it. 
I think clients should use it sparingly, especially now that we have 
full testing capabilities.

Maurizio

On 26/09/2019 19:10, Maurizio Cimadamore wrote:
> Hi,
> in a previous document [1] I explored the problem of allowing 
> concurrent access to a memory segment in a safe fashion. From that 
> exploration, it emerged that there was one type of race that was 
> particularly nasty: that is, a race between a thread A attempting to 
> close a segment S while a thread B is attempting to access (read or 
> write) S.
>
> The presence of this race makes it really hard to generalize the 
> existing memory access API to cases where concurrent/shared access is 
> needed. Of course one naive solution would be to synchronize every 
> access on the liveness check, but that makes performance really poor - 
> which would defeat the point of having such an API in the first place.
>
> Instead, to solve that problem, in the document I posit about a 
> solution which uses an explicit acquire/release mechanism - that is 
> clients of a shared segment will need to explicitly acquire the 
> segment in order to be able to operate on it, and release it when 
> done. A shared segment can only be closed when all clients are done 
> with the segment - this is what ensures temporal safety. Moreover, 
> since each client works on its own 'acquired' copy of the shared 
> segment, everything is a constant and the JIT can see through the code 
> and optimize it in the same way as it does for confined access. That 
> said, we never fully committed to that solution, since the resulting 
> API was very complex: for things to work, part of the MemorySegment 
> API has to be moved under a new abstraction (in the document called 
> MemoryHandle) - more specifically the bits that are responsible for 
> creating addresses. While it's possible to devise a confined segment 
> that is both a MemorySegment and a MemoryHandle (thus giving us back 
> the old API), the general feedback I've received is that this solution 
> seems a bit too convoluted.
>
> When discussing about this problem with Jim, he pointed out a useful 
> connection and a possible way out: after all, all these 
> acquire/release and reference counting schemes are there to perform a 
> job that a JVM knows exactly how to do at speed: determining whether 
> an object is still used or not. So, instead of inventing new 
> machinery, we could simply piggy back on the mechanisms we already 
> have - that is GC and Cleaners.
>
> The key realization, in the shared case, can be summarized as: 
> performance, safety, deterministic deallocation, pick two! Since we're 
> not willing to compromise on safety, or on performance, letting go of 
> the deterministic de-allocation goal (only for shared segments) seems 
> a reasonable conclusion.
>
> In other words, there are now two kinds of segments: /confined/ 
> segment and /shared/ segments. A segment always starts off as 
> confined, and has an owning thread. You can update the owning thread - 
> effectively nuking the existing segment and obtaining a new segment 
> that is confined on a new thread. This allows clients to achieve 
> serialized thread-confinement use cases - where multiple threads 
> operate on a piece of memory one at a time. Confined segments are 
> operated upon as usual: you allocate a segment, you use it, you close 
> it (or you use a try with resources to do it all automagically).
>
> If clients want more - e.g. full concurrent access, an API point is 
> provided to turn a confined segment into a shared one. Again, what 
> happens here is that the existing segment will be nuked, and a new 
> shared segment will be created. But, this shared segment _cannot be 
> closed_ (e.g. it is pinned, using the existing API terminology). So, 
> how are off-heap resources released if we can't close the segment? 
> Well, we let the GC take care of it - by registering the segment on a 
> Cleaner, and have the cleaner call some cleanup code once the segment 
> is no longer referenced (in reality, things are a bit different, in 
> the sense that what we really? key on is the _scope_ of a segment, 
> which might be shared across multiple views, but the essence is the 
> same). In other words, deallocation for shared segments works pretty 
> much the same way deallocation of direct buffer work.
>
> With this move, we are able to retain the simplicity of the existing 
> API, while also being able to support efficient and safe concurrent 
> access.
>
> A webrev implementing this change is available here:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/shared-segments_v2/
>
> Implementation-wise things are, I think, quite straightforward. I took 
> sometime to refactor the code, to make the various scope subclasses 
> disappear. We now have a single memory segment implementation and two 
> scopes: shared and confined. The confined scope takes a 'Runnable' 
> cleanup action which is used (i) when closing the confined segment or 
> (ii) passed onto the Cleaner by the shared scope if the segment is 
> upgraded to 'shared' state. Also, since shared segment now can now be 
> picked up by Cleaner when no longer referenced, it is crucial that we 
> add in reachability fences around Unsafe operations (same way as 
> direct buffer does really). This is because sometimes the GC can 
> aggressively collect unused objects stored in local variables during 
> method execution. Adding these fences doesn't negatively impact 
> performances (in fact, I'm told these fences are a no-op in Hotspot).
>
> I also took some effort to update some of the javadoc which are 
> rendered invalid by this change.
>
> Comments welcome
>
> Maurizio
>
> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/confinement.html
>

From kishor.kharbas at intel.com  Fri Sep 27 19:31:07 2019
From: kishor.kharbas at intel.com (Kharbas, Kishor)
Date: Fri, 27 Sep 2019 19:31:07 +0000
Subject: [vector]: Review of changes for CSR comments
Message-ID: <F89640DCD01A85489FCBA68183A6A0F3CB568CA0@ORSMSX116.amr.corp.intel.com>

Hi all,
Please review the webrev which address some of the comments in CSR review of vector api (https://bugs.openjdk.java.net/browse/JDK-8223348).

Link: http://cr.openjdk.java.net/~kkharbas/8223348/webrev.00/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template.sdiff.html

Thanks,
Kishor

From Yang.Zhang at arm.com  Sun Sep 29 06:29:42 2019
From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China))
Date: Sun, 29 Sep 2019 06:29:42 +0000
Subject: [vector] Implement VectorShuffle rearrange and iota for AArch64 NEON
Message-ID: <VE1PR08MB4656C17E7D3366DA0AF5F8E78E830@VE1PR08MB4656.eurprd08.prod.outlook.com>

Hi all

Could anyone please help to review this patch?

Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.shuffle/webrev.00/

In this patch, VectorLoadConst, VectorLoadShuffle and VectorRearrange rules are supported.
Here is an example that rearranges a NEON vector with 4 ints:
Rearrange V1 int[a0, a1, a2, a3] to V2 int[a2, a3, a0, a1]
   1. Get the indices of V1 and store them as Vi byte[0, 1, 2, 3].
   2. Convert Vi byte[0, 1, 2, 3] to the indices of V2 and also store them as Vi byte[2, 3, 0, 1].
   3. Unsigned extend Long Vi from byte[2, 3, 0, 1] to int[2, 3, 0, 1].
   4. Multiply Vi int[2, 3, 0, 1] with constant int[0x04040404, 0x04040404, 0x04040404, 0x04040404]
      and get tbl base Vm int[0x08080808, 0x0c0c0c0c, 0x00000000, 0x04040404].
   5. Add Vm with constant int[0x03020100, 0x03020100, 0x03020100, 0x03020100]
      and get tbl index Vm int[0x0b0a0908, 0x0f0e0d0c, 0x03020100, 0x07060504]
   6. Use Vm as index register, and use V1 as table register.
      Then get V2 as the result by tbl NEON instructions.
 Notes:
   Step 1 matches VectorLoadConst.
   Step 3 matches VectorLoadShuffle.
   Step 4, 5, 6 match VectorRearrange.
   For VectorRearrange short/int, the reason why such complex calculation is
   required is because NEON tbl supports bytes table only, so for short/int, we
   need to lookup 2/4 bytes as a group. For VectorRearrange long, we use bsl
   to implement rearrange.

Regards,
Yang

From kishor.kharbas at intel.com  Mon Sep 30 17:34:11 2019
From: kishor.kharbas at intel.com (Kharbas, Kishor)
Date: Mon, 30 Sep 2019 17:34:11 +0000
Subject: [vector] Add test case for vector shuffle operations with C2
In-Reply-To: <VE1PR08MB4656186C6B629EB7F3E58EC38E860@VE1PR08MB4656.eurprd08.prod.outlook.com>
References: <VE1PR08MB4656186C6B629EB7F3E58EC38E860@VE1PR08MB4656.eurprd08.prod.outlook.com>
Message-ID: <F89640DCD01A85489FCBA68183A6A0F3CB5690B3@ORSMSX116.amr.corp.intel.com>

Hi Yang,
The webrev looks good to me.

Regards,
-Kishor

> -----Original Message-----
> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On
> Behalf Of Yang Zhang (Arm Technology China)
> Sent: Thursday, September 26, 2019 1:21 AM
> To: panama-dev at openjdk.java.net
> Cc: nd <nd at arm.com>
> Subject: [vector] Add test case for vector shuffle operations with C2
> 
> Hi all
> 
> Could anyone please help to review this patch?
> 
> Webrev:
> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.shuffletest/webrev
> .00/
> 
> When I add VectorLoadShuffle and VectorRearrange backend support for
> AArch64 platform, I find that these instructions are not tested fully. In this
> patch, I add iotaShuffle test case which can test VectorLoadShuffle
> instruction separately.
> 
> Regards,
> Yang
> 
> 
> 
> 
> 
> Regards
> Yang