From david.holmes at oracle.com  Mon Jul  2 00:24:43 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 2 Jul 2018 10:24:43 +1000
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
Message-ID: <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>

Hi Swati,

I took a look at this though I'm not familiar with the functional 
operation of the NUMA API's - I'm relying on Gustavo and Derek to spot 
any actual usage errors there.

In isbound_to_single_node() there is no NULL check for 
_numa_bitmask_isbitset (which seems to be the normal pattern for using 
all of these function pointers).

Otherwise this seems fine.

Thanks,
David

On 30/06/2018 2:46 AM, Swati Sharma wrote:
>   Hi,
> 
> Could I get a review for this change that affects the JVM when there are
> pinned memory nodes please?
> 
> It's already reviewed and tested on PPC64 and on AARCH64 by Gustavo and
> Derek, however both are not Reviewers so I need additional reviews for that
> change.
> 
> 
> Thanks in advance.
> 
> Swati
> 
> On Tue, Jun 19, 2018 at 5:58 PM, Swati Sharma <swatibits14 at gmail.com> wrote:
> 
>> Hi All,
>>
>> Here is the numa information of the system :
>> swati at java-diesel1:~$ numactl -H
>> available: 8 nodes (0-7)
>> node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
>> node 0 size: 64386 MB
>> node 0 free: 64134 MB
>> node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
>> node 1 size: 64509 MB
>> node 1 free: 64232 MB
>> node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
>> node 2 size: 64509 MB
>> node 2 free: 64215 MB
>> node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
>> node 3 size: 64509 MB
>> node 3 free: 64157 MB
>> node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 102 103
>> node 4 size: 64509 MB
>> node 4 free: 64336 MB
>> node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109 110 111
>> node 5 size: 64509 MB
>> node 5 free: 64352 MB
>> node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117 118 119
>> node 6 size: 64509 MB
>> node 6 free: 64359 MB
>> node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125 126 127
>> node 7 size: 64508 MB
>> node 7 free: 64350 MB
>> node distances:
>> node   0   1   2   3   4   5   6   7
>>    0:  10  16  16  16  32  32  32  32
>>    1:  16  10  16  16  32  32  32  32
>>    2:  16  16  10  16  32  32  32  32
>>    3:  16  16  16  10  32  32  32  32
>>    4:  32  32  32  32  10  16  16  16
>>    5:  32  32  32  32  16  10  16  16
>>    6:  32  32  32  32  16  16  10  16
>>    7:  32  32  32  32  16  16  16  10
>>
>> Thanks,
>> Swati
>>
>> On Tue, Jun 19, 2018 at 12:00 AM, Gustavo Romero <
>> gromero at linux.vnet.ibm.com> wrote:
>>
>>> Hi Swati,
>>>
>>> On 06/16/2018 02:52 PM, Swati Sharma wrote:
>>>
>>>> Hi All,
>>>>
>>>> This is my first patch,I would appreciate if anyone can review the fix:
>>>>
>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8189922 <
>>>> https://bugs.openjdk.java.net/browse/JDK-8189922>
>>>> Webrev :http://cr.openjdk.java.net/~gromero/8189922/v1
>>>>
>>>> The bug is about JVM flag UseNUMA which bypasses the user specified
>>>> numactl --membind option and divides the whole heap in lgrps according to
>>>> available numa nodes.
>>>>
>>>> The proposed solution is to disable UseNUMA if bound to single numa
>>>> node. In case more than one numa node binding, create the lgrps according
>>>> to bound nodes.If there is no binding, then JVM will divide the whole heap
>>>> based on the number of NUMA nodes available on the system.
>>>>
>>>> I appreciate Gustavo's help for fixing the thread allocation based on
>>>> numa distance for membind which was a dangling issue associated with main
>>>> patch.
>>>>
>>>
>>> Thanks. I have no further comments on it. LGTM.
>>>
>>>
>>> Best regards,
>>> Gustavo
>>>
>>> PS: Please, provide numactl -H information when possible. It helps to
>>> grasp
>>> promptly the actual NUMA topology in question :)
>>>
>>> Tested the fix by running specjbb2015 composite workload on 8 NUMA node
>>>> system.
>>>> Case 1 : Single NUMA node bind
>>>> numactl --cpunodebind=0 --membind=0 java -Xmx24g -Xms24g -Xmn22g
>>>> -XX:+UseNUMA -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>>>> <composite_application>
>>>> Before Patch: gc.log
>>>> eden space 22511616K(22GB), 12% used
>>>>       lgrp 0 space 2813952K, 100% used
>>>>       lgrp 1 space 2813952K, 0% used
>>>>       lgrp 2 space 2813952K, 0% used
>>>>       lgrp 3 space 2813952K, 0% used
>>>>       lgrp 4 space 2813952K, 0% used
>>>>       lgrp 5 space 2813952K, 0% used
>>>>       lgrp 6 space 2813952K, 0% used
>>>>       lgrp 7 space 2813952K, 0% used
>>>> After Patch : gc.log
>>>> eden space 46718976K(45GB), 99% used(NUMA disabled)
>>>>
>>>> Case 2 : Multiple NUMA node bind
>>>> numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g -Xmx50g -Xmn45g
>>>> -XX:+UseNUMA -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>>>> <composite_application>
>>>> Before Patch :gc.log
>>>> eden space 46718976K, 6% used
>>>>       lgrp 0 space 5838848K, 14% used
>>>>       lgrp 1 space 5838848K, 0% used
>>>>       lgrp 2 space 5838848K, 0% used
>>>>       lgrp 3 space 5838848K, 0% used
>>>>       lgrp 4 space 5838848K, 0% used
>>>>       lgrp 5 space 5838848K, 0% used
>>>>       lgrp 6 space 5838848K, 0% used
>>>>       lgrp 7 space 5847040K, 35% used
>>>> After Patch : gc.log
>>>> eden space 46718976K(45GB), 99% used
>>>>        lgrp 0 space 23359488K(23.5GB), 100% used
>>>>        lgrp 7 space 23359488K(23.5GB), 99% used
>>>>
>>>>
>>>> Note: The proposed solution is only for numactl membind option.The fix
>>>> is not for --cpunodebind and localalloc which is a separate bug bug
>>>> https://bugs.openjdk.java.net/browse/JDK-8205051 and fix is in progress
>>>> on this.
>>>>
>>>> Thanks,
>>>> Swati Sharma
>>>> Software Engineer -2 at AMD
>>>>
>>>>
>>>
>>

From rkennke at redhat.com  Mon Jul  2 11:56:37 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 2 Jul 2018 13:56:37 +0200
Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter
In-Reply-To: <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com>
References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com>
 <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com>
 <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com>
 <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com>
 <A08320C0-A1AF-4EF8-8B2E-05AA4373EE57@redhat.com>
 <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com>
 <a1416699-78f6-b450-50c3-5d4ac2642a1d@oracle.com>
 <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com>
Message-ID: <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com>


>> I am a fan of profile guided optimization. I would definitely not mind 
>> introducing these concepts in the compilers where they are with no doubt 
>> necessary (and we also have the right tools for dealing with this 
>> better). In fact, they already have read/write decorators that could be 
>> used for resolve barriers in our compilers, and can use algorithms to 
>> safely elide barriers where provably correct, so it makes perfect sense 
>> for me to use such concepts there.
>> I'm just not sure that the interpreter needs to be polluted with this 
>> conceptual overhead, unless there is at least one benchmark that can 
>> show that we are solving an actual problem with this. Remember, 
>> premature optimizations are the root of all evil.
> 
> but efficient systems are made from thousands of tiny optimizations, each
> one too small to be measured above the noise on its own.
> 

After some offline discussion with Erik, I want to propose a solution
that 1. keeps the API simple to use, even if not sure if it's a read- or
write-access (defaulting to stronger write, 2. remains flexible enough
to optimize for read-only acces.

This changeset introduces an API BarrierSetAssembler::resolve() which
takes the 'hint' about read- vs write-access via a Decorator ACCESS_READ
and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets
ACCESS_WRITE if ACCESS_READ is not explicitely set.

Incremental webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/
Full webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/

If this proposal gets accepted, I'd take this further (in separate RFEs):
1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS
and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they
are currently passed into Access API that 'knows' what it is, e.g.
store_at/load_at, etc).
2. introduce same pattern for resolve() in runtime (and later, c1 and c2).

What do you think?

Roman


From volker.simonis at gmail.com  Mon Jul  2 17:27:22 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 2 Jul 2018 19:27:22 +0200
Subject: [11] RFR(XS): MallocSiteTable::initialize() doesn't take function
 descriptors into account
Message-ID: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>

Hi,

can I please have a review for this trivial change which fixes a
problem on Linux/ppc64

http://cr.openjdk.java.net/~simonis/webrevs/2018/8206173/
https://bugs.openjdk.java.net/browse/JDK-8206173

MallocSiteTable::initialize() creates a pseudo call stack for
hashtable entry allocations which is populated with the addresses of
some well-known static methods.

However, taking the address of a function or static method in C/C++
isn't required to return the actual code address where that function
lives in memory. On ppc64 (i.e. big-endian, ABI ELFv1) applying the
address operator on a function will return the functions "function
descriptor" (see
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES)
which is a struct of three pointers where the first one points to the
actual function address.

In order to get a correct stack trace on ppc64 as well, we therefore
have to dereference the function descriptor before we can store the
real function address in the stack trace.

In order to make the shared code fix less intrusive, I've added a pair
of LITTLE_ENDIAN_ONLY/BIG_ENDIAN_ONLY macros to macros.hpp.

This bug is the reason why runtime/ElfDecoder/TestElfDirectRead.java
fails on Linux/ppc64.

Thank you and best regards,
Volker

From paul.sandoz at oracle.com  Mon Jul  2 17:39:10 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 2 Jul 2018 10:39:10 -0700
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
Message-ID: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>

Hi,

Please review this fix for 11:

  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-tag/webrev/

This is a regression introduced by constant dynamic that causes a JCK test to fail when using "-Xcomp -XX:-TieredCompilation?.

The problem is due to a lossy mapping between a constant tag and basic type.

A constant tag of say JVM_CONSTANT_Class is mapped to a basic type of T_OBJECT. T_OBJECT is mapped to a constant tag of JVM_CONSTANT_String. So the round trip is lossy, and this for some reasons results in the JVMTI test failure under certain conditions. This also includes mapping JVM_CONSTANT_UnresolvedClass to T_OBJECT, which might be the source of the problem. 

I verified all the JCK JVMTI tests pass with "-Xcomp -XX:-TieredCompilation?.

I am not familiar with the interactions between JVMTI,  -Xcomp, and C2. So i don?t fully understand why the failure occurred under certain conditions and not others.

Thanks,
Paul.

From vladimir.kozlov at oracle.com  Mon Jul  2 18:43:07 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 2 Jul 2018 11:43:07 -0700
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
In-Reply-To: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
References: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
Message-ID: <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>

On 7/2/18 10:39 AM, Paul Sandoz wrote:
> Hi,
> 
> Please review this fix for 11:
> 
>    http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-tag/webrev/

Seems good to me. I will run testing with it.

> 
> This is a regression introduced by constant dynamic that causes a JCK test to fail when using "-Xcomp -XX:-TieredCompilation?.
> 
> The problem is due to a lossy mapping between a constant tag and basic type.
> 
> A constant tag of say JVM_CONSTANT_Class is mapped to a basic type of T_OBJECT. T_OBJECT is mapped to a constant tag of JVM_CONSTANT_String. So the round trip is lossy, and this for some reasons results in the JVMTI test failure under certain conditions. This also includes mapping JVM_CONSTANT_UnresolvedClass to T_OBJECT, which might be the source of the problem.
> 
> I verified all the JCK JVMTI tests pass with "-Xcomp -XX:-TieredCompilation?.

Thank you.

> 
> I am not familiar with the interactions between JVMTI,  -Xcomp, and C2. So i don?t fully understand why the failure occurred under certain conditions and not others.

-Xcomp -XX:-TieredCompilation combination means is compiled all called 
methods and only C2 JIT is used.

I think we may not running JCK testing with this combination of flags. 
The problem was reported by Goetz from SAP.

Thanks,
Vladimir

> 
> Thanks,
> Paul.
> 

From igor.ignatyev at oracle.com  Mon Jul  2 22:54:25 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 2 Jul 2018 15:54:25 -0700
Subject: RFR(S/M) : 8202561 : clean up TEST.groups file
In-Reply-To: <5cf5b46a-1ae7-3286-1a5f-9f2141312401@oracle.com>
References: <19F6C0D7-EA7D-456D-BB3E-68EE786C3125@oracle.com>
 <5cf5b46a-1ae7-3286-1a5f-9f2141312401@oracle.com>
Message-ID: <18365AA7-3384-477B-8126-5C97175042A3@oracle.com>

Katya,

thank you for review!

can I get a second Review?

Cheers,
-- Igor

> On Jun 28, 2018, at 1:43 PM, Ekaterina Pavlova <ekaterina.pavlova at oracle.com> wrote:
> 
> Looks good,
> 
> 
> thanks,
> -katya
> 
> On 6/28/18 11:09 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8202561/webrev.00/index.html
>>> 2262 lines changed: 2 ins; 2258 del; 2 mod
>> Hi all,
>> could you please review the clean up for hotspot TEST.groups file?
>> the patch moves all vmTestbase_*_quick groups to a separate file TEST.quick-groups.
>> webrev: http://cr.openjdk.java.net/~iignatyev//8202561/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202561
>> Thanks,
>> -- Igor
> 


From vladimir.kozlov at oracle.com  Mon Jul  2 23:09:07 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 2 Jul 2018 16:09:07 -0700
Subject: RFR(S/M) : 8202561 : clean up TEST.groups file
In-Reply-To: <19F6C0D7-EA7D-456D-BB3E-68EE786C3125@oracle.com>
References: <19F6C0D7-EA7D-456D-BB3E-68EE786C3125@oracle.com>
Message-ID: <69c8a863-dedd-1c61-d739-d944bc9cc786@oracle.com>

Thank you for doing this. Looks fine. One question is why you cloned 
TEST.groups instead of creating new file? Diffs look confusing.

Vladimir

On 6/28/18 11:09 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8202561/webrev.00/index.html
>> 2262 lines changed: 2 ins; 2258 del; 2 mod
> 
> Hi all,
> 
> could you please review the clean up for hotspot TEST.groups file?
> 
> the patch moves all vmTestbase_*_quick groups to a separate file TEST.quick-groups.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8202561/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8202561
> 
> Thanks,
> -- Igor
> 

From zgu at redhat.com  Mon Jul  2 23:09:14 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 2 Jul 2018 19:09:14 -0400
Subject: [11] RFR(XS): MallocSiteTable::initialize() doesn't take function
 descriptors into account
In-Reply-To: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>
References: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>
Message-ID: <bf795eaf-a9ab-61b3-9893-490e9d3bb3c2@redhat.com>

Hi Volker,

fp[0] should work with little endian as well, right?

I wonder if change

pc[2] = (address)MallocSiteTable::allocation_at;

to

pc[2] = (address)(&MallocSiteTable::allocation_at);

will work.

Thanks,

-Zhengyu

On 07/02/2018 01:27 PM, Volker Simonis wrote:
> Hi,
> 
> can I please have a review for this trivial change which fixes a
> problem on Linux/ppc64
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206173/
> https://bugs.openjdk.java.net/browse/JDK-8206173
> 
> MallocSiteTable::initialize() creates a pseudo call stack for
> hashtable entry allocations which is populated with the addresses of
> some well-known static methods.
> 
> However, taking the address of a function or static method in C/C++
> isn't required to return the actual code address where that function
> lives in memory. On ppc64 (i.e. big-endian, ABI ELFv1) applying the
> address operator on a function will return the functions "function
> descriptor" (see
> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES)
> which is a struct of three pointers where the first one points to the
> actual function address.
> 
> In order to get a correct stack trace on ppc64 as well, we therefore
> have to dereference the function descriptor before we can store the
> real function address in the stack trace.
> 
> In order to make the shared code fix less intrusive, I've added a pair
> of LITTLE_ENDIAN_ONLY/BIG_ENDIAN_ONLY macros to macros.hpp.
> 
> This bug is the reason why runtime/ElfDecoder/TestElfDirectRead.java
> fails on Linux/ppc64.
> 
> Thank you and best regards,
> Volker
> 

From swatibits14 at gmail.com  Tue Jul  3 05:08:01 2018
From: swatibits14 at gmail.com (Swati Sharma)
Date: Tue, 3 Jul 2018 10:38:01 +0530
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
Message-ID: <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>

Hi David,

I have added NULL check for  _numa_bitmask_isbitset in
isbound_to_single_node()
method.

Hosted: http://cr.openjdk.java.net/~gromero/8189922/v2/

Swati

On Mon, Jul 2, 2018 at 5:54 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Swati,
>
> I took a look at this though I'm not familiar with the functional
> operation of the NUMA API's - I'm relying on Gustavo and Derek to spot any
> actual usage errors there.
>
> In isbound_to_single_node() there is no NULL check for
> _numa_bitmask_isbitset (which seems to be the normal pattern for using all
> of these function pointers).
>
> Otherwise this seems fine.
>
> Thanks,
> David
>
>
> On 30/06/2018 2:46 AM, Swati Sharma wrote:
>
>>   Hi,
>>
>> Could I get a review for this change that affects the JVM when there are
>> pinned memory nodes please?
>>
>> It's already reviewed and tested on PPC64 and on AARCH64 by Gustavo and
>> Derek, however both are not Reviewers so I need additional reviews for
>> that
>> change.
>>
>>
>> Thanks in advance.
>>
>> Swati
>>
>> On Tue, Jun 19, 2018 at 5:58 PM, Swati Sharma <swatibits14 at gmail.com>
>> wrote:
>>
>> Hi All,
>>>
>>> Here is the numa information of the system :
>>> swati at java-diesel1:~$ numactl -H
>>> available: 8 nodes (0-7)
>>> node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
>>> node 0 size: 64386 MB
>>> node 0 free: 64134 MB
>>> node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
>>> node 1 size: 64509 MB
>>> node 1 free: 64232 MB
>>> node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
>>> node 2 size: 64509 MB
>>> node 2 free: 64215 MB
>>> node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
>>> node 3 size: 64509 MB
>>> node 3 free: 64157 MB
>>> node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 102 103
>>> node 4 size: 64509 MB
>>> node 4 free: 64336 MB
>>> node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109 110 111
>>> node 5 size: 64509 MB
>>> node 5 free: 64352 MB
>>> node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117 118 119
>>> node 6 size: 64509 MB
>>> node 6 free: 64359 MB
>>> node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125 126 127
>>> node 7 size: 64508 MB
>>> node 7 free: 64350 MB
>>> node distances:
>>> node   0   1   2   3   4   5   6   7
>>>    0:  10  16  16  16  32  32  32  32
>>>    1:  16  10  16  16  32  32  32  32
>>>    2:  16  16  10  16  32  32  32  32
>>>    3:  16  16  16  10  32  32  32  32
>>>    4:  32  32  32  32  10  16  16  16
>>>    5:  32  32  32  32  16  10  16  16
>>>    6:  32  32  32  32  16  16  10  16
>>>    7:  32  32  32  32  16  16  16  10
>>>
>>> Thanks,
>>> Swati
>>>
>>> On Tue, Jun 19, 2018 at 12:00 AM, Gustavo Romero <
>>> gromero at linux.vnet.ibm.com> wrote:
>>>
>>> Hi Swati,
>>>>
>>>> On 06/16/2018 02:52 PM, Swati Sharma wrote:
>>>>
>>>> Hi All,
>>>>>
>>>>> This is my first patch,I would appreciate if anyone can review the fix:
>>>>>
>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8189922 <
>>>>> https://bugs.openjdk.java.net/browse/JDK-8189922>
>>>>> Webrev :http://cr.openjdk.java.net/~gromero/8189922/v1
>>>>>
>>>>> The bug is about JVM flag UseNUMA which bypasses the user specified
>>>>> numactl --membind option and divides the whole heap in lgrps according
>>>>> to
>>>>> available numa nodes.
>>>>>
>>>>> The proposed solution is to disable UseNUMA if bound to single numa
>>>>> node. In case more than one numa node binding, create the lgrps
>>>>> according
>>>>> to bound nodes.If there is no binding, then JVM will divide the whole
>>>>> heap
>>>>> based on the number of NUMA nodes available on the system.
>>>>>
>>>>> I appreciate Gustavo's help for fixing the thread allocation based on
>>>>> numa distance for membind which was a dangling issue associated with
>>>>> main
>>>>> patch.
>>>>>
>>>>>
>>>> Thanks. I have no further comments on it. LGTM.
>>>>
>>>>
>>>> Best regards,
>>>> Gustavo
>>>>
>>>> PS: Please, provide numactl -H information when possible. It helps to
>>>> grasp
>>>> promptly the actual NUMA topology in question :)
>>>>
>>>> Tested the fix by running specjbb2015 composite workload on 8 NUMA node
>>>>
>>>>> system.
>>>>> Case 1 : Single NUMA node bind
>>>>> numactl --cpunodebind=0 --membind=0 java -Xmx24g -Xms24g -Xmn22g
>>>>> -XX:+UseNUMA -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>>>>> <composite_application>
>>>>> Before Patch: gc.log
>>>>> eden space 22511616K(22GB), 12% used
>>>>>       lgrp 0 space 2813952K, 100% used
>>>>>       lgrp 1 space 2813952K, 0% used
>>>>>       lgrp 2 space 2813952K, 0% used
>>>>>       lgrp 3 space 2813952K, 0% used
>>>>>       lgrp 4 space 2813952K, 0% used
>>>>>       lgrp 5 space 2813952K, 0% used
>>>>>       lgrp 6 space 2813952K, 0% used
>>>>>       lgrp 7 space 2813952K, 0% used
>>>>> After Patch : gc.log
>>>>> eden space 46718976K(45GB), 99% used(NUMA disabled)
>>>>>
>>>>> Case 2 : Multiple NUMA node bind
>>>>> numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g -Xmx50g -Xmn45g
>>>>> -XX:+UseNUMA -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>>>>> <composite_application>
>>>>> Before Patch :gc.log
>>>>> eden space 46718976K, 6% used
>>>>>       lgrp 0 space 5838848K, 14% used
>>>>>       lgrp 1 space 5838848K, 0% used
>>>>>       lgrp 2 space 5838848K, 0% used
>>>>>       lgrp 3 space 5838848K, 0% used
>>>>>       lgrp 4 space 5838848K, 0% used
>>>>>       lgrp 5 space 5838848K, 0% used
>>>>>       lgrp 6 space 5838848K, 0% used
>>>>>       lgrp 7 space 5847040K, 35% used
>>>>> After Patch : gc.log
>>>>> eden space 46718976K(45GB), 99% used
>>>>>        lgrp 0 space 23359488K(23.5GB), 100% used
>>>>>        lgrp 7 space 23359488K(23.5GB), 99% used
>>>>>
>>>>>
>>>>> Note: The proposed solution is only for numactl membind option.The fix
>>>>> is not for --cpunodebind and localalloc which is a separate bug bug
>>>>> https://bugs.openjdk.java.net/browse/JDK-8205051 and fix is in
>>>>> progress
>>>>> on this.
>>>>>
>>>>> Thanks,
>>>>> Swati Sharma
>>>>> Software Engineer -2 at AMD
>>>>>
>>>>>
>>>>>
>>>>
>>>

From david.holmes at oracle.com  Tue Jul  3 06:06:13 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Jul 2018 16:06:13 +1000
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
Message-ID: <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>

Looks fine.

Thanks,
David

On 3/07/2018 3:08 PM, Swati Sharma wrote:
> Hi David,
> 
> I have added NULL check for _numa_bitmask_isbitset in 
> isbound_to_single_node() method.
> 
> Hosted:http://cr.openjdk.java.net/~gromero/8189922/v2/ 
> <http://cr.openjdk.java.net/~gromero/8189922/v2/>
> 
> Swati
> 
> On Mon, Jul 2, 2018 at 5:54 AM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Swati,
> 
>     I took a look at this though I'm not familiar with the functional
>     operation of the NUMA API's - I'm relying on Gustavo and Derek to
>     spot any actual usage errors there.
> 
>     In isbound_to_single_node() there is no NULL check for
>     _numa_bitmask_isbitset (which seems to be the normal pattern for
>     using all of these function pointers).
> 
>     Otherwise this seems fine.
> 
>     Thanks,
>     David
> 
> 
>     On 30/06/2018 2:46 AM, Swati Sharma wrote:
> 
>          ? Hi,
> 
>         Could I get a review for this change that affects the JVM when
>         there are
>         pinned memory nodes please?
> 
>         It's already reviewed and tested on PPC64 and on AARCH64 by
>         Gustavo and
>         Derek, however both are not Reviewers so I need additional
>         reviews for that
>         change.
> 
> 
>         Thanks in advance.
> 
>         Swati
> 
>         On Tue, Jun 19, 2018 at 5:58 PM, Swati Sharma
>         <swatibits14 at gmail.com <mailto:swatibits14 at gmail.com>> wrote:
> 
>             Hi All,
> 
>             Here is the numa information of the system :
>             swati at java-diesel1:~$ numactl -H
>             available: 8 nodes (0-7)
>             node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
>             node 0 size: 64386 MB
>             node 0 free: 64134 MB
>             node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
>             node 1 size: 64509 MB
>             node 1 free: 64232 MB
>             node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
>             node 2 size: 64509 MB
>             node 2 free: 64215 MB
>             node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
>             node 3 size: 64509 MB
>             node 3 free: 64157 MB
>             node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 102 103
>             node 4 size: 64509 MB
>             node 4 free: 64336 MB
>             node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109
>             110 111
>             node 5 size: 64509 MB
>             node 5 free: 64352 MB
>             node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117
>             118 119
>             node 6 size: 64509 MB
>             node 6 free: 64359 MB
>             node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125
>             126 127
>             node 7 size: 64508 MB
>             node 7 free: 64350 MB
>             node distances:
>             node? ?0? ?1? ?2? ?3? ?4? ?5? ?6? ?7
>              ? ?0:? 10? 16? 16? 16? 32? 32? 32? 32
>              ? ?1:? 16? 10? 16? 16? 32? 32? 32? 32
>              ? ?2:? 16? 16? 10? 16? 32? 32? 32? 32
>              ? ?3:? 16? 16? 16? 10? 32? 32? 32? 32
>              ? ?4:? 32? 32? 32? 32? 10? 16? 16? 16
>              ? ?5:? 32? 32? 32? 32? 16? 10? 16? 16
>              ? ?6:? 32? 32? 32? 32? 16? 16? 10? 16
>              ? ?7:? 32? 32? 32? 32? 16? 16? 16? 10
> 
>             Thanks,
>             Swati
> 
>             On Tue, Jun 19, 2018 at 12:00 AM, Gustavo Romero <
>             gromero at linux.vnet.ibm.com
>             <mailto:gromero at linux.vnet.ibm.com>> wrote:
> 
>                 Hi Swati,
> 
>                 On 06/16/2018 02:52 PM, Swati Sharma wrote:
> 
>                     Hi All,
> 
>                     This is my first patch,I would appreciate if anyone
>                     can review the fix:
> 
>                     Bug :
>                     https://bugs.openjdk.java.net/browse/JDK-8189922
>                     <https://bugs.openjdk.java.net/browse/JDK-8189922> <
>                     https://bugs.openjdk.java.net/browse/JDK-8189922
>                     <https://bugs.openjdk.java.net/browse/JDK-8189922>>
>                     Webrev
>                     :http://cr.openjdk.java.net/~gromero/8189922/v1
>                     <http://cr.openjdk.java.net/~gromero/8189922/v1>
> 
>                     The bug is about JVM flag UseNUMA which bypasses the
>                     user specified
>                     numactl --membind option and divides the whole heap
>                     in lgrps according to
>                     available numa nodes.
> 
>                     The proposed solution is to disable UseNUMA if bound
>                     to single numa
>                     node. In case more than one numa node binding,
>                     create the lgrps according
>                     to bound nodes.If there is no binding, then JVM will
>                     divide the whole heap
>                     based on the number of NUMA nodes available on the
>                     system.
> 
>                     I appreciate Gustavo's help for fixing the thread
>                     allocation based on
>                     numa distance for membind which was a dangling issue
>                     associated with main
>                     patch.
> 
> 
>                 Thanks. I have no further comments on it. LGTM.
> 
> 
>                 Best regards,
>                 Gustavo
> 
>                 PS: Please, provide numactl -H information when
>                 possible. It helps to
>                 grasp
>                 promptly the actual NUMA topology in question :)
> 
>                 Tested the fix by running specjbb2015 composite workload
>                 on 8 NUMA node
> 
>                     system.
>                     Case 1 : Single NUMA node bind
>                     numactl --cpunodebind=0 --membind=0 java -Xmx24g
>                     -Xms24g -Xmn22g
>                     -XX:+UseNUMA
>                     -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>                     <composite_application>
>                     Before Patch: gc.log
>                     eden space 22511616K(22GB), 12% used
>                      ? ? ? lgrp 0 space 2813952K, 100% used
>                      ? ? ? lgrp 1 space 2813952K, 0% used
>                      ? ? ? lgrp 2 space 2813952K, 0% used
>                      ? ? ? lgrp 3 space 2813952K, 0% used
>                      ? ? ? lgrp 4 space 2813952K, 0% used
>                      ? ? ? lgrp 5 space 2813952K, 0% used
>                      ? ? ? lgrp 6 space 2813952K, 0% used
>                      ? ? ? lgrp 7 space 2813952K, 0% used
>                     After Patch : gc.log
>                     eden space 46718976K(45GB), 99% used(NUMA disabled)
> 
>                     Case 2 : Multiple NUMA node bind
>                     numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g
>                     -Xmx50g -Xmn45g
>                     -XX:+UseNUMA
>                     -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>                     <composite_application>
>                     Before Patch :gc.log
>                     eden space 46718976K, 6% used
>                      ? ? ? lgrp 0 space 5838848K, 14% used
>                      ? ? ? lgrp 1 space 5838848K, 0% used
>                      ? ? ? lgrp 2 space 5838848K, 0% used
>                      ? ? ? lgrp 3 space 5838848K, 0% used
>                      ? ? ? lgrp 4 space 5838848K, 0% used
>                      ? ? ? lgrp 5 space 5838848K, 0% used
>                      ? ? ? lgrp 6 space 5838848K, 0% used
>                      ? ? ? lgrp 7 space 5847040K, 35% used
>                     After Patch : gc.log
>                     eden space 46718976K(45GB), 99% used
>                      ? ? ? ?lgrp 0 space 23359488K(23.5GB), 100% used
>                      ? ? ? ?lgrp 7 space 23359488K(23.5GB), 99% used
> 
> 
>                     Note: The proposed solution is only for numactl
>                     membind option.The fix
>                     is not for --cpunodebind and localalloc which is a
>                     separate bug bug
>                     https://bugs.openjdk.java.net/browse/JDK-8205051
>                     <https://bugs.openjdk.java.net/browse/JDK-8205051>
>                     and fix is in progress
>                     on this.
> 
>                     Thanks,
>                     Swati Sharma
>                     Software Engineer -2 at AMD
> 
> 
> 
> 
> 

From fairoz.matte at oracle.com  Tue Jul  3 06:15:05 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Mon, 2 Jul 2018 23:15:05 -0700 (PDT)
Subject: [8u-backport] RFR: JDK-8081323: ConstantPool::_resolved_references is
 missing in heap dump
Message-ID: <da8d3209-a5c4-4c55-9563-662af505322e@default>

Hi,

Kindly review the backport of "JDK-8081323: ConstantPool::_resolved_references is missing in heap dump" to 8u

I have manually verified the issue with Yourkit, kindly check the images attached to backport bug (https://bugs.openjdk.java.net/browse/JDK-8198556)
Also ran hotspot tests.

Webrev - http://cr.openjdk.java.net/~fmatte/8081323/webrev.00/  

JDK 10 bug - https://bugs.openjdk.java.net/browse/JDK-8081323 

JDK 10 changeset - http://hg.openjdk.java.net/jdk10/hs/rev/d8e417df3468  

Review thread - http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028215.html 

Thanks,
Fairoz

From david.holmes at oracle.com  Tue Jul  3 06:45:40 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Jul 2018 16:45:40 +1000
Subject: [8u-backport] RFR: JDK-8081323:
 ConstantPool::_resolved_references is missing in heap dump
In-Reply-To: <da8d3209-a5c4-4c55-9563-662af505322e@default>
References: <da8d3209-a5c4-4c55-9563-662af505322e@default>
Message-ID: <cd0b19fa-ab72-2f7b-7b0d-66acf56fa66e@oracle.com>

Hi Fairoz,

This seems to be an accurate backport of the JDK 10 changes. But I can't 
comment on the applicability of those changes in 8u.

David

On 3/07/2018 4:15 PM, Fairoz Matte wrote:
> Hi,
> 
> Kindly review the backport of "JDK-8081323: ConstantPool::_resolved_references is missing in heap dump" to 8u
> 
> I have manually verified the issue with Yourkit, kindly check the images attached to backport bug (https://bugs.openjdk.java.net/browse/JDK-8198556)
> Also ran hotspot tests.
> 
> Webrev - http://cr.openjdk.java.net/~fmatte/8081323/webrev.00/
> 
> JDK 10 bug - https://bugs.openjdk.java.net/browse/JDK-8081323
> 
> JDK 10 changeset - http://hg.openjdk.java.net/jdk10/hs/rev/d8e417df3468
> 
> Review thread - http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028215.html
> 
> Thanks,
> Fairoz
> 

From volker.simonis at gmail.com  Tue Jul  3 07:03:49 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 3 Jul 2018 09:03:49 +0200
Subject: [11] RFR(XS): MallocSiteTable::initialize() doesn't take function
 descriptors into account
In-Reply-To: <bf795eaf-a9ab-61b3-9893-490e9d3bb3c2@redhat.com>
References: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>
 <bf795eaf-a9ab-61b3-9893-490e9d3bb3c2@redhat.com>
Message-ID: <CA+3eh11OeozG-0btKKXUHCb3Te86+fSHTHaeO0B8M+2AmenrmQ@mail.gmail.com>

On Tue, Jul 3, 2018 at 1:09 AM, Zhengyu Gu <zgu at redhat.com> wrote:
> Hi Volker,
>
> fp[0] should work with little endian as well, right?
>

Yes, of course. But little endian doesn't use function descriptors. On
little endian the new ABI ELFv2 version is used which uses plain
function pointers like on x86.

> I wonder if change
>
> pc[2] = (address)MallocSiteTable::allocation_at;
>
> to
>
> pc[2] = (address)(&MallocSiteTable::allocation_at);
>
> will work.
>

No it won't! You really have to manually decompose the function
descriptor. You also have to be careful when trying things in gdb
because inside gdb you may manage to cast the function descriptor to
the corresponding function pointer. But the C/C++ compiler only gives
you access to the function descriptor.

Regards,
Volker

> Thanks,
>
> -Zhengyu
>
>
> On 07/02/2018 01:27 PM, Volker Simonis wrote:
>>
>> Hi,
>>
>> can I please have a review for this trivial change which fixes a
>> problem on Linux/ppc64
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206173/
>> https://bugs.openjdk.java.net/browse/JDK-8206173
>>
>> MallocSiteTable::initialize() creates a pseudo call stack for
>> hashtable entry allocations which is populated with the addresses of
>> some well-known static methods.
>>
>> However, taking the address of a function or static method in C/C++
>> isn't required to return the actual code address where that function
>> lives in memory. On ppc64 (i.e. big-endian, ABI ELFv1) applying the
>> address operator on a function will return the functions "function
>> descriptor" (see
>>
>> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES)
>> which is a struct of three pointers where the first one points to the
>> actual function address.
>>
>> In order to get a correct stack trace on ppc64 as well, we therefore
>> have to dereference the function descriptor before we can store the
>> real function address in the stack trace.
>>
>> In order to make the shared code fix less intrusive, I've added a pair
>> of LITTLE_ENDIAN_ONLY/BIG_ENDIAN_ONLY macros to macros.hpp.
>>
>> This bug is the reason why runtime/ElfDecoder/TestElfDirectRead.java
>> fails on Linux/ppc64.
>>
>> Thank you and best regards,
>> Volker
>>
>

From ioi.lam at oracle.com  Tue Jul  3 07:12:33 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 3 Jul 2018 00:12:33 -0700
Subject: RFR(S/M) : 8202561 : clean up TEST.groups file
In-Reply-To: <69c8a863-dedd-1c61-d739-d944bc9cc786@oracle.com>
References: <19F6C0D7-EA7D-456D-BB3E-68EE786C3125@oracle.com>
 <69c8a863-dedd-1c61-d739-d944bc9cc786@oracle.com>
Message-ID: <7972563c-fc6c-4204-7b3c-689a97e47883@oracle.com>

Changes look good. I agree with Vladimir that creating a new 
TEST.quick-groups file is better.

Thanks

- Ioi


On 7/2/18 4:09 PM, Vladimir Kozlov wrote:
> Thank you for doing this. Looks fine. One question is why you cloned 
> TEST.groups instead of creating new file? Diffs look confusing.
>
> Vladimir
>
> On 6/28/18 11:09 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8202561/webrev.00/index.html
>>> 2262 lines changed: 2 ins; 2258 del; 2 mod
>>
>> Hi all,
>>
>> could you please review the clean up for hotspot TEST.groups file?
>>
>> the patch moves all vmTestbase_*_quick groups to a separate file 
>> TEST.quick-groups.
>>
>> webrev: 
>> http://cr.openjdk.java.net/~iignatyev//8202561/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202561
>>
>> Thanks,
>> -- Igor
>>


From thomas.stuefe at gmail.com  Tue Jul  3 07:41:56 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 3 Jul 2018 09:41:56 +0200
Subject: [11] RFR(XS): MallocSiteTable::initialize() doesn't take function
 descriptors into account
In-Reply-To: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>
References: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>
Message-ID: <CAA-vtUzzyLT4u=t7Z6BvRrLxN2tkx5diKexZP1pwrHoFmMM0jg@mail.gmail.com>

Hi Volker,

short term, this is okay.

As discussed offlist:

I would prefer a more generic solution for these kind of things, since
we resolve function descriptors at various places already (see struct
FunctionDescriptor) and since ppc64 is also not the only architecture
having function descriptors, this would justify a more generic
solution.

Long term, I would prefer something like

os::resolve_function_address_from_descriptor(address function_descriptor);

with the idea that this is to be called with function names and shall
return the start of the function code. On most archs, this would just
return the input pointer, on ppc64 and other archs like this it would
resolve the function descriptor.

But as I wrote, this change is okay for now.

Suggested change:

- three native pointers where the first pointer is the real function address.
+ three native pointers of which the first pointer is the real function address.

I do not need another webrev.

Thanks, Thomas



On Mon, Jul 2, 2018 at 7:27 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> Hi,
>
> can I please have a review for this trivial change which fixes a
> problem on Linux/ppc64
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206173/
> https://bugs.openjdk.java.net/browse/JDK-8206173
>
> MallocSiteTable::initialize() creates a pseudo call stack for
> hashtable entry allocations which is populated with the addresses of
> some well-known static methods.
>
> However, taking the address of a function or static method in C/C++
> isn't required to return the actual code address where that function
> lives in memory. On ppc64 (i.e. big-endian, ABI ELFv1) applying the
> address operator on a function will return the functions "function
> descriptor" (see
> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES)
> which is a struct of three pointers where the first one points to the
> actual function address.
>
> In order to get a correct stack trace on ppc64 as well, we therefore
> have to dereference the function descriptor before we can store the
> real function address in the stack trace.
>
> In order to make the shared code fix less intrusive, I've added a pair
> of LITTLE_ENDIAN_ONLY/BIG_ENDIAN_ONLY macros to macros.hpp.
>
> This bug is the reason why runtime/ElfDecoder/TestElfDirectRead.java
> fails on Linux/ppc64.
>
> Thank you and best regards,
> Volker

From zgu at redhat.com  Tue Jul  3 11:47:15 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 3 Jul 2018 07:47:15 -0400
Subject: [11] RFR(XS): MallocSiteTable::initialize() doesn't take function
 descriptors into account
In-Reply-To: <CA+3eh11OeozG-0btKKXUHCb3Te86+fSHTHaeO0B8M+2AmenrmQ@mail.gmail.com>
References: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>
 <bf795eaf-a9ab-61b3-9893-490e9d3bb3c2@redhat.com>
 <CA+3eh11OeozG-0btKKXUHCb3Te86+fSHTHaeO0B8M+2AmenrmQ@mail.gmail.com>
Message-ID: <873421ca-c7aa-f26e-04b4-f441adddf0ad@redhat.com>



On 07/03/2018 03:03 AM, Volker Simonis wrote:
> On Tue, Jul 3, 2018 at 1:09 AM, Zhengyu Gu <zgu at redhat.com> wrote:
>> Hi Volker,
>>
>> fp[0] should work with little endian as well, right?
>>
> 
> Yes, of course. But little endian doesn't use function descriptors. On
> little endian the new ABI ELFv2 version is used which uses plain
> function pointers like on x86.

Ah, thanks for explaining.

> 
>> I wonder if change
>>
>> pc[2] = (address)MallocSiteTable::allocation_at;
>>
>> to
>>
>> pc[2] = (address)(&MallocSiteTable::allocation_at);
>>
>> will work.
>>
> 
> No it won't! You really have to manually decompose the function
> descriptor. You also have to be careful when trying things in gdb
> because inside gdb you may manage to cast the function descriptor to
> the corresponding function pointer. But the C/C++ compiler only gives
> you access to the function descriptor.


I agree with Thomas, ABI issues should be addressed at os level. The 
comments in elfFuncDescTable.hpp mentions "and other architectures like 
for example IA64 ...", not sure if "other" will pop up at some point.

Thanks,

-Zhengyu


> 
> Regards,
> Volker
> 
>> Thanks,
>>
>> -Zhengyu
>>
>>
>> On 07/02/2018 01:27 PM, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> can I please have a review for this trivial change which fixes a
>>> problem on Linux/ppc64
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206173/
>>> https://bugs.openjdk.java.net/browse/JDK-8206173
>>>
>>> MallocSiteTable::initialize() creates a pseudo call stack for
>>> hashtable entry allocations which is populated with the addresses of
>>> some well-known static methods.
>>>
>>> However, taking the address of a function or static method in C/C++
>>> isn't required to return the actual code address where that function
>>> lives in memory. On ppc64 (i.e. big-endian, ABI ELFv1) applying the
>>> address operator on a function will return the functions "function
>>> descriptor" (see
>>>
>>> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES)
>>> which is a struct of three pointers where the first one points to the
>>> actual function address.
>>>
>>> In order to get a correct stack trace on ppc64 as well, we therefore
>>> have to dereference the function descriptor before we can store the
>>> real function address in the stack trace.
>>>
>>> In order to make the shared code fix less intrusive, I've added a pair
>>> of LITTLE_ENDIAN_ONLY/BIG_ENDIAN_ONLY macros to macros.hpp.
>>>
>>> This bug is the reason why runtime/ElfDecoder/TestElfDirectRead.java
>>> fails on Linux/ppc64.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>

From zgu at redhat.com  Tue Jul  3 12:38:18 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 3 Jul 2018 08:38:18 -0400
Subject: [11] RFR(XS): MallocSiteTable::initialize() doesn't take function
 descriptors into account
In-Reply-To: <873421ca-c7aa-f26e-04b4-f441adddf0ad@redhat.com>
References: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>
 <bf795eaf-a9ab-61b3-9893-490e9d3bb3c2@redhat.com>
 <CA+3eh11OeozG-0btKKXUHCb3Te86+fSHTHaeO0B8M+2AmenrmQ@mail.gmail.com>
 <873421ca-c7aa-f26e-04b4-f441adddf0ad@redhat.com>
Message-ID: <c7b01136-bdff-ef2f-5657-47c384c66b64@redhat.com>

BTW, patch looks good as short term fix.

Thanks,

-Zhengyu

On 07/03/2018 07:47 AM, Zhengyu Gu wrote:
> 
> 
> On 07/03/2018 03:03 AM, Volker Simonis wrote:
>> On Tue, Jul 3, 2018 at 1:09 AM, Zhengyu Gu <zgu at redhat.com> wrote:
>>> Hi Volker,
>>>
>>> fp[0] should work with little endian as well, right?
>>>
>>
>> Yes, of course. But little endian doesn't use function descriptors. On
>> little endian the new ABI ELFv2 version is used which uses plain
>> function pointers like on x86.
> 
> Ah, thanks for explaining.
> 
>>
>>> I wonder if change
>>>
>>> pc[2] = (address)MallocSiteTable::allocation_at;
>>>
>>> to
>>>
>>> pc[2] = (address)(&MallocSiteTable::allocation_at);
>>>
>>> will work.
>>>
>>
>> No it won't! You really have to manually decompose the function
>> descriptor. You also have to be careful when trying things in gdb
>> because inside gdb you may manage to cast the function descriptor to
>> the corresponding function pointer. But the C/C++ compiler only gives
>> you access to the function descriptor.
> 
> 
> I agree with Thomas, ABI issues should be addressed at os level. The 
> comments in elfFuncDescTable.hpp mentions "and other architectures like 
> for example IA64 ...", not sure if "other" will pop up at some point.
> 
> Thanks,
> 
> -Zhengyu
> 
> 
>>
>> Regards,
>> Volker
>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> On 07/02/2018 01:27 PM, Volker Simonis wrote:
>>>>
>>>> Hi,
>>>>
>>>> can I please have a review for this trivial change which fixes a
>>>> problem on Linux/ppc64
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206173/
>>>> https://bugs.openjdk.java.net/browse/JDK-8206173
>>>>
>>>> MallocSiteTable::initialize() creates a pseudo call stack for
>>>> hashtable entry allocations which is populated with the addresses of
>>>> some well-known static methods.
>>>>
>>>> However, taking the address of a function or static method in C/C++
>>>> isn't required to return the actual code address where that function
>>>> lives in memory. On ppc64 (i.e. big-endian, ABI ELFv1) applying the
>>>> address operator on a function will return the functions "function
>>>> descriptor" (see
>>>>
>>>> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES) 
>>>>
>>>> which is a struct of three pointers where the first one points to the
>>>> actual function address.
>>>>
>>>> In order to get a correct stack trace on ppc64 as well, we therefore
>>>> have to dereference the function descriptor before we can store the
>>>> real function address in the stack trace.
>>>>
>>>> In order to make the shared code fix less intrusive, I've added a pair
>>>> of LITTLE_ENDIAN_ONLY/BIG_ENDIAN_ONLY macros to macros.hpp.
>>>>
>>>> This bug is the reason why runtime/ElfDecoder/TestElfDirectRead.java
>>>> fails on Linux/ppc64.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>

From volker.simonis at gmail.com  Tue Jul  3 13:50:25 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 3 Jul 2018 15:50:25 +0200
Subject: [11] RFR(XS): MallocSiteTable::initialize() doesn't take function
 descriptors into account
In-Reply-To: <c7b01136-bdff-ef2f-5657-47c384c66b64@redhat.com>
References: <CA+3eh10VP9wfxFWhEssnB2d9rWUUzdgVtkbB-VxpbBV9iv_Kbg@mail.gmail.com>
 <bf795eaf-a9ab-61b3-9893-490e9d3bb3c2@redhat.com>
 <CA+3eh11OeozG-0btKKXUHCb3Te86+fSHTHaeO0B8M+2AmenrmQ@mail.gmail.com>
 <873421ca-c7aa-f26e-04b4-f441adddf0ad@redhat.com>
 <c7b01136-bdff-ef2f-5657-47c384c66b64@redhat.com>
Message-ID: <CA+3eh13c=38P23O58boyyO6gPZ0yYyi-Gv7MXeCjz27YEHnYfQ@mail.gmail.com>

Thank you Zhengyu!

On Tue, Jul 3, 2018 at 2:38 PM, Zhengyu Gu <zgu at redhat.com> wrote:
> BTW, patch looks good as short term fix.
>
> Thanks,
>
> -Zhengyu
>
>
> On 07/03/2018 07:47 AM, Zhengyu Gu wrote:
>>
>>
>>
>> On 07/03/2018 03:03 AM, Volker Simonis wrote:
>>>
>>> On Tue, Jul 3, 2018 at 1:09 AM, Zhengyu Gu <zgu at redhat.com> wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> fp[0] should work with little endian as well, right?
>>>>
>>>
>>> Yes, of course. But little endian doesn't use function descriptors. On
>>> little endian the new ABI ELFv2 version is used which uses plain
>>> function pointers like on x86.
>>
>>
>> Ah, thanks for explaining.
>>
>>>
>>>> I wonder if change
>>>>
>>>> pc[2] = (address)MallocSiteTable::allocation_at;
>>>>
>>>> to
>>>>
>>>> pc[2] = (address)(&MallocSiteTable::allocation_at);
>>>>
>>>> will work.
>>>>
>>>
>>> No it won't! You really have to manually decompose the function
>>> descriptor. You also have to be careful when trying things in gdb
>>> because inside gdb you may manage to cast the function descriptor to
>>> the corresponding function pointer. But the C/C++ compiler only gives
>>> you access to the function descriptor.
>>
>>
>>
>> I agree with Thomas, ABI issues should be addressed at os level. The
>> comments in elfFuncDescTable.hpp mentions "and other architectures like for
>> example IA64 ...", not sure if "other" will pop up at some point.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>>
>>> Regards,
>>> Volker
>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>> On 07/02/2018 01:27 PM, Volker Simonis wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> can I please have a review for this trivial change which fixes a
>>>>> problem on Linux/ppc64
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206173/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8206173
>>>>>
>>>>> MallocSiteTable::initialize() creates a pseudo call stack for
>>>>> hashtable entry allocations which is populated with the addresses of
>>>>> some well-known static methods.
>>>>>
>>>>> However, taking the address of a function or static method in C/C++
>>>>> isn't required to return the actual code address where that function
>>>>> lives in memory. On ppc64 (i.e. big-endian, ABI ELFv1) applying the
>>>>> address operator on a function will return the functions "function
>>>>> descriptor" (see
>>>>>
>>>>>
>>>>> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES)
>>>>> which is a struct of three pointers where the first one points to the
>>>>> actual function address.
>>>>>
>>>>> In order to get a correct stack trace on ppc64 as well, we therefore
>>>>> have to dereference the function descriptor before we can store the
>>>>> real function address in the stack trace.
>>>>>
>>>>> In order to make the shared code fix less intrusive, I've added a pair
>>>>> of LITTLE_ENDIAN_ONLY/BIG_ENDIAN_ONLY macros to macros.hpp.
>>>>>
>>>>> This bug is the reason why runtime/ElfDecoder/TestElfDirectRead.java
>>>>> fails on Linux/ppc64.
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>
>

From aph at redhat.com  Tue Jul  3 14:31:21 2018
From: aph at redhat.com (aph)
Date: Tue, 3 Jul 2018 15:31:21 +0100
Subject: RFR: 8206267: Unsafe publication of StubCodeDesc leads to crashes
Message-ID: <aeb0adbe-ff8e-e722-db84-cc2aecd5bdc8@redhat.com>

The StubCodeDesc constructor is unsychronized. However, it runs when
the C2 compiler thread is initializing. The compiler thread reads the
StubCodeDesc list while it is in an unstable state, resulting in a
read from an uninitialized pointer field and it then segfaults,
causing the VM to abort.

http://cr.openjdk.java.net/~aph/8206267/

OK for 11 and 12?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From coleen.phillimore at oracle.com  Tue Jul  3 14:49:54 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 3 Jul 2018 10:49:54 -0400
Subject: [8u-backport] RFR: JDK-8081323:
 ConstantPool::_resolved_references is missing in heap dump
In-Reply-To: <da8d3209-a5c4-4c55-9563-662af505322e@default>
References: <da8d3209-a5c4-4c55-9563-662af505322e@default>
Message-ID: <f1319a80-08af-5a7c-4492-226714aa1521@oracle.com>


Hi Fairoz,? This change looks good and applicable to jdk8u.? The name of 
init_lock will come out as "init_lock" rather than "<init_lock>" in the 
original but I think this is ok.? Better than having two different 
vmSymbols::init_lock_name() functions.

Thanks,
Coleen

On 7/3/18 2:15 AM, Fairoz Matte wrote:
> Hi,
>
> Kindly review the backport of "JDK-8081323: ConstantPool::_resolved_references is missing in heap dump" to 8u
>
> I have manually verified the issue with Yourkit, kindly check the images attached to backport bug (https://bugs.openjdk.java.net/browse/JDK-8198556)
> Also ran hotspot tests.
>
> Webrev - http://cr.openjdk.java.net/~fmatte/8081323/webrev.00/
>
> JDK 10 bug - https://bugs.openjdk.java.net/browse/JDK-8081323
>
> JDK 10 changeset - http://hg.openjdk.java.net/jdk10/hs/rev/d8e417df3468
>
> Review thread - http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028215.html
>
> Thanks,
> Fairoz


From shade at redhat.com  Tue Jul  3 14:57:39 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Jul 2018 16:57:39 +0200
Subject: RFR: 8206267: Unsafe publication of StubCodeDesc leads to crashes
In-Reply-To: <aeb0adbe-ff8e-e722-db84-cc2aecd5bdc8@redhat.com>
References: <aeb0adbe-ff8e-e722-db84-cc2aecd5bdc8@redhat.com>
Message-ID: <782ea25b-dc66-3ad1-d023-70345f59ee58@redhat.com>

On 07/03/2018 04:31 PM, aph wrote:
> The StubCodeDesc constructor is unsychronized. However, it runs when
> the C2 compiler thread is initializing. The compiler thread reads the
> StubCodeDesc list while it is in an unstable state, resulting in a
> read from an uninitialized pointer field and it then segfaults,
> causing the VM to abort.
> 
> http://cr.openjdk.java.net/~aph/8206267/
> 
> OK for 11 and 12?

Looks good for 12.
Looks simple enough for 11.

Star formatting is a bit awkward:
   37 StubCodeDesc *volatile StubCodeDesc::_list = NULL;
   ...
   42   static StubCodeDesc *volatile _list;         // the list of all descriptors

...should probably be:
   37 StubCodeDesc* volatile StubCodeDesc::_list = NULL;
   ...
   42   static StubCodeDesc* volatile _list;         // the list of all descriptors


-Aleksey



From aph at redhat.com  Tue Jul  3 15:16:04 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 3 Jul 2018 16:16:04 +0100
Subject: RFR: 8206267: Unsafe publication of StubCodeDesc leads to crashes
In-Reply-To: <782ea25b-dc66-3ad1-d023-70345f59ee58@redhat.com>
References: <aeb0adbe-ff8e-e722-db84-cc2aecd5bdc8@redhat.com>
 <782ea25b-dc66-3ad1-d023-70345f59ee58@redhat.com>
Message-ID: <55629334-1f50-98c8-9530-c616234d2a97@redhat.com>

On 07/03/2018 03:57 PM, Aleksey Shipilev wrote:
> On 07/03/2018 04:31 PM, aph wrote:
>> The StubCodeDesc constructor is unsychronized. However, it runs when
>> the C2 compiler thread is initializing. The compiler thread reads the
>> StubCodeDesc list while it is in an unstable state, resulting in a
>> read from an uninitialized pointer field and it then segfaults,
>> causing the VM to abort.
>>
>> http://cr.openjdk.java.net/~aph/8206267/
>>
>> OK for 11 and 12?
> 
> Looks good for 12.
> Looks simple enough for 11.
> 
> Star formatting is a bit awkward:
>    37 StubCodeDesc *volatile StubCodeDesc::_list = NULL;
>    ...
>    42   static StubCodeDesc *volatile _list;         // the list of all descriptors
> 
> ...should probably be:
>    37 StubCodeDesc* volatile StubCodeDesc::_list = NULL;
>    ...
>    42   static StubCodeDesc* volatile _list;         // the list of all descriptors

That's incorrect.  Indirection binds to the right.

You need to get it right for:

   int *a, b;

which would be highly misleading as

   int *a, b;

But anyway, I have withdrawn the bug report: it's been fixed a
different way in current sources.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Jul  3 15:17:21 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 3 Jul 2018 16:17:21 +0100
Subject: RFR: 8206267: Unsafe publication of StubCodeDesc leads to crashes
In-Reply-To: <55629334-1f50-98c8-9530-c616234d2a97@redhat.com>
References: <aeb0adbe-ff8e-e722-db84-cc2aecd5bdc8@redhat.com>
 <782ea25b-dc66-3ad1-d023-70345f59ee58@redhat.com>
 <55629334-1f50-98c8-9530-c616234d2a97@redhat.com>
Message-ID: <edf1080b-6525-59be-a40a-9cdea406f82f@redhat.com>

On 07/03/2018 04:16 PM, Andrew Haley wrote:
> which would be highly misleading as
> 
>    int *a, b;

   int* a, b;

LOL!  It's too hot to think today.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Tue Jul  3 15:42:33 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 3 Jul 2018 16:42:33 +0100
Subject: Patch withdrawn: 8206267: Unsafe publication of StubCodeDesc leads to
 crashes
In-Reply-To: <aeb0adbe-ff8e-e722-db84-cc2aecd5bdc8@redhat.com>
References: <aeb0adbe-ff8e-e722-db84-cc2aecd5bdc8@redhat.com>
Message-ID: <7278f633-fe24-5356-cf80-17297395ae5e@redhat.com>

FYI.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From paul.sandoz at oracle.com  Tue Jul  3 16:26:44 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Jul 2018 09:26:44 -0700
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
In-Reply-To: <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>
References: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
 <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>
Message-ID: <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>



> On Jul 2, 2018, at 11:43 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> On 7/2/18 10:39 AM, Paul Sandoz wrote:
>> Hi,
>> Please review this fix for 11:
>>   http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-tag/webrev/
> 
> Seems good to me. I will run testing with it.
> 

Thanks, i see all relevant tests pass, so ok to push?

Paul.

From vladimir.kozlov at oracle.com  Tue Jul  3 17:11:45 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 3 Jul 2018 10:11:45 -0700
Subject: 8138922: StubCodeDesc constructor publishes partially-constructed
 objects on StubCodeDesc::_list
In-Reply-To: <7b6eeb93-0259-6019-4ef4-02a93799eefe@redhat.com>
References: <7b6eeb93-0259-6019-4ef4-02a93799eefe@redhat.com>
Message-ID: <2fef682c-e9c5-e1e0-b1ac-6a1380405e85@oracle.com>

There was also following fix in JDK 9 (and no backport to 8u) which 
removed desc_for_index():

http://hg.openjdk.java.net/jdk/jdk/rev/cb578d8c6cba

I agree that both fixes should be backported. Or at least 8138922.

I also did not find any traces of backport requests and no labels were 
added.

Regards,
Vladimir

On 7/3/18 8:39 AM, Andrew Haley wrote:
> This is bug:
> 
> 8138922: StubCodeDesc constructor publishes partially-constructed objects on StubCodeDesc::_list
> 
> Fixed in JDK 9 by:
> 
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/30b120bce29d
> 
> However, I am seeing crashes in 8u, and the fix was never back-ported.
> 
> I don't know why it wasn't back-ported, but I guess it should be.  I
> can't find any discussion of a possible back-port.  Does anyone
> remember?
> 

From vladimir.kozlov at oracle.com  Tue Jul  3 17:14:14 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 3 Jul 2018 10:14:14 -0700
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
In-Reply-To: <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>
References: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
 <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>
 <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>
Message-ID: <b0cd02f6-3e1f-919f-2652-fe13bcb747bd@oracle.com>

Yes, compiler tests passed. And you tested failed combination.

I think it needs second review. May be someone from runtime.

Thanks,
Vladimir

On 7/3/18 9:26 AM, Paul Sandoz wrote:
> 
> 
>> On Jul 2, 2018, at 11:43 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> On 7/2/18 10:39 AM, Paul Sandoz wrote:
>>> Hi,
>>> Please review this fix for 11:
>>>    http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-tag/webrev/
>>
>> Seems good to me. I will run testing with it.
>>
> 
> Thanks, i see all relevant tests pass, so ok to push?
> 
> Paul.
> 

From coleen.phillimore at oracle.com  Tue Jul  3 17:25:43 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 3 Jul 2018 13:25:43 -0400
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
In-Reply-To: <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>
References: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
 <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>
 <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>
Message-ID: <41c56c1e-4404-944c-dba0-b9c937bd36b7@oracle.com>



On 7/3/18 12:26 PM, Paul Sandoz wrote:
>
>> On Jul 2, 2018, at 11:43 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> On 7/2/18 10:39 AM, Paul Sandoz wrote:
>>> Hi,
>>> Please review this fix for 11:
>>>    http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-tag/webrev/
>> Seems good to me. I will run testing with it.
>>
> Thanks, i see all relevant tests pass, so ok to push?

You need two reviewers, and are you pushing this to JDK11 ?

The patch in the bug report seems better because you don't know that all 
of the callers want to convert JVM_CONSTANT_Dynamic to the underlying 
type that the Symbol points to.? The name of the ciStream function 
implies that it just returns tag_at().?? I would assume that there would 
be other callers that want to do something with the actual tag, like 
print the bytecode stream for example.

Coleen

>
> Paul.


From paul.sandoz at oracle.com  Tue Jul  3 17:44:27 2018
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Jul 2018 10:44:27 -0700
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
In-Reply-To: <41c56c1e-4404-944c-dba0-b9c937bd36b7@oracle.com>
References: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
 <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>
 <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>
 <41c56c1e-4404-944c-dba0-b9c937bd36b7@oracle.com>
Message-ID: <AF9FEAFD-CA62-4B0D-BC98-3910A1186E4D@oracle.com>



> On Jul 3, 2018, at 10:25 AM, coleen.phillimore at oracle.com wrote:
> 
> 
> 
> On 7/3/18 12:26 PM, Paul Sandoz wrote:
>> 
>>> On Jul 2, 2018, at 11:43 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> On 7/2/18 10:39 AM, Paul Sandoz wrote:
>>>> Hi,
>>>> Please review this fix for 11:
>>>>   http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-tag/webrev/
>>> Seems good to me. I will run testing with it.
>>> 
>> Thanks, i see all relevant tests pass, so ok to push?
> 
> You need two reviewers,

Ok.


> and are you pushing this to JDK11 ?
> 

Yes.


> The patch in the bug report seems better because you don't know that all of the callers want to convert JVM_CONSTANT_Dynamic to the underlying type that the Symbol points to.  The name of the ciStream function implies that it just returns tag_at().   I would assume that there would be other callers that want to do something with the actual tag, like print the bytecode stream for example.
> 

The patch in the bug report was a quick hack to get the test running by reverting what was pushed for constant dynamic support, but it will result in failures if it encounters a constant dynamic entry as the type of the dynamic constant is required and not JVM_CONSTANT_Dynamic.

The method ciBytecodeStream::get_constant_pool_tag is used for producing ldc instructions in what appears to be specialized cases, see the two usages in BCEscapeAnalyzer::iterate_one_block and Parse::do_one_bytecode.

We could rename it to Parse::get_constant_pool_tag_for_ldc ? if so would prefer to do that as a separate issue for 12 only.

Thanks,
Paul.

> Coleen
> 
>> 
>> Paul.
> 


From coleen.phillimore at oracle.com  Tue Jul  3 17:54:03 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 3 Jul 2018 13:54:03 -0400
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
In-Reply-To: <AF9FEAFD-CA62-4B0D-BC98-3910A1186E4D@oracle.com>
References: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
 <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>
 <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>
 <41c56c1e-4404-944c-dba0-b9c937bd36b7@oracle.com>
 <AF9FEAFD-CA62-4B0D-BC98-3910A1186E4D@oracle.com>
Message-ID: <581d3936-f9f7-fee6-44f9-3038642d6387@oracle.com>



On 7/3/18 1:44 PM, Paul Sandoz wrote:
>
>> On Jul 3, 2018, at 10:25 AM, coleen.phillimore at oracle.com wrote:
>>
>>
>>
>> On 7/3/18 12:26 PM, Paul Sandoz wrote:
>>>> On Jul 2, 2018, at 11:43 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>
>>>> On 7/2/18 10:39 AM, Paul Sandoz wrote:
>>>>> Hi,
>>>>> Please review this fix for 11:
>>>>>    http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-tag/webrev/
>>>> Seems good to me. I will run testing with it.
>>>>
>>> Thanks, i see all relevant tests pass, so ok to push?
>> You need two reviewers,
> Ok.
>
>
>> and are you pushing this to JDK11 ?
>>
> Yes.
>
>
>> The patch in the bug report seems better because you don't know that all of the callers want to convert JVM_CONSTANT_Dynamic to the underlying type that the Symbol points to.  The name of the ciStream function implies that it just returns tag_at().   I would assume that there would be other callers that want to do something with the actual tag, like print the bytecode stream for example.
>>
> The patch in the bug report was a quick hack to get the test running by reverting what was pushed for constant dynamic support, but it will result in failures if it encounters a constant dynamic entry as the type of the dynamic constant is required and not JVM_CONSTANT_Dynamic.
>
> The method ciBytecodeStream::get_constant_pool_tag is used for producing ldc instructions in what appears to be specialized cases, see the two usages in BCEscapeAnalyzer::iterate_one_block and Parse::do_one_bytecode.
>
> We could rename it to Parse::get_constant_pool_tag_for_ldc ? if so would prefer to do that as a separate issue for 12 only.

I'm trying to sort out the logic with this.? If it's just used for ldc, 
it does look like what you want (like the change in bytecode.cpp).

The function name that I would like to see changed is 
ConstantPool::constant_at() becomes ConstantPool::constant_tag_at().

I think I understand this well enough to review it now.? Seems good.? 
Thank you for solving this problem!

Coleen

>
> Thanks,
> Paul.
>
>> Coleen
>>
>>> Paul.


From coleen.phillimore at oracle.com  Tue Jul  3 17:55:07 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 3 Jul 2018 13:55:07 -0400
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
In-Reply-To: <581d3936-f9f7-fee6-44f9-3038642d6387@oracle.com>
References: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
 <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>
 <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>
 <41c56c1e-4404-944c-dba0-b9c937bd36b7@oracle.com>
 <AF9FEAFD-CA62-4B0D-BC98-3910A1186E4D@oracle.com>
 <581d3936-f9f7-fee6-44f9-3038642d6387@oracle.com>
Message-ID: <32a52806-b577-0603-7109-b100927a4079@oracle.com>



On 7/3/18 1:54 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 7/3/18 1:44 PM, Paul Sandoz wrote:
>>
>>> On Jul 3, 2018, at 10:25 AM, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>>
>>> On 7/3/18 12:26 PM, Paul Sandoz wrote:
>>>>> On Jul 2, 2018, at 11:43 AM, Vladimir Kozlov 
>>>>> <vladimir.kozlov at oracle.com> wrote:
>>>>>
>>>>> On 7/2/18 10:39 AM, Paul Sandoz wrote:
>>>>>> Hi,
>>>>>> Please review this fix for 11:
>>>>>> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-tag/webrev/
>>>>> Seems good to me. I will run testing with it.
>>>>>
>>>> Thanks, i see all relevant tests pass, so ok to push?
>>> You need two reviewers,
>> Ok.
>>
>>
>>> and are you pushing this to JDK11 ?
>>>
>> Yes.
>>
>>
>>> The patch in the bug report seems better because you don't know that 
>>> all of the callers want to convert JVM_CONSTANT_Dynamic to the 
>>> underlying type that the Symbol points to.? The name of the ciStream 
>>> function implies that it just returns tag_at().?? I would assume 
>>> that there would be other callers that want to do something with the 
>>> actual tag, like print the bytecode stream for example.
>>>
>> The patch in the bug report was a quick hack to get the test running 
>> by reverting what was pushed for constant dynamic support, but it 
>> will result in failures if it encounters a constant dynamic entry as 
>> the type of the dynamic constant is required and not 
>> JVM_CONSTANT_Dynamic.
>>
>> The method ciBytecodeStream::get_constant_pool_tag is used for 
>> producing ldc instructions in what appears to be specialized cases, 
>> see the two usages in BCEscapeAnalyzer::iterate_one_block and 
>> Parse::do_one_bytecode.
>>
>> We could rename it to Parse::get_constant_pool_tag_for_ldc ? if so 
>> would prefer to do that as a separate issue for 12 only.
>
> I'm trying to sort out the logic with this.? If it's just used for 
> ldc, it does look like what you want (like the change in bytecode.cpp).
>
> The function name that I would like to see changed is 
> ConstantPool::constant_at() becomes ConstantPool::constant_tag_at().
>
> I think I understand this well enough to review it now.? Seems good.? 
> Thank you for solving this problem!
>
> Coleen
>
>>
>> Thanks,
>> Paul.
>>
>>> Coleen
>>>
>>>> Paul.
>


From igor.ignatyev at oracle.com  Tue Jul  3 17:58:49 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 3 Jul 2018 10:58:49 -0700
Subject: RFR(S/M) : 8206287 : fix legal notice in hotspot tests
Message-ID: <42C6AE70-F5B6-406E-BBB7-85C3E578A935@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8206287/webrev.00/index.html
> 243 lines changed: 0 ins; 124 del; 119 mod;

Hi all,

could you please review this patch which removes 'the Classpath exception' from hotspot tests? 

JBS: https://bugs.openjdk.java.net/browse/JDK-8206287
webrev: http://cr.openjdk.java.net/~iignatyev//8206287/webrev.00/index.html

Thanks,
-- Igor

From igor.ignatyev at oracle.com  Tue Jul  3 18:00:27 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 3 Jul 2018 11:00:27 -0700
Subject: RFR(S/M) : 8202561 : clean up TEST.groups file
In-Reply-To: <7972563c-fc6c-4204-7b3c-689a97e47883@oracle.com>
References: <19F6C0D7-EA7D-456D-BB3E-68EE786C3125@oracle.com>
 <69c8a863-dedd-1c61-d739-d944bc9cc786@oracle.com>
 <7972563c-fc6c-4204-7b3c-689a97e47883@oracle.com>
Message-ID: <3CB9AE4B-6C42-4172-8F4A-196EE409CB8B@oracle.com>

Ioi, Vladimir,

thank you for review, I'll make TEST.quick-groups a "new" file before pushing.

-- Igor

> On Jul 3, 2018, at 12:12 AM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> Changes look good. I agree with Vladimir that creating a new TEST.quick-groups file is better.
> 
> Thanks
> 
> - Ioi
> 
> 
> On 7/2/18 4:09 PM, Vladimir Kozlov wrote:
>> Thank you for doing this. Looks fine. One question is why you cloned TEST.groups instead of creating new file? Diffs look confusing.
>> 
>> Vladimir
>> 
>> On 6/28/18 11:09 AM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8202561/webrev.00/index.html
>>>> 2262 lines changed: 2 ins; 2258 del; 2 mod
>>> 
>>> Hi all,
>>> 
>>> could you please review the clean up for hotspot TEST.groups file?
>>> 
>>> the patch moves all vmTestbase_*_quick groups to a separate file TEST.quick-groups.
>>> 
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8202561/webrev.00/index.html
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202561
>>> 
>>> Thanks,
>>> -- Igor
>>> 
> 


From harold.seigel at oracle.com  Tue Jul  3 18:15:37 2018
From: harold.seigel at oracle.com (Harold David Seigel)
Date: Tue, 3 Jul 2018 14:15:37 -0400
Subject: RFR(S/M) : 8206287 : fix legal notice in hotspot tests
In-Reply-To: <42C6AE70-F5B6-406E-BBB7-85C3E578A935@oracle.com>
References: <42C6AE70-F5B6-406E-BBB7-85C3E578A935@oracle.com>
Message-ID: <574ae004-963e-3f44-52f2-ed575cc6fabe@oracle.com>

Looks good!

Thanks, Harold


On 7/3/2018 1:58 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8206287/webrev.00/index.html
>> 243 lines changed: 0 ins; 124 del; 119 mod;
> Hi all,
>
> could you please review this patch which removes 'the Classpath exception' from hotspot tests?
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8206287
> webrev: http://cr.openjdk.java.net/~iignatyev//8206287/webrev.00/index.html
>
> Thanks,
> -- Igor


From vladimir.kozlov at oracle.com  Tue Jul  3 19:18:56 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 3 Jul 2018 12:18:56 -0700
Subject: RFR(S/M) : 8206287 : fix legal notice in hotspot tests
In-Reply-To: <42C6AE70-F5B6-406E-BBB7-85C3E578A935@oracle.com>
References: <42C6AE70-F5B6-406E-BBB7-85C3E578A935@oracle.com>
Message-ID: <5cb03f53-4c70-8697-dbbc-ce8407f89044@oracle.com>

Looks good.

Would be nice to add a test which scan all tests headers for CPE to 
avoid adding tests with CPE in a future.

Thanks,
Vladimir

On 7/3/18 10:58 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8206287/webrev.00/index.html
>> 243 lines changed: 0 ins; 124 del; 119 mod;
> 
> Hi all,
> 
> could you please review this patch which removes 'the Classpath exception' from hotspot tests?
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8206287
> webrev: http://cr.openjdk.java.net/~iignatyev//8206287/webrev.00/index.html
> 
> Thanks,
> -- Igor
> 

From igor.ignatyev at oracle.com  Tue Jul  3 21:29:49 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 3 Jul 2018 14:29:49 -0700
Subject: RFR(S/M) : 8206287 : fix legal notice in hotspot tests
In-Reply-To: <5cb03f53-4c70-8697-dbbc-ce8407f89044@oracle.com>
References: <42C6AE70-F5B6-406E-BBB7-85C3E578A935@oracle.com>
 <5cb03f53-4c70-8697-dbbc-ce8407f89044@oracle.com>
Message-ID: <327F6822-7F7B-42FF-B849-8CA9B2AEA8AB@oracle.com>

Vladimir, Harold,

thank you for your review.

I'll create an RFE for adding a test to check legal notices. implementing one for tests is quite easy, but I think we should have some kind of test for the whole (hotspot) codebase.

-- Igor

> On Jul 3, 2018, at 12:18 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Looks good.
> 
> Would be nice to add a test which scan all tests headers for CPE to avoid adding tests with CPE in a future.
> 
> Thanks,
> Vladimir
> 
> On 7/3/18 10:58 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8206287/webrev.00/index.html
>>> 243 lines changed: 0 ins; 124 del; 119 mod;
>> Hi all,
>> could you please review this patch which removes 'the Classpath exception' from hotspot tests?
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206287
>> webrev: http://cr.openjdk.java.net/~iignatyev//8206287/webrev.00/index.html
>> Thanks,
>> -- Igor


From fairoz.matte at oracle.com  Wed Jul  4 04:26:32 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Tue, 3 Jul 2018 21:26:32 -0700 (PDT)
Subject: [8u-backport] RFR: JDK-8081323:
 ConstantPool::_resolved_references is missing in heap dump
In-Reply-To: <f1319a80-08af-5a7c-4492-226714aa1521@oracle.com>
References: <da8d3209-a5c4-4c55-9563-662af505322e@default>
 <f1319a80-08af-5a7c-4492-226714aa1521@oracle.com>
Message-ID: <d9781957-f15d-4e89-9ec5-00731e88fd4d@default>

Thank you Coleen and David for the reviews.

Thanks,
Fairoz

> -----Original Message-----
> From: Coleen Phillimore
> Sent: Tuesday, July 03, 2018 8:20 PM
> To: hotspot-dev at openjdk.java.net
> Subject: Re: [8u-backport] RFR: JDK-8081323:
> ConstantPool::_resolved_references is missing in heap dump
> 
> 
> Hi Fairoz,? This change looks good and applicable to jdk8u.? The name of
> init_lock will come out as "init_lock" rather than "<init_lock>" in the original
> but I think this is ok.? Better than having two different
> vmSymbols::init_lock_name() functions.
> 
> Thanks,
> Coleen
> 
> On 7/3/18 2:15 AM, Fairoz Matte wrote:
> > Hi,
> >
> > Kindly review the backport of "JDK-8081323:
> > ConstantPool::_resolved_references is missing in heap dump" to 8u
> >
> > I have manually verified the issue with Yourkit, kindly check the
> > images attached to backport bug
> > (https://bugs.openjdk.java.net/browse/JDK-8198556)
> > Also ran hotspot tests.
> >
> > Webrev - http://cr.openjdk.java.net/~fmatte/8081323/webrev.00/
> >
> > JDK 10 bug - https://bugs.openjdk.java.net/browse/JDK-8081323
> >
> > JDK 10 changeset -
> > http://hg.openjdk.java.net/jdk10/hs/rev/d8e417df3468
> >
> > Review thread -
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> September/0282
> > 15.html
> >
> > Thanks,
> > Fairoz
> 

From sgehwolf at redhat.com  Wed Jul  4 07:23:38 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 04 Jul 2018 09:23:38 +0200
Subject: 8138922: StubCodeDesc constructor publishes
 partially-constructed objects on StubCodeDesc::_list
In-Reply-To: <2fef682c-e9c5-e1e0-b1ac-6a1380405e85@oracle.com>
References: <7b6eeb93-0259-6019-4ef4-02a93799eefe@redhat.com>
 <2fef682c-e9c5-e1e0-b1ac-6a1380405e85@oracle.com>
Message-ID: <87cacadb2a514825dee57f21fca2fd8ef41f0c5c.camel@redhat.com>

On Tue, 2018-07-03 at 10:11 -0700, Vladimir Kozlov wrote:
> There was also following fix in JDK 9 (and no backport to 8u) which 
> removed desc_for_index():
> 
> http://hg.openjdk.java.net/jdk/jdk/rev/cb578d8c6cba
> 
> I agree that both fixes should be backported. Or at least 8138922.

FWIW 8138922 JDK 8 backport won't apply cleanly. Looks like the
difference between 9 and 8 is part of 8046809.

Thanks,
Severin

> I also did not find any traces of backport requests and no labels were 
> added.
> 
> Regards,
> Vladimir
> 
> On 7/3/18 8:39 AM, Andrew Haley wrote:
> > This is bug:
> > 
> > 8138922: StubCodeDesc constructor publishes partially-constructed objects on StubCodeDesc::_list
> > 
> > Fixed in JDK 9 by:
> > 
> > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/30b120bce29d
> > 
> > However, I am seeing crashes in 8u, and the fix was never back-ported.
> > 
> > I don't know why it wasn't back-ported, but I guess it should be.  I
> > can't find any discussion of a possible back-port.  Does anyone
> > remember?
> > 

From goetz.lindenmaier at sap.com  Wed Jul  4 07:46:22 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 4 Jul 2018 07:46:22 +0000
Subject: [11] RFR jck test fails with C2:
 vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
In-Reply-To: <AF9FEAFD-CA62-4B0D-BC98-3910A1186E4D@oracle.com>
References: <25804888-83C9-4EAD-87F4-D80CECBF5C98@oracle.com>
 <c927409e-815d-43bc-f558-25b1460eec1e@oracle.com>
 <4BF4AE94-F5AD-450C-AD53-879A9D8E3D5E@oracle.com>
 <41c56c1e-4404-944c-dba0-b9c937bd36b7@oracle.com>
 <AF9FEAFD-CA62-4B0D-BC98-3910A1186E4D@oracle.com>
Message-ID: <f21704bdfc5149e6add5c1d6e751e64c@sap.com>

Hi,

thanks for fixing this, I haven't seen the issue tonight any more.

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Paul Sandoz
> Sent: Dienstag, 3. Juli 2018 19:44
> To: Coleen Phillimore <coleen.phillimore at oracle.com>
> Cc: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> Subject: Re: [11] RFR jck test fails with C2:
> vm/jvmti/FollowReferences/fref001/fref00113/fref00113.html
> 
> 
> 
> > On Jul 3, 2018, at 10:25 AM, coleen.phillimore at oracle.com wrote:
> >
> >
> >
> > On 7/3/18 12:26 PM, Paul Sandoz wrote:
> >>
> >>> On Jul 2, 2018, at 11:43 AM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
> >>>
> >>> On 7/2/18 10:39 AM, Paul Sandoz wrote:
> >>>> Hi,
> >>>> Please review this fix for 11:
> >>>>   http://cr.openjdk.java.net/~psandoz/jdk/JDK-8202769-ci-stream-cp-
> tag/webrev/
> >>> Seems good to me. I will run testing with it.
> >>>
> >> Thanks, i see all relevant tests pass, so ok to push?
> >
> > You need two reviewers,
> 
> Ok.
> 
> 
> > and are you pushing this to JDK11 ?
> >
> 
> Yes.
> 
> 
> > The patch in the bug report seems better because you don't know that all
> of the callers want to convert JVM_CONSTANT_Dynamic to the underlying
> type that the Symbol points to.  The name of the ciStream function implies
> that it just returns tag_at().   I would assume that there would be other
> callers that want to do something with the actual tag, like print the bytecode
> stream for example.
> >
> 
> The patch in the bug report was a quick hack to get the test running by
> reverting what was pushed for constant dynamic support, but it will result in
> failures if it encounters a constant dynamic entry as the type of the dynamic
> constant is required and not JVM_CONSTANT_Dynamic.
> 
> The method ciBytecodeStream::get_constant_pool_tag is used for producing
> ldc instructions in what appears to be specialized cases, see the two usages in
> BCEscapeAnalyzer::iterate_one_block and Parse::do_one_bytecode.
> 
> We could rename it to Parse::get_constant_pool_tag_for_ldc ? if so would
> prefer to do that as a separate issue for 12 only.
> 
> Thanks,
> Paul.
> 
> > Coleen
> >
> >>
> >> Paul.
> >


From matthias.baesken at sap.com  Wed Jul  4 08:21:26 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 4 Jul 2018 08:21:26 +0000
Subject: RFR :  8206255 : fix
 compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java jtreg test on
 linux s390x
Message-ID: <b79c40bb7d784fd1aba17bf0f64b0eb4@sap.com>

Hello  , could you please review this small  fix  for SHA handling on  s390x.
It  does  the same we have already  on  aarch64  and  x86(-64)   -   in case of  all 3 flags   UseSHA1Intrinsics, UseSHA256Intrinsics, UseSHA512Intrinsics   set to false  we
 Set also  UseSHA to false .

The test   compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java    revealed  the difference on s390x .
The test  outputs :

java.lang.AssertionError: Option 'UseSHA' is expected to have 'false' value
'UseSHA' option should be disabled when all UseSHA*Intrinsics are disabled


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

http://cr.openjdk.java.net/~mbaesken/webrevs/8206255/


Thanks, Matthias



From thomas.stuefe at gmail.com  Wed Jul  4 10:51:19 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 4 Jul 2018 12:51:19 +0200
Subject: RFR : 8206255 : fix
 compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java
 jtreg test on linux s390x
In-Reply-To: <b79c40bb7d784fd1aba17bf0f64b0eb4@sap.com>
References: <b79c40bb7d784fd1aba17bf0f64b0eb4@sap.com>
Message-ID: <CAA-vtUyt-U+gXL9bqVTfxuKgR6SiT6QazbxQ4cK091+4aCh0xw@mail.gmail.com>

Looks good Matthias (and trivial)

..Thomas

On Wed, Jul 4, 2018 at 10:21 AM, Baesken, Matthias
<matthias.baesken at sap.com> wrote:
> Hello  , could you please review this small  fix  for SHA handling on  s390x.
> It  does  the same we have already  on  aarch64  and  x86(-64)   -   in case of  all 3 flags   UseSHA1Intrinsics, UseSHA256Intrinsics, UseSHA512Intrinsics   set to false  we
>  Set also  UseSHA to false .
>
> The test   compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java    revealed  the difference on s390x .
> The test  outputs :
>
> java.lang.AssertionError: Option 'UseSHA' is expected to have 'false' value
> 'UseSHA' option should be disabled when all UseSHA*Intrinsics are disabled
>
>
> https://bugs.openjdk.java.net/browse/JDK-8206255
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8206255/
>
>
> Thanks, Matthias
>
>

From matthias.baesken at sap.com  Wed Jul  4 11:19:35 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 4 Jul 2018 11:19:35 +0000
Subject: RFR : 8206255 : fix
 compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java jtreg test on
 linux s390x
In-Reply-To: <CAA-vtUyt-U+gXL9bqVTfxuKgR6SiT6QazbxQ4cK091+4aCh0xw@mail.gmail.com>
References: <b79c40bb7d784fd1aba17bf0f64b0eb4@sap.com>
 <CAA-vtUyt-U+gXL9bqVTfxuKgR6SiT6QazbxQ4cK091+4aCh0xw@mail.gmail.com>
Message-ID: <9e319c8317fd401ca71a525e115d9e33@sap.com>

Thanks Thomas ! Can I have a second review please ?

Btw can I  push this to jdk11  ?

Best regards, Matthias

> -----Original Message-----
> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> Sent: Mittwoch, 4. Juli 2018 12:51
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR : 8206255 : fix
> compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java jtreg
> test on linux s390x
> 
> Looks good Matthias (and trivial)
> 
> ..Thomas
> 
> On Wed, Jul 4, 2018 at 10:21 AM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
> > Hello  , could you please review this small  fix  for SHA handling on  s390x.
> > It  does  the same we have already  on  aarch64  and  x86(-64)   -   in case of
> all 3 flags   UseSHA1Intrinsics, UseSHA256Intrinsics, UseSHA512Intrinsics   set
> to false  we
> >  Set also  UseSHA to false .
> >
> > The test
> compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java
> revealed  the difference on s390x .
> > The test  outputs :
> >
> > java.lang.AssertionError: Option 'UseSHA' is expected to have 'false' value
> > 'UseSHA' option should be disabled when all UseSHA*Intrinsics are
> disabled
> >
> >
> > https://bugs.openjdk.java.net/browse/JDK-8206255
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8206255/
> >
> >
> > Thanks, Matthias
> >
> >

From matthias.baesken at sap.com  Wed Jul  4 14:44:52 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 4 Jul 2018 14:44:52 +0000
Subject: ResourceMarks when CompiledIC_at is used ?
Message-ID: <23b9d0beacf641998b007bf05295360b@sap.com>

Hello,   I recently looked at   8164293: HotSpot leaking memory in long-running requests

http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a

where a number of missing ResourceMarks were added .
I think some of those ResourceMarks were added  because of  CompiledIC_at  in the changed  functions .

I checked for  other CompiledIC_at    in the hs coding ,  and found some other places (see below) where  ResourceMarks  are missing as well.
Should they be added ?

Best regards, Matthias



src/hotspot/share/aot/aotCompiledMethod.cpp

void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
.....
274      } else if (iter.type() == relocInfo::virtual_call_type) {
275        // Check compiledIC holders associated with this nmethod
276        CompiledIC *ic = CompiledIC_at(&iter);    <------------------------------------


    and

441void AOTCompiledMethod::clear_inline_caches() {
442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's only allowed at safepoint");
443  if (is_zombie()) {
444    return;
445  }
446
447  RelocIterator iter(this);
448  while (iter.next()) {
449    iter.reloc()->clear_inline_cache();
450    if (iter.type() == relocInfo::opt_virtual_call_type) {
451      CompiledIC* cic = CompiledIC_at(&iter);    <------------------------------------
452      assert(cic->is_clean(), "!");
453      nativePltCall_at(iter.addr())->set_stub_to_clean();
454    }
455  }
456}

src/hotspot/share/code/compiledMethod.cpp

326void CompiledMethod::clear_ic_stubs() {
327  assert_locked_or_safepoint(CompiledIC_lock);
328  RelocIterator iter(this);
329  while(iter.next()) {
330    if (iter.type() == relocInfo::virtual_call_type) {
331      CompiledIC* ic = CompiledIC_at(&iter);      <------------------------------------
332      ic->clear_ic_stub();
333    }
334  }
335}


547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel, bool unloading_occurred, bool clean_all) {
548  assert_locked_or_safepoint(CompiledIC_lock);
549  bool postponed = false;
550
551  // Find all calls in an nmethod and clear the ones that point to non-entrant,
552  // zombie and unloaded nmethods.
553  RelocIterator iter(this, oops_reloc_begin());
554  while(iter.next()) {
555
556    switch (iter.type()) {
557
558    case relocInfo::virtual_call_type:
559      if (unloading_occurred) {
560        // If class unloading occurred we first clear ICs where the cached metadata
561        // is referring to an unloaded klass or method.
562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));        <------------------------------------

From vladimir.kozlov at oracle.com  Wed Jul  4 17:24:49 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 4 Jul 2018 10:24:49 -0700
Subject: RFR : 8206255 : fix
 compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java jtreg test on
 linux s390x
In-Reply-To: <9e319c8317fd401ca71a525e115d9e33@sap.com>
References: <b79c40bb7d784fd1aba17bf0f64b0eb4@sap.com>
 <CAA-vtUyt-U+gXL9bqVTfxuKgR6SiT6QazbxQ4cK091+4aCh0xw@mail.gmail.com>
 <9e319c8317fd401ca71a525e115d9e33@sap.com>
Message-ID: <9ad0b1f3-c4e8-e0b1-4e30-e3d93dfc84f5@oracle.com>

Looks good to me too.

Yes, you can still push into jdk11 any p1-3 bugs (not p4-5). And you 
don't need to push it into 12 (jdk/jdk) because it will be pooled from 
jdk11 automatically.

Thanks,
Vladimir

On 7/4/18 4:19 AM, Baesken, Matthias wrote:
> Thanks Thomas ! Can I have a second review please ?
> 
> Btw can I  push this to jdk11  ?
> 
> Best regards, Matthias
> 
>> -----Original Message-----
>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> Sent: Mittwoch, 4. Juli 2018 12:51
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR : 8206255 : fix
>> compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java jtreg
>> test on linux s390x
>>
>> Looks good Matthias (and trivial)
>>
>> ..Thomas
>>
>> On Wed, Jul 4, 2018 at 10:21 AM, Baesken, Matthias
>> <matthias.baesken at sap.com> wrote:
>>> Hello  , could you please review this small  fix  for SHA handling on  s390x.
>>> It  does  the same we have already  on  aarch64  and  x86(-64)   -   in case of
>> all 3 flags   UseSHA1Intrinsics, UseSHA256Intrinsics, UseSHA512Intrinsics   set
>> to false  we
>>>   Set also  UseSHA to false .
>>>
>>> The test
>> compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java
>> revealed  the difference on s390x .
>>> The test  outputs :
>>>
>>> java.lang.AssertionError: Option 'UseSHA' is expected to have 'false' value
>>> 'UseSHA' option should be disabled when all UseSHA*Intrinsics are
>> disabled
>>>
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8206255
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8206255/
>>>
>>>
>>> Thanks, Matthias
>>>
>>>

From vladimir.kozlov at oracle.com  Wed Jul  4 17:43:01 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 4 Jul 2018 10:43:01 -0700
Subject: ResourceMarks when CompiledIC_at is used ?
In-Reply-To: <23b9d0beacf641998b007bf05295360b@sap.com>
References: <23b9d0beacf641998b007bf05295360b@sap.com>
Message-ID: <784021d1-54e7-cf97-4f9e-342cbabf97ed@oracle.com>

Thank you, Matthias

Yes, I checked all these places and they have to be fixed. Please, file 
a bug for jdk11.

Vladimir

On 7/4/18 7:44 AM, Baesken, Matthias wrote:
> Hello,   I recently looked at   8164293: HotSpot leaking memory in long-running requests
> 
> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a
> 
> where a number of missing ResourceMarks were added .
> I think some of those ResourceMarks were added  because of  CompiledIC_at  in the changed  functions .
> 
> I checked for  other CompiledIC_at    in the hs coding ,  and found some other places (see below) where  ResourceMarks  are missing as well.
> Should they be added ?
> 
> Best regards, Matthias
> 
> 
> 
> src/hotspot/share/aot/aotCompiledMethod.cpp
> 
> void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
> .....
> 274      } else if (iter.type() == relocInfo::virtual_call_type) {
> 275        // Check compiledIC holders associated with this nmethod
> 276        CompiledIC *ic = CompiledIC_at(&iter);    <------------------------------------
> 
> 
>      and
> 
> 441void AOTCompiledMethod::clear_inline_caches() {
> 442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's only allowed at safepoint");
> 443  if (is_zombie()) {
> 444    return;
> 445  }
> 446
> 447  RelocIterator iter(this);
> 448  while (iter.next()) {
> 449    iter.reloc()->clear_inline_cache();
> 450    if (iter.type() == relocInfo::opt_virtual_call_type) {
> 451      CompiledIC* cic = CompiledIC_at(&iter);    <------------------------------------
> 452      assert(cic->is_clean(), "!");
> 453      nativePltCall_at(iter.addr())->set_stub_to_clean();
> 454    }
> 455  }
> 456}
> 
> src/hotspot/share/code/compiledMethod.cpp
> 
> 326void CompiledMethod::clear_ic_stubs() {
> 327  assert_locked_or_safepoint(CompiledIC_lock);
> 328  RelocIterator iter(this);
> 329  while(iter.next()) {
> 330    if (iter.type() == relocInfo::virtual_call_type) {
> 331      CompiledIC* ic = CompiledIC_at(&iter);      <------------------------------------
> 332      ic->clear_ic_stub();
> 333    }
> 334  }
> 335}
> 
> 
> 547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel, bool unloading_occurred, bool clean_all) {
> 548  assert_locked_or_safepoint(CompiledIC_lock);
> 549  bool postponed = false;
> 550
> 551  // Find all calls in an nmethod and clear the ones that point to non-entrant,
> 552  // zombie and unloaded nmethods.
> 553  RelocIterator iter(this, oops_reloc_begin());
> 554  while(iter.next()) {
> 555
> 556    switch (iter.type()) {
> 557
> 558    case relocInfo::virtual_call_type:
> 559      if (unloading_occurred) {
> 560        // If class unloading occurred we first clear ICs where the cached metadata
> 561        // is referring to an unloaded klass or method.
> 562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));        <------------------------------------
> 

From gnu.andrew at redhat.com  Thu Jul  5 02:08:05 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 5 Jul 2018 03:08:05 +0100
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
Message-ID: <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>

On 26 June 2018 at 18:39, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> On 21 June 2018 at 04:56, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>> [CCing hotspot list for review]
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179887
>> Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8179887/webrev.01/
>> Review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031746.html
>>
>> Patch is basically the same as for OpenJDK 11, except we don't have to
>> revert 8187667, which isn't present in OpenJDK 8.
>>
>> Thanks,
>> --
>> Andrew :)
>>
>> Senior Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Web Site: http://fuseyism.com
>> Twitter: https://twitter.com/gnu_andrew_java
>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>
> Ping?
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Web Site: http://fuseyism.com
> Twitter: https://twitter.com/gnu_andrew_java
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Ping x 2?
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From david.holmes at oracle.com  Thu Jul  5 04:03:02 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jul 2018 14:03:02 +1000
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
Message-ID: <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>

Hi Andrew,

As far as I can see this got quite messy. We initially disabled the 
warning to fix the build problem. Then we actually changed the code in 
8179887. But that broke JFR's use of the API:

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

and that and:

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

remain open and unresolved.

I'd be inclined to disable the build warning for 8u rather than make 
code changes (which will likely still break JFR).

David

On 5/07/2018 12:08 PM, Andrew Hughes wrote:
> On 26 June 2018 at 18:39, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>> On 21 June 2018 at 04:56, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>> [CCing hotspot list for review]
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179887
>>> Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8179887/webrev.01/
>>> Review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031746.html
>>>
>>> Patch is basically the same as for OpenJDK 11, except we don't have to
>>> revert 8187667, which isn't present in OpenJDK 8.
>>>
>>> Thanks,
>>> --
>>> Andrew :)
>>>
>>> Senior Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>>
>>> Web Site: http://fuseyism.com
>>> Twitter: https://twitter.com/gnu_andrew_java
>>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>
>> Ping?
>> --
>> Andrew :)
>>
>> Senior Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Web Site: http://fuseyism.com
>> Twitter: https://twitter.com/gnu_andrew_java
>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> 
> Ping x 2?
> 

From felix.yang at oracle.com  Thu Jul  5 05:09:37 2018
From: felix.yang at oracle.com (Felix Yang)
Date: Thu, 5 Jul 2018 13:09:37 +0800
Subject: RFR 8206378/11, Backout JDK-8202561
Message-ID: <f9d5625c-8fc4-85f9-eb12-0219341af905@oracle.com>

Hi all,

 ??? please review the patch to backout JDK-8202561, which breaks JDK CI.

Original issue:

 ??? https://bugs.openjdk.java.net/browse/JDK-8202561

Backout request:

 ??? https://bugs.openjdk.java.net/browse/JDK-8206378

Webrev:

 ??? http://cr.openjdk.java.net/~xiaofeya/8206378/webrev.00/

Thanks,

Felix




From david.holmes at oracle.com  Thu Jul  5 05:16:07 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jul 2018 15:16:07 +1000
Subject: RFR 8206378/11, Backout JDK-8202561
In-Reply-To: <f9d5625c-8fc4-85f9-eb12-0219341af905@oracle.com>
References: <f9d5625c-8fc4-85f9-eb12-0219341af905@oracle.com>
Message-ID: <263d567f-1e3c-8410-fefb-6b1a24ad93ad@oracle.com>

Looks good.

Thanks for fixing this.

David

On 5/07/2018 3:09 PM, Felix Yang wrote:
> Hi all,
> 
>  ??? please review the patch to backout JDK-8202561, which breaks JDK CI.
> 
> Original issue:
> 
>  ??? https://bugs.openjdk.java.net/browse/JDK-8202561
> 
> Backout request:
> 
>  ??? https://bugs.openjdk.java.net/browse/JDK-8206378
> 
> Webrev:
> 
>  ??? http://cr.openjdk.java.net/~xiaofeya/8206378/webrev.00/
> 
> Thanks,
> 
> Felix
> 
> 
> 

From kevin.walls at oracle.com  Thu Jul  5 08:46:09 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 5 Jul 2018 09:46:09 +0100
Subject: RFR: 8205677: [8u] casts and type change for 8u to enable later
 Windows compilers
Message-ID: <10a72c45-c34a-599a-b771-08d5a7083c62@oracle.com>

Hi,

I'd like to get a review of:

8205677: [8u] casts and type change for 8u to enable later Windows compilers
https://bugs.openjdk.java.net/browse/JDK-8205677

This is a collection of new small changes aiming to permit 8u to build 
with later Windows compilers (and also with the current VS2010).

The changes are:

8u webrev: http://cr.openjdk.java.net/~kevinw/8205677/webrev.00/

Notes:

1
hotspot\src\share\vm\classfile\altHashing.cpp(227): warning C4838: 
conversion from 'unsigned int' to 'const jint' requires a narrowing 
conversion

(jint) casts are present in the later JDK 
test/hotspot/gtest/classfile/test_AltHashing.cpp and look like they were 
in JDK9 from the start.

2
hotspot\src\share\vm\gc_implementation\parallelScavenge\gcTaskManager.cpp(1038): 
warning C4312: 'type cast': conversion from 'unsigned int' to 'Monitor 
*' of greater size

-? _monitor = (Monitor*) 0xDEAD000F;
+? _monitor = (Monitor*) (uintptr_t) 0xDEAD000F;

3
..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): error C2440: '=': 
cannot convert from 'jlong' to 'jlong *'
..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): note: Conversion 
from integral type to pointer type requires reinterpret_cast, C-style 
cast or function-style cast

-??? *long_at_addr(which) = (long)contents;
+??? *long_at_addr(which) = (jlong)contents;


4
...\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepGeneration.cpp(6833): 
warning C4334: '<<': result of 32-bit shift implicitly converted to 64 
bits (was 64-bit shift intended?)

Like in 8197864 where we cast a 1 to an intptr_t before the shift.

 ?? assert(mr.end() == (HeapWord*)round_to((intptr_t)mr.end(),
-??????????????????????? (1 << (_shifter+LogHeapWordSize))),
+??????????????????????? ((intptr_t) 1 << (_shifter+LogHeapWordSize))),


5
hotspot\src\share\vm\runtime\memprofiler.cpp(129): warning C4477: 
'fprintf' : format string '%6ld' requires an argument of type 'long', 
but variadic argument 3 has type '::size_t'

OopMapCache::memory_size() is only used in one place, and only when 
NOTPRODUCT.? Here in 8u, we can make it return a size_t and compile 
without error.

In jdk10 onwards, after 8186042, this line in memprofiler.cpp hard-codes 
a 0L instead of OopMapCache::memory_size(), as the tracking of 
_total_memory_size was removed, but the print was kept to the same 
format.? I don't think we would remove that statistic in an update


Thanks
Kevin








From matthias.baesken at sap.com  Thu Jul  5 09:14:50 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 5 Jul 2018 09:14:50 +0000
Subject: RFR JDK-8206394 :  ResourceMark in AOTCompiledMethod::metadata_do,
 AOTCompiledMethod::clear_inline_caches , CompiledMethod::clear_ic_stubs ,
 CompiledMethod::cleanup_inline_caches_impl - was :  RE: ResourceMarks when
 CompiledIC_at is used ?
Message-ID: <74d4f74ddb934d33a712887edd606d24@sap.com>

Hi Vladimir, thanks for looking into it !

Please review :

http://cr.openjdk.java.net/~mbaesken/webrevs/8206394/


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


Best regards, Matthias



> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Mittwoch, 4. Juli 2018 19:43
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: ResourceMarks when CompiledIC_at is used ?
> 
> Thank you, Matthias
> 
> Yes, I checked all these places and they have to be fixed. Please, file
> a bug for jdk11.
> 
> Vladimir
> 
> On 7/4/18 7:44 AM, Baesken, Matthias wrote:
> > Hello,   I recently looked at   8164293: HotSpot leaking memory in long-
> running requests
> >
> > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a
> >
> > where a number of missing ResourceMarks were added .
> > I think some of those ResourceMarks were added  because of
> CompiledIC_at  in the changed  functions .
> >
> > I checked for  other CompiledIC_at    in the hs coding ,  and found some
> other places (see below) where  ResourceMarks  are missing as well.
> > Should they be added ?
> >
> > Best regards, Matthias
> >
> >
> >
> > src/hotspot/share/aot/aotCompiledMethod.cpp
> >
> > void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
> > .....
> > 274      } else if (iter.type() == relocInfo::virtual_call_type) {
> > 275        // Check compiledIC holders associated with this nmethod
> > 276        CompiledIC *ic = CompiledIC_at(&iter);    <-------------------------------
> -----
> >
> >
> >      and
> >
> > 441void AOTCompiledMethod::clear_inline_caches() {
> > 442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's only
> allowed at safepoint");
> > 443  if (is_zombie()) {
> > 444    return;
> > 445  }
> > 446
> > 447  RelocIterator iter(this);
> > 448  while (iter.next()) {
> > 449    iter.reloc()->clear_inline_cache();
> > 450    if (iter.type() == relocInfo::opt_virtual_call_type) {
> > 451      CompiledIC* cic = CompiledIC_at(&iter);    <-------------------------------
> -----
> > 452      assert(cic->is_clean(), "!");
> > 453      nativePltCall_at(iter.addr())->set_stub_to_clean();
> > 454    }
> > 455  }
> > 456}
> >
> > src/hotspot/share/code/compiledMethod.cpp
> >
> > 326void CompiledMethod::clear_ic_stubs() {
> > 327  assert_locked_or_safepoint(CompiledIC_lock);
> > 328  RelocIterator iter(this);
> > 329  while(iter.next()) {
> > 330    if (iter.type() == relocInfo::virtual_call_type) {
> > 331      CompiledIC* ic = CompiledIC_at(&iter);      <-------------------------------
> -----
> > 332      ic->clear_ic_stub();
> > 333    }
> > 334  }
> > 335}
> >
> >
> > 547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel, bool
> unloading_occurred, bool clean_all) {
> > 548  assert_locked_or_safepoint(CompiledIC_lock);
> > 549  bool postponed = false;
> > 550
> > 551  // Find all calls in an nmethod and clear the ones that point to non-
> entrant,
> > 552  // zombie and unloaded nmethods.
> > 553  RelocIterator iter(this, oops_reloc_begin());
> > 554  while(iter.next()) {
> > 555
> > 556    switch (iter.type()) {
> > 557
> > 558    case relocInfo::virtual_call_type:
> > 559      if (unloading_occurred) {
> > 560        // If class unloading occurred we first clear ICs where the cached
> metadata
> > 561        // is referring to an unloaded klass or method.
> > 562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));        <---------
> ---------------------------
> >

From harold.seigel at oracle.com  Thu Jul  5 14:06:39 2018
From: harold.seigel at oracle.com (Harold David Seigel)
Date: Thu, 5 Jul 2018 10:06:39 -0400
Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
 include module and class loader information
In-Reply-To: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
References: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
Message-ID: <f5667bfb-4139-ba72-ef57-4ff014da0ce6@oracle.com>

Hi Lois,

This change looks good!

Can you fix the indentation at lines 523 - 525 and 1262 - 1264 in 
klassVtable.cpp?? No need for a new webrev.

Thanks, Harold


On 6/27/2018 9:20 AM, Lois Foltan wrote:
> Please review this change to migrate existing loader constraint 
> LinkageErrors to the new error message format proposal.? The actual 
> wording of the loader constraint messages has not changed. Module and 
> class loader information have been moved into the error message's 
> REASON section.? This change also removes the method 
> java_lang_ClassLoader::describe_external() in favor of 
> Klass::class_in_module_of_loader().
>
> open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611/webrev/
> bug link https://bugs.openjdk.java.net/browse/JDK-8205611
>
> JDK-8166633 outlines a new proposal where error messages follow a 
> format of ERRROR: PROBLEM (REASON) where the PROBLEM is aggressively 
> simple (and definitely avoids arbitrary-length loader names) so the 
> REASON bears all the cost of explaining the PROBLEM with more 
> specifics.? See the proposal in more detail at 
> https://bugs.openjdk.java.net/browse/JDK-8166633. The new utility 
> method Klass::class_in_module_of_loader() implements the proposed format.
>
> Some example text:
>
> (JDK 11) 'DuplicateLE_Test_Loader_IF' @<id> (instance of 
> PreemptingClassLoader, child of 'app' 
> jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate 
> interface definition for test.J.
> to
> (JDK 12) loader 'DuplicateLE_Test_Loader_IF' @6eeee674 attempted 
> duplicate interface definition for test.J. (test.J is in unnamed 
> module of loader 'DuplicateLE_Test_Loader_IF' @6eeee674, parent loader 
> 'app')
>
>
> (JDK 11) loader constraint violation: loader PreemptingClassLoader 
> @<id> (instance of PreemptingClassLoader, child of 'app' 
> jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load class 
> test.D_ambgs. A different class with the same name was previously 
> loaded by 'app' (instance of 
> jdk.internal.loader.ClassLoaders$AppClassLoader).
> to
> (JDK 12) loader constraint violation: loader PreemptingClassLoader 
> @5bc79a1c wants to load class test.D_ambgs. A different class with the 
> same name was previously loaded by 'app'. (test.D_ambgs is in unnamed 
> module of loader 'app')
>
>
> (JDK 11) loader constraint violation for class test.Task: when 
> selecting overriding method test.Task.m()Ltest/Foo; the class loader 
> PreemptingClassLoader @<id> (instance of PreemptingClassLoader, child 
> of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) of the 
> selected method's type test.Task, and the class loader 'app' (instance 
> of jdk.internal.loader.ClassLoaders$AppClassLoader) for its super type 
> test.J have different Class objects for the type test.Foo used in the 
> signature
> to
> (JDK 12) loader constraint violation for class test.Task: when 
> selecting overriding method test.Task.m()Ltest/Foo; the class loader 
> PreemptingClassLoader @7884e077 of the selected method's type 
> test.Task, and the class loader 'app' for its super type test.J have 
> different Class objects for the type test.Foo used in the signature 
> (test.Task is in unnamed module of loader PreemptingClassLoader 
> @7884e077, parent loader 'app'; test.J is in unnamed module of loader 
> 'app')
>
>
> Testing: hs-tier(1-3), jdk-tier(1-3) complete
> ?????????????? hs-tier(4,5) in progress
> ?????????????? JCK vm, lang in progress
>
> Thanks,
> Lois


From vladimir.kozlov at oracle.com  Thu Jul  5 16:06:56 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 5 Jul 2018 09:06:56 -0700
Subject: RFR JDK-8206394 : ResourceMark in AOTCompiledMethod::metadata_do, 
 AOTCompiledMethod::clear_inline_caches ,
 CompiledMethod::clear_ic_stubs , 
 CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks when
 CompiledIC_at is used ?
In-Reply-To: <74d4f74ddb934d33a712887edd606d24@sap.com>
References: <74d4f74ddb934d33a712887edd606d24@sap.com>
Message-ID: <284b43ad-bec2-f479-7068-84945e4c89d0@oracle.com>

Looks good. I will test it and push if it passed.

Thanks,
Vladimir

On 7/5/18 2:14 AM, Baesken, Matthias wrote:
> Hi Vladimir, thanks for looking into it !
> 
> Please review :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8206394/
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8206394
> 
> 
> Best regards, Matthias
> 
> 
> 
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Mittwoch, 4. Juli 2018 19:43
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: ResourceMarks when CompiledIC_at is used ?
>>
>> Thank you, Matthias
>>
>> Yes, I checked all these places and they have to be fixed. Please, file
>> a bug for jdk11.
>>
>> Vladimir
>>
>> On 7/4/18 7:44 AM, Baesken, Matthias wrote:
>>> Hello,   I recently looked at   8164293: HotSpot leaking memory in long-
>> running requests
>>>
>>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a
>>>
>>> where a number of missing ResourceMarks were added .
>>> I think some of those ResourceMarks were added  because of
>> CompiledIC_at  in the changed  functions .
>>>
>>> I checked for  other CompiledIC_at    in the hs coding ,  and found some
>> other places (see below) where  ResourceMarks  are missing as well.
>>> Should they be added ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>> src/hotspot/share/aot/aotCompiledMethod.cpp
>>>
>>> void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
>>> .....
>>> 274      } else if (iter.type() == relocInfo::virtual_call_type) {
>>> 275        // Check compiledIC holders associated with this nmethod
>>> 276        CompiledIC *ic = CompiledIC_at(&iter);    <-------------------------------
>> -----
>>>
>>>
>>>       and
>>>
>>> 441void AOTCompiledMethod::clear_inline_caches() {
>>> 442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's only
>> allowed at safepoint");
>>> 443  if (is_zombie()) {
>>> 444    return;
>>> 445  }
>>> 446
>>> 447  RelocIterator iter(this);
>>> 448  while (iter.next()) {
>>> 449    iter.reloc()->clear_inline_cache();
>>> 450    if (iter.type() == relocInfo::opt_virtual_call_type) {
>>> 451      CompiledIC* cic = CompiledIC_at(&iter);    <-------------------------------
>> -----
>>> 452      assert(cic->is_clean(), "!");
>>> 453      nativePltCall_at(iter.addr())->set_stub_to_clean();
>>> 454    }
>>> 455  }
>>> 456}
>>>
>>> src/hotspot/share/code/compiledMethod.cpp
>>>
>>> 326void CompiledMethod::clear_ic_stubs() {
>>> 327  assert_locked_or_safepoint(CompiledIC_lock);
>>> 328  RelocIterator iter(this);
>>> 329  while(iter.next()) {
>>> 330    if (iter.type() == relocInfo::virtual_call_type) {
>>> 331      CompiledIC* ic = CompiledIC_at(&iter);      <-------------------------------
>> -----
>>> 332      ic->clear_ic_stub();
>>> 333    }
>>> 334  }
>>> 335}
>>>
>>>
>>> 547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel, bool
>> unloading_occurred, bool clean_all) {
>>> 548  assert_locked_or_safepoint(CompiledIC_lock);
>>> 549  bool postponed = false;
>>> 550
>>> 551  // Find all calls in an nmethod and clear the ones that point to non-
>> entrant,
>>> 552  // zombie and unloaded nmethods.
>>> 553  RelocIterator iter(this, oops_reloc_begin());
>>> 554  while(iter.next()) {
>>> 555
>>> 556    switch (iter.type()) {
>>> 557
>>> 558    case relocInfo::virtual_call_type:
>>> 559      if (unloading_occurred) {
>>> 560        // If class unloading occurred we first clear ICs where the cached
>> metadata
>>> 561        // is referring to an unloaded klass or method.
>>> 562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));        <---------
>> ---------------------------
>>>

From matthias.baesken at sap.com  Thu Jul  5 16:18:06 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 5 Jul 2018 16:18:06 +0000
Subject: RFR JDK-8206394 : ResourceMark in AOTCompiledMethod::metadata_do, 
 AOTCompiledMethod::clear_inline_caches ,
 CompiledMethod::clear_ic_stubs , 
 CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks when
 CompiledIC_at is used ?
In-Reply-To: <284b43ad-bec2-f479-7068-84945e4c89d0@oracle.com>
References: <74d4f74ddb934d33a712887edd606d24@sap.com>
 <284b43ad-bec2-f479-7068-84945e4c89d0@oracle.com>
Message-ID: <31df82f18d7b4b6bbf514676dfdf171e@sap.com>

Great , thanks for your help !


Btw.  while looking a bit more at the  ResourceMark usages  , I found  that the    name_and_sig_as_C_string()   calls  are mostly
   in the codebase with a  related ResourceMark .

However it is not done always,  for example ;   do you think it is missing at these places or not needed?


hotspot/share/classfile/verifier.cpp#626

623void ClassVerifier::verify_method(const methodHandle& m, TRAPS) {
624  HandleMark hm(THREAD);
625  _method = m;   // initialize _method
626  log_info(verification)("Verifying method %s", m->name_and_sig_as_C_string());


hotspot/share/classfile/classLoader.cpp#2045

void ClassLoader::compile_the_world_in(char* name, Handle loader, TRAPS) {

2058                if (HAS_PENDING_EXCEPTION) {
2059                  clear_pending_exception_if_not_oom(CHECK);
2060                  tty->print_cr("CompileTheWorld (%d) : Skipping method: %s", _compile_the_world_class_counter, m->name_and_sig_as_C_string());
2061                } else {
2062                  _compile_the_world_method_counter++;
2063                }
2064              }
2065            } else {
2066              tty->print_cr("CompileTheWorld (%d) : Skipping method: %s", _compile_the_world_class_counter, m->name_and_sig_as_C_string());
2067            }

Best regards, Matthias



> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Donnerstag, 5. Juli 2018 18:07
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR JDK-8206394 : ResourceMark in
> AOTCompiledMethod::metadata_do,
> AOTCompiledMethod::clear_inline_caches ,
> CompiledMethod::clear_ic_stubs ,
> CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks
> when CompiledIC_at is used ?
> 
> Looks good. I will test it and push if it passed.
> 
> Thanks,
> Vladimir
> 
> On 7/5/18 2:14 AM, Baesken, Matthias wrote:
> > Hi Vladimir, thanks for looking into it !
> >
> > Please review :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8206394/
> >
> >
> > https://bugs.openjdk.java.net/browse/JDK-8206394
> >
> >
> > Best regards, Matthias
> >
> >
> >
> >> -----Original Message-----
> >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> >> Sent: Mittwoch, 4. Juli 2018 19:43
> >> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> >> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> >> Subject: Re: ResourceMarks when CompiledIC_at is used ?
> >>
> >> Thank you, Matthias
> >>
> >> Yes, I checked all these places and they have to be fixed. Please, file
> >> a bug for jdk11.
> >>
> >> Vladimir
> >>
> >> On 7/4/18 7:44 AM, Baesken, Matthias wrote:
> >>> Hello,   I recently looked at   8164293: HotSpot leaking memory in long-
> >> running requests
> >>>
> >>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a
> >>>
> >>> where a number of missing ResourceMarks were added .
> >>> I think some of those ResourceMarks were added  because of
> >> CompiledIC_at  in the changed  functions .
> >>>
> >>> I checked for  other CompiledIC_at    in the hs coding ,  and found some
> >> other places (see below) where  ResourceMarks  are missing as well.
> >>> Should they be added ?
> >>>
> >>> Best regards, Matthias
> >>>
> >>>
> >>>
> >>> src/hotspot/share/aot/aotCompiledMethod.cpp
> >>>
> >>> void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
> >>> .....
> >>> 274      } else if (iter.type() == relocInfo::virtual_call_type) {
> >>> 275        // Check compiledIC holders associated with this nmethod
> >>> 276        CompiledIC *ic = CompiledIC_at(&iter);    <---------------------------
> ----
> >> -----
> >>>
> >>>
> >>>       and
> >>>
> >>> 441void AOTCompiledMethod::clear_inline_caches() {
> >>> 442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's
> only
> >> allowed at safepoint");
> >>> 443  if (is_zombie()) {
> >>> 444    return;
> >>> 445  }
> >>> 446
> >>> 447  RelocIterator iter(this);
> >>> 448  while (iter.next()) {
> >>> 449    iter.reloc()->clear_inline_cache();
> >>> 450    if (iter.type() == relocInfo::opt_virtual_call_type) {
> >>> 451      CompiledIC* cic = CompiledIC_at(&iter);    <---------------------------
> ----
> >> -----
> >>> 452      assert(cic->is_clean(), "!");
> >>> 453      nativePltCall_at(iter.addr())->set_stub_to_clean();
> >>> 454    }
> >>> 455  }
> >>> 456}
> >>>
> >>> src/hotspot/share/code/compiledMethod.cpp
> >>>
> >>> 326void CompiledMethod::clear_ic_stubs() {
> >>> 327  assert_locked_or_safepoint(CompiledIC_lock);
> >>> 328  RelocIterator iter(this);
> >>> 329  while(iter.next()) {
> >>> 330    if (iter.type() == relocInfo::virtual_call_type) {
> >>> 331      CompiledIC* ic = CompiledIC_at(&iter);      <---------------------------
> ----
> >> -----
> >>> 332      ic->clear_ic_stub();
> >>> 333    }
> >>> 334  }
> >>> 335}
> >>>
> >>>
> >>> 547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel,
> bool
> >> unloading_occurred, bool clean_all) {
> >>> 548  assert_locked_or_safepoint(CompiledIC_lock);
> >>> 549  bool postponed = false;
> >>> 550
> >>> 551  // Find all calls in an nmethod and clear the ones that point to non-
> >> entrant,
> >>> 552  // zombie and unloaded nmethods.
> >>> 553  RelocIterator iter(this, oops_reloc_begin());
> >>> 554  while(iter.next()) {
> >>> 555
> >>> 556    switch (iter.type()) {
> >>> 557
> >>> 558    case relocInfo::virtual_call_type:
> >>> 559      if (unloading_occurred) {
> >>> 560        // If class unloading occurred we first clear ICs where the cached
> >> metadata
> >>> 561        // is referring to an unloaded klass or method.
> >>> 562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));        <------
> ---
> >> ---------------------------
> >>>

From vladimir.kozlov at oracle.com  Thu Jul  5 16:32:38 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 5 Jul 2018 09:32:38 -0700
Subject: RFR JDK-8206394 : ResourceMark in AOTCompiledMethod::metadata_do, 
 AOTCompiledMethod::clear_inline_caches ,
 CompiledMethod::clear_ic_stubs , 
 CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks when
 CompiledIC_at is used ?
In-Reply-To: <31df82f18d7b4b6bbf514676dfdf171e@sap.com>
References: <74d4f74ddb934d33a712887edd606d24@sap.com>
 <284b43ad-bec2-f479-7068-84945e4c89d0@oracle.com>
 <31df82f18d7b4b6bbf514676dfdf171e@sap.com>
Message-ID: <5c7f604c-289a-f587-6db8-6ec4801cd9ba@oracle.com>

These are much less the issue but would be nice to fix them too.

Code in verify_method() only used when logging for class verification is 
switched on.

compile_the_world_in() is used only for testing - never in production.

I think it is P4 and we can fix them in jdk 12. But may be runtime group 
have other opinion about verify_method().

File bug on hotspot/runtime and see what other say.

Thanks,
Vladimir

On 7/5/18 9:18 AM, Baesken, Matthias wrote:
> Great , thanks for your help !
> 
> 
> Btw.  while looking a bit more at the  ResourceMark usages  , I found  that the    name_and_sig_as_C_string()   calls  are mostly
>     in the codebase with a  related ResourceMark .
> 
> However it is not done always,  for example ;   do you think it is missing at these places or not needed?
> 
> 
> hotspot/share/classfile/verifier.cpp#626
> 
> 623void ClassVerifier::verify_method(const methodHandle& m, TRAPS) {
> 624  HandleMark hm(THREAD);
> 625  _method = m;   // initialize _method
> 626  log_info(verification)("Verifying method %s", m->name_and_sig_as_C_string());
> 
> 
> hotspot/share/classfile/classLoader.cpp#2045
> 
> void ClassLoader::compile_the_world_in(char* name, Handle loader, TRAPS) {
> 
> 2058                if (HAS_PENDING_EXCEPTION) {
> 2059                  clear_pending_exception_if_not_oom(CHECK);
> 2060                  tty->print_cr("CompileTheWorld (%d) : Skipping method: %s", _compile_the_world_class_counter, m->name_and_sig_as_C_string());
> 2061                } else {
> 2062                  _compile_the_world_method_counter++;
> 2063                }
> 2064              }
> 2065            } else {
> 2066              tty->print_cr("CompileTheWorld (%d) : Skipping method: %s", _compile_the_world_class_counter, m->name_and_sig_as_C_string());
> 2067            }
> 
> Best regards, Matthias
> 
> 
> 
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Donnerstag, 5. Juli 2018 18:07
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: RFR JDK-8206394 : ResourceMark in
>> AOTCompiledMethod::metadata_do,
>> AOTCompiledMethod::clear_inline_caches ,
>> CompiledMethod::clear_ic_stubs ,
>> CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks
>> when CompiledIC_at is used ?
>>
>> Looks good. I will test it and push if it passed.
>>
>> Thanks,
>> Vladimir
>>
>> On 7/5/18 2:14 AM, Baesken, Matthias wrote:
>>> Hi Vladimir, thanks for looking into it !
>>>
>>> Please review :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8206394/
>>>
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8206394
>>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Mittwoch, 4. Juli 2018 19:43
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>> Subject: Re: ResourceMarks when CompiledIC_at is used ?
>>>>
>>>> Thank you, Matthias
>>>>
>>>> Yes, I checked all these places and they have to be fixed. Please, file
>>>> a bug for jdk11.
>>>>
>>>> Vladimir
>>>>
>>>> On 7/4/18 7:44 AM, Baesken, Matthias wrote:
>>>>> Hello,   I recently looked at   8164293: HotSpot leaking memory in long-
>>>> running requests
>>>>>
>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a
>>>>>
>>>>> where a number of missing ResourceMarks were added .
>>>>> I think some of those ResourceMarks were added  because of
>>>> CompiledIC_at  in the changed  functions .
>>>>>
>>>>> I checked for  other CompiledIC_at    in the hs coding ,  and found some
>>>> other places (see below) where  ResourceMarks  are missing as well.
>>>>> Should they be added ?
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>
>>>>> src/hotspot/share/aot/aotCompiledMethod.cpp
>>>>>
>>>>> void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
>>>>> .....
>>>>> 274      } else if (iter.type() == relocInfo::virtual_call_type) {
>>>>> 275        // Check compiledIC holders associated with this nmethod
>>>>> 276        CompiledIC *ic = CompiledIC_at(&iter);    <---------------------------
>> ----
>>>> -----
>>>>>
>>>>>
>>>>>        and
>>>>>
>>>>> 441void AOTCompiledMethod::clear_inline_caches() {
>>>>> 442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's
>> only
>>>> allowed at safepoint");
>>>>> 443  if (is_zombie()) {
>>>>> 444    return;
>>>>> 445  }
>>>>> 446
>>>>> 447  RelocIterator iter(this);
>>>>> 448  while (iter.next()) {
>>>>> 449    iter.reloc()->clear_inline_cache();
>>>>> 450    if (iter.type() == relocInfo::opt_virtual_call_type) {
>>>>> 451      CompiledIC* cic = CompiledIC_at(&iter);    <---------------------------
>> ----
>>>> -----
>>>>> 452      assert(cic->is_clean(), "!");
>>>>> 453      nativePltCall_at(iter.addr())->set_stub_to_clean();
>>>>> 454    }
>>>>> 455  }
>>>>> 456}
>>>>>
>>>>> src/hotspot/share/code/compiledMethod.cpp
>>>>>
>>>>> 326void CompiledMethod::clear_ic_stubs() {
>>>>> 327  assert_locked_or_safepoint(CompiledIC_lock);
>>>>> 328  RelocIterator iter(this);
>>>>> 329  while(iter.next()) {
>>>>> 330    if (iter.type() == relocInfo::virtual_call_type) {
>>>>> 331      CompiledIC* ic = CompiledIC_at(&iter);      <---------------------------
>> ----
>>>> -----
>>>>> 332      ic->clear_ic_stub();
>>>>> 333    }
>>>>> 334  }
>>>>> 335}
>>>>>
>>>>>
>>>>> 547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel,
>> bool
>>>> unloading_occurred, bool clean_all) {
>>>>> 548  assert_locked_or_safepoint(CompiledIC_lock);
>>>>> 549  bool postponed = false;
>>>>> 550
>>>>> 551  // Find all calls in an nmethod and clear the ones that point to non-
>>>> entrant,
>>>>> 552  // zombie and unloaded nmethods.
>>>>> 553  RelocIterator iter(this, oops_reloc_begin());
>>>>> 554  while(iter.next()) {
>>>>> 555
>>>>> 556    switch (iter.type()) {
>>>>> 557
>>>>> 558    case relocInfo::virtual_call_type:
>>>>> 559      if (unloading_occurred) {
>>>>> 560        // If class unloading occurred we first clear ICs where the cached
>>>> metadata
>>>>> 561        // is referring to an unloaded klass or method.
>>>>> 562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));        <------
>> ---
>>>> ---------------------------
>>>>>

From bsrbnd at gmail.com  Thu Jul  5 16:39:30 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Thu, 5 Jul 2018 18:39:30 +0200
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
Message-ID: <CAEgw74Dgd9ssTp0u2h6iaL_PTLWzuoqOoBpfVFqGW=t6UM=PpQ@mail.gmail.com>

[please forward to jdk8u-dev if necessary]

Hi David and Andrew,

On 5 July 2018 at 06:03, David Holmes <david.holmes at oracle.com> wrote:
> Hi Andrew,
>
> As far as I can see this got quite messy. We initially disabled the warning
> to fix the build problem. Then we actually changed the code in 8179887. But
> that broke JFR's use of the API:
>
> https://bugs.openjdk.java.net/browse/JDK-8202835

Note that I provided a fix for this which would need a review:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032445.html

It only concerns Linux and tier1 is OK.

> and that and:
>
> https://bugs.openjdk.java.net/browse/JDK-8202794
>
> remain open and unresolved.

This one has been updated and tested on Linux, MacOS and Solaris by
Alan and is quite ready to be pushed if someone could also test it on
AIX:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-June/054180.html

Thanks,
Bernard


> I'd be inclined to disable the build warning for 8u rather than make code
> changes (which will likely still break JFR).
>
> David
>
>
> On 5/07/2018 12:08 PM, Andrew Hughes wrote:
>>
>> On 26 June 2018 at 18:39, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>
>>> On 21 June 2018 at 04:56, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>>
>>>> [CCing hotspot list for review]
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179887
>>>> Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8179887/webrev.01/
>>>> Review thread:
>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031746.html
>>>>
>>>> Patch is basically the same as for OpenJDK 11, except we don't have to
>>>> revert 8187667, which isn't present in OpenJDK 8.
>>>>
>>>> Thanks,
>>>> --
>>>> Andrew :)
>>>>
>>>> Senior Free Java Software Engineer
>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>
>>>> Web Site: http://fuseyism.com
>>>> Twitter: https://twitter.com/gnu_andrew_java
>>>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>>>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>>
>>>
>>> Ping?
>>> --
>>> Andrew :)
>>>
>>> Senior Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>>
>>> Web Site: http://fuseyism.com
>>> Twitter: https://twitter.com/gnu_andrew_java
>>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>
>>
>> Ping x 2?
>>
>

From sgehwolf at redhat.com  Thu Jul  5 16:41:11 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 05 Jul 2018 18:41:11 +0200
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally
 when no debuginfo is stripped
Message-ID: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>

Hi,

Please review this 8u-only change. JDK 10+ are not affected.

For JDK 8 builds which don't perform any debug info stripping no
.gnu_debuglink sections should get generated. The fix is to move the
objcopy --add-gnu-debuglink calls into branches which actually perform
some stripping: all_strip, min_strip. Thoughts?

Bug: https://bugs.openjdk.java.net/browse/JDK-8206425
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206425/webrev.01/

Testing: Manually produced a build with no stripping and verified no
.gnu_debuglink sections got generated.

$ for i in $(find build/linux-x86_64-normal-server-release/images/j2sdk-image/ \
 | grep -E 'libjvm.so|libsaproc.so|libjsig.so'); do echo $i
 readelf --sections $i | grep gnu_debuglink; done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjsig.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so

Thanks,
Severin

From erik.joelsson at oracle.com  Thu Jul  5 16:54:23 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 5 Jul 2018 09:54:23 -0700
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally
 when no debuginfo is stripped
In-Reply-To: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
References: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
Message-ID: <2abd74ca-c35f-a71c-8894-fdb594826c69@oracle.com>

Looks good to me.

/Erik


On 2018-07-05 09:41, Severin Gehwolf wrote:
> Hi,
>
> Please review this 8u-only change. JDK 10+ are not affected.
>
> For JDK 8 builds which don't perform any debug info stripping no
> .gnu_debuglink sections should get generated. The fix is to move the
> objcopy --add-gnu-debuglink calls into branches which actually perform
> some stripping: all_strip, min_strip. Thoughts?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8206425
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206425/webrev.01/
>
> Testing: Manually produced a build with no stripping and verified no
> .gnu_debuglink sections got generated.
>
> $ for i in $(find build/linux-x86_64-normal-server-release/images/j2sdk-image/ \
>   | grep -E 'libjvm.so|libsaproc.so|libjsig.so'); do echo $i
>   readelf --sections $i | grep gnu_debuglink; done
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjsig.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
>
> Thanks,
> Severin


From boris.ulasevich at bell-sw.com  Thu Jul  5 17:09:35 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Thu, 5 Jul 2018 20:09:35 +0300
Subject: [11] RFR(S) 8206265: assert in TestOptionsWithRanges on aarch64
Message-ID: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>

Hi all,

please review bugfix for openjdk-11 and 12:

   http://cr.openjdk.java.net/~bulasevich/8206265/webrev.04/
   https://bugs.openjdk.java.net/browse/JDK-8206265

Currently, TestOptionsWithRanges which tries different combinations of 
maximum option values fails with assert if SoftwarePrefetchHintDistance 
option limit is 32K (prfm gets imm12<<3) when using its maximum value in 
cmp instruction (which fits only 12-bit immediate).

A new instruction cmp(rscratch, Rn, imm) alias is introduced to use it 
when immediate value can not fit in 12 bit. I believe it's cleaner than 
using subs.

Alternatively, if someone believes this looks risky for 11 I can propose 
to just limit SoftwarePrefetchHintDistance. It seems unreasonable to 
prefetch more than a few cache lines ahead anyway.

thanks,
Boris

From coleen.phillimore at oracle.com  Thu Jul  5 17:29:57 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 5 Jul 2018 13:29:57 -0400
Subject: RFR JDK-8206394 : ResourceMark in AOTCompiledMethod::metadata_do, 
 AOTCompiledMethod::clear_inline_caches ,
 CompiledMethod::clear_ic_stubs , 
 CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks when
 CompiledIC_at is used ?
In-Reply-To: <31df82f18d7b4b6bbf514676dfdf171e@sap.com>
References: <74d4f74ddb934d33a712887edd606d24@sap.com>
 <284b43ad-bec2-f479-7068-84945e4c89d0@oracle.com>
 <31df82f18d7b4b6bbf514676dfdf171e@sap.com>
Message-ID: <74183e10-314b-1e5b-b7ce-c5f8172fb665@oracle.com>


Some ResourceMarks are missing because they might clear other resource 
allocated memory when they return.? This usually occurs with the 
print_on(outputStream*) methods because logStream or stringStream may be 
expanded in the print function and you don't want it cleared on return.? 
There may also be a ResourceMark further up the call chain for these 
cases.? So you have to be careful with this.


On 7/5/18 12:18 PM, Baesken, Matthias wrote:
> Great , thanks for your help !
>
>
> Btw.  while looking a bit more at the  ResourceMark usages  , I found  that the    name_and_sig_as_C_string()   calls  are mostly
>     in the codebase with a  related ResourceMark .
>
> However it is not done always,  for example ;   do you think it is missing at these places or not needed?
>
>
> hotspot/share/classfile/verifier.cpp#626
>
> 623void ClassVerifier::verify_method(const methodHandle& m, TRAPS) {
> 624  HandleMark hm(THREAD);

The HandleMark is probably not needed here though.? A ResourceMark does 
seem like a good idea here.

Coleen
> 625  _method = m;   // initialize _method
> 626  log_info(verification)("Verifying method %s", m->name_and_sig_as_C_string());
>
>
> hotspot/share/classfile/classLoader.cpp#2045
>
> void ClassLoader::compile_the_world_in(char* name, Handle loader, TRAPS) {
>
> 2058                if (HAS_PENDING_EXCEPTION) {
> 2059                  clear_pending_exception_if_not_oom(CHECK);
> 2060                  tty->print_cr("CompileTheWorld (%d) : Skipping method: %s", _compile_the_world_class_counter, m->name_and_sig_as_C_string());
> 2061                } else {
> 2062                  _compile_the_world_method_counter++;
> 2063                }
> 2064              }
> 2065            } else {
> 2066              tty->print_cr("CompileTheWorld (%d) : Skipping method: %s", _compile_the_world_class_counter, m->name_and_sig_as_C_string());
> 2067            }
>
> Best regards, Matthias
>
>
>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Donnerstag, 5. Juli 2018 18:07
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: RFR JDK-8206394 : ResourceMark in
>> AOTCompiledMethod::metadata_do,
>> AOTCompiledMethod::clear_inline_caches ,
>> CompiledMethod::clear_ic_stubs ,
>> CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks
>> when CompiledIC_at is used ?
>>
>> Looks good. I will test it and push if it passed.
>>
>> Thanks,
>> Vladimir
>>
>> On 7/5/18 2:14 AM, Baesken, Matthias wrote:
>>> Hi Vladimir, thanks for looking into it !
>>>
>>> Please review :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8206394/
>>>
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8206394
>>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Mittwoch, 4. Juli 2018 19:43
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>> Subject: Re: ResourceMarks when CompiledIC_at is used ?
>>>>
>>>> Thank you, Matthias
>>>>
>>>> Yes, I checked all these places and they have to be fixed. Please, file
>>>> a bug for jdk11.
>>>>
>>>> Vladimir
>>>>
>>>> On 7/4/18 7:44 AM, Baesken, Matthias wrote:
>>>>> Hello,   I recently looked at   8164293: HotSpot leaking memory in long-
>>>> running requests
>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a
>>>>>
>>>>> where a number of missing ResourceMarks were added .
>>>>> I think some of those ResourceMarks were added  because of
>>>> CompiledIC_at  in the changed  functions .
>>>>> I checked for  other CompiledIC_at    in the hs coding ,  and found some
>>>> other places (see below) where  ResourceMarks  are missing as well.
>>>>> Should they be added ?
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>
>>>>> src/hotspot/share/aot/aotCompiledMethod.cpp
>>>>>
>>>>> void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
>>>>> .....
>>>>> 274      } else if (iter.type() == relocInfo::virtual_call_type) {
>>>>> 275        // Check compiledIC holders associated with this nmethod
>>>>> 276        CompiledIC *ic = CompiledIC_at(&iter);    <---------------------------
>> ----
>>>> -----
>>>>>
>>>>>        and
>>>>>
>>>>> 441void AOTCompiledMethod::clear_inline_caches() {
>>>>> 442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's
>> only
>>>> allowed at safepoint");
>>>>> 443  if (is_zombie()) {
>>>>> 444    return;
>>>>> 445  }
>>>>> 446
>>>>> 447  RelocIterator iter(this);
>>>>> 448  while (iter.next()) {
>>>>> 449    iter.reloc()->clear_inline_cache();
>>>>> 450    if (iter.type() == relocInfo::opt_virtual_call_type) {
>>>>> 451      CompiledIC* cic = CompiledIC_at(&iter);    <---------------------------
>> ----
>>>> -----
>>>>> 452      assert(cic->is_clean(), "!");
>>>>> 453      nativePltCall_at(iter.addr())->set_stub_to_clean();
>>>>> 454    }
>>>>> 455  }
>>>>> 456}
>>>>>
>>>>> src/hotspot/share/code/compiledMethod.cpp
>>>>>
>>>>> 326void CompiledMethod::clear_ic_stubs() {
>>>>> 327  assert_locked_or_safepoint(CompiledIC_lock);
>>>>> 328  RelocIterator iter(this);
>>>>> 329  while(iter.next()) {
>>>>> 330    if (iter.type() == relocInfo::virtual_call_type) {
>>>>> 331      CompiledIC* ic = CompiledIC_at(&iter);      <---------------------------
>> ----
>>>> -----
>>>>> 332      ic->clear_ic_stub();
>>>>> 333    }
>>>>> 334  }
>>>>> 335}
>>>>>
>>>>>
>>>>> 547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel,
>> bool
>>>> unloading_occurred, bool clean_all) {
>>>>> 548  assert_locked_or_safepoint(CompiledIC_lock);
>>>>> 549  bool postponed = false;
>>>>> 550
>>>>> 551  // Find all calls in an nmethod and clear the ones that point to non-
>>>> entrant,
>>>>> 552  // zombie and unloaded nmethods.
>>>>> 553  RelocIterator iter(this, oops_reloc_begin());
>>>>> 554  while(iter.next()) {
>>>>> 555
>>>>> 556    switch (iter.type()) {
>>>>> 557
>>>>> 558    case relocInfo::virtual_call_type:
>>>>> 559      if (unloading_occurred) {
>>>>> 560        // If class unloading occurred we first clear ICs where the cached
>>>> metadata
>>>>> 561        // is referring to an unloaded klass or method.
>>>>> 562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));        <------
>> ---
>>>> ---------------------------


From thomas.stuefe at gmail.com  Thu Jul  5 18:27:15 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 5 Jul 2018 20:27:15 +0200
Subject: RFR JDK-8206394 : ResourceMark in AOTCompiledMethod::metadata_do, 
 AOTCompiledMethod::clear_inline_caches ,
 CompiledMethod::clear_ic_stubs , 
 CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks when
 CompiledIC_at is used ?
In-Reply-To: <74183e10-314b-1e5b-b7ce-c5f8172fb665@oracle.com>
References: <74d4f74ddb934d33a712887edd606d24@sap.com>
 <284b43ad-bec2-f479-7068-84945e4c89d0@oracle.com>
 <31df82f18d7b4b6bbf514676dfdf171e@sap.com>
 <74183e10-314b-1e5b-b7ce-c5f8172fb665@oracle.com>
Message-ID: <CAA-vtUwrqYxgtf_fmCtnzVT3k6s4MhmZ89aK=4TU6BceRWKOhw@mail.gmail.com>

Hi Coleen,

On Thu, Jul 5, 2018 at 7:29 PM,  <coleen.phillimore at oracle.com> wrote:
>
> Some ResourceMarks are missing because they might clear other resource
> allocated memory when they return.  This usually occurs with the
> print_on(outputStream*) methods because logStream or stringStream may be
> expanded in the print function and you don't want it cleared on return.

Not LogStream, we explicitly refactored that to not use ResourceArea
anymore: https://bugs.openjdk.java.net/browse/JDK-8181917

I think stringStream should not use ResourceArea either. One should
avoid handing pointers to resourceArea up and down the stack so much.
For stringStream this is especially evil since whether this
crashes/asserts depends on when the buffer is resized, and that
depends on the content written to the stream, and that is highly
runtime dependent and difficult to test.

If we keep doing this, maybe we could at least modify
stringStream::write() to assert on the ResourceMark equality every
time it is called instead of just when the buffer gets resized. What
do you think?

..Thomas

> There may also be a ResourceMark further up the call chain for these cases.
> So you have to be careful with this.
>
>
> On 7/5/18 12:18 PM, Baesken, Matthias wrote:
>>
>> Great , thanks for your help !
>>
>>
>> Btw.  while looking a bit more at the  ResourceMark usages  , I found
>> that the    name_and_sig_as_C_string()   calls  are mostly
>>     in the codebase with a  related ResourceMark .
>>
>> However it is not done always,  for example ;   do you think it is missing
>> at these places or not needed?
>>
>>
>> hotspot/share/classfile/verifier.cpp#626
>>
>> 623void ClassVerifier::verify_method(const methodHandle& m, TRAPS) {
>> 624  HandleMark hm(THREAD);
>
>
> The HandleMark is probably not needed here though.  A ResourceMark does seem
> like a good idea here.
>
> Coleen
>
>> 625  _method = m;   // initialize _method
>> 626  log_info(verification)("Verifying method %s",
>> m->name_and_sig_as_C_string());
>>
>>
>> hotspot/share/classfile/classLoader.cpp#2045
>>
>> void ClassLoader::compile_the_world_in(char* name, Handle loader, TRAPS) {
>>
>> 2058                if (HAS_PENDING_EXCEPTION) {
>> 2059                  clear_pending_exception_if_not_oom(CHECK);
>> 2060                  tty->print_cr("CompileTheWorld (%d) : Skipping
>> method: %s", _compile_the_world_class_counter,
>> m->name_and_sig_as_C_string());
>> 2061                } else {
>> 2062                  _compile_the_world_method_counter++;
>> 2063                }
>> 2064              }
>> 2065            } else {
>> 2066              tty->print_cr("CompileTheWorld (%d) : Skipping method:
>> %s", _compile_the_world_class_counter, m->name_and_sig_as_C_string());
>> 2067            }
>>
>> Best regards, Matthias
>>
>>
>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>> Sent: Donnerstag, 5. Juli 2018 18:07
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: RFR JDK-8206394 : ResourceMark in
>>> AOTCompiledMethod::metadata_do,
>>> AOTCompiledMethod::clear_inline_caches ,
>>> CompiledMethod::clear_ic_stubs ,
>>> CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks
>>> when CompiledIC_at is used ?
>>>
>>> Looks good. I will test it and push if it passed.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 7/5/18 2:14 AM, Baesken, Matthias wrote:
>>>>
>>>> Hi Vladimir, thanks for looking into it !
>>>>
>>>> Please review :
>>>>
>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8206394/
>>>>
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8206394
>>>>
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>>> Sent: Mittwoch, 4. Juli 2018 19:43
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>>> Subject: Re: ResourceMarks when CompiledIC_at is used ?
>>>>>
>>>>> Thank you, Matthias
>>>>>
>>>>> Yes, I checked all these places and they have to be fixed. Please, file
>>>>> a bug for jdk11.
>>>>>
>>>>> Vladimir
>>>>>
>>>>> On 7/4/18 7:44 AM, Baesken, Matthias wrote:
>>>>>>
>>>>>> Hello,   I recently looked at   8164293: HotSpot leaking memory in
>>>>>> long-
>>>>>
>>>>> running requests
>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a
>>>>>>
>>>>>> where a number of missing ResourceMarks were added .
>>>>>> I think some of those ResourceMarks were added  because of
>>>>>
>>>>> CompiledIC_at  in the changed  functions .
>>>>>>
>>>>>> I checked for  other CompiledIC_at    in the hs coding ,  and found
>>>>>> some
>>>>>
>>>>> other places (see below) where  ResourceMarks  are missing as well.
>>>>>>
>>>>>> Should they be added ?
>>>>>>
>>>>>> Best regards, Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>> src/hotspot/share/aot/aotCompiledMethod.cpp
>>>>>>
>>>>>> void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
>>>>>> .....
>>>>>> 274      } else if (iter.type() == relocInfo::virtual_call_type) {
>>>>>> 275        // Check compiledIC holders associated with this nmethod
>>>>>> 276        CompiledIC *ic = CompiledIC_at(&iter);
>>>>>> <---------------------------
>>>
>>> ----
>>>>>
>>>>> -----
>>>>>>
>>>>>>
>>>>>>        and
>>>>>>
>>>>>> 441void AOTCompiledMethod::clear_inline_caches() {
>>>>>> 442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's
>>>
>>> only
>>>>>
>>>>> allowed at safepoint");
>>>>>>
>>>>>> 443  if (is_zombie()) {
>>>>>> 444    return;
>>>>>> 445  }
>>>>>> 446
>>>>>> 447  RelocIterator iter(this);
>>>>>> 448  while (iter.next()) {
>>>>>> 449    iter.reloc()->clear_inline_cache();
>>>>>> 450    if (iter.type() == relocInfo::opt_virtual_call_type) {
>>>>>> 451      CompiledIC* cic = CompiledIC_at(&iter);
>>>>>> <---------------------------
>>>
>>> ----
>>>>>
>>>>> -----
>>>>>>
>>>>>> 452      assert(cic->is_clean(), "!");
>>>>>> 453      nativePltCall_at(iter.addr())->set_stub_to_clean();
>>>>>> 454    }
>>>>>> 455  }
>>>>>> 456}
>>>>>>
>>>>>> src/hotspot/share/code/compiledMethod.cpp
>>>>>>
>>>>>> 326void CompiledMethod::clear_ic_stubs() {
>>>>>> 327  assert_locked_or_safepoint(CompiledIC_lock);
>>>>>> 328  RelocIterator iter(this);
>>>>>> 329  while(iter.next()) {
>>>>>> 330    if (iter.type() == relocInfo::virtual_call_type) {
>>>>>> 331      CompiledIC* ic = CompiledIC_at(&iter);
>>>>>> <---------------------------
>>>
>>> ----
>>>>>
>>>>> -----
>>>>>>
>>>>>> 332      ic->clear_ic_stub();
>>>>>> 333    }
>>>>>> 334  }
>>>>>> 335}
>>>>>>
>>>>>>
>>>>>> 547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel,
>>>
>>> bool
>>>>>
>>>>> unloading_occurred, bool clean_all) {
>>>>>>
>>>>>> 548  assert_locked_or_safepoint(CompiledIC_lock);
>>>>>> 549  bool postponed = false;
>>>>>> 550
>>>>>> 551  // Find all calls in an nmethod and clear the ones that point to
>>>>>> non-
>>>>>
>>>>> entrant,
>>>>>>
>>>>>> 552  // zombie and unloaded nmethods.
>>>>>> 553  RelocIterator iter(this, oops_reloc_begin());
>>>>>> 554  while(iter.next()) {
>>>>>> 555
>>>>>> 556    switch (iter.type()) {
>>>>>> 557
>>>>>> 558    case relocInfo::virtual_call_type:
>>>>>> 559      if (unloading_occurred) {
>>>>>> 560        // If class unloading occurred we first clear ICs where the
>>>>>> cached
>>>>>
>>>>> metadata
>>>>>>
>>>>>> 561        // is referring to an unloaded klass or method.
>>>>>> 562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));
>>>>>> <------
>>>
>>> ---
>>>>>
>>>>> ---------------------------
>
>

From rkennke at redhat.com  Thu Jul  5 18:37:01 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 5 Jul 2018 20:37:01 +0200
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
Message-ID: <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>

I am not an expert in this particular code, but know assembly well. The
implementation looks good to me.

What happens when JNI critical functions are encountered on other
platforms? Will it fail gracefully or fall back to something else? Would
(for example) Shenandoah have to turn off JNI criticals on such
platforms until support gets implemented?

Also, as you mentioned, it baked quite a lot in Shenandoah already, and
passes our tests that stress this code.

Thank you!
Roman

> Ping!!!! anyone? please!
> 
> - Zhengyu
> 
> On 05/02/2018 05:12 PM, Per Liden wrote:
>> Hi,
>>
>> On 05/02/2018 09:41 PM, Zhengyu Gu wrote:
>>> Hi,
>>>
>>> Can I have reviews for this RFR?
>>>
>>> This patch completes object pinning for JNI critical section,
>>> provides critical native support.
>>>
>>> The approach is quite straightforward:
>>>
>>> During generating native wrapper for critical native method, it
>>> generates runtime call to pin every array argument, before unpacks them.
>>>
>>> For pinned objects, it also needs to save them for unpinning after
>>> JNI function call completes.
>>>
>>> If argument is passed on stack, it saves pinned object at the
>>> original slot (as pin_object() may move the object). For register
>>> based arguments, it reuses oop handle area (where GCLocker based
>>> implementation saves register based arguments for safepoints).
>>>
>>> Currently, only Shenandoah uses object pinning for JNI critical
>>> section, this patch has been baked quite some time there. However, I
>>> am new to Runtime Stub code, I would appreciate your comments and
>>> suggestions.
>>>
>>> I rebased patch to jdk/jdk repo.
>>>
>>> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.02/
>>
>> Just want to say that I would really like to see this patch go in. As
>> mentioned, it completes the object pinning story and it's useful for
>> other GCs too (at least ZGC and possibly G1). However, I also agree
>> with Aleksey that some one who really knows this code needs to review
>> this. Unfortunately that's not me. Anyone?
>>
>> cheers,
>> Per
>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> On 04/06/2018 10:35 PM, Zhengyu Gu wrote:
>>>> Offline discussion with Aleksey, he suggested that
>>>> pin/unpin_critical_native_array methods can be made more generic as
>>>> pin/unpin_object.
>>>>
>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.01/
>>>>
>>>> Test:
>>>> ?? Reran all tests, submit-hs tests still clean.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>> On 04/06/2018 08:55 AM, Aleksey Shipilev wrote:
>>>>> On 04/04/2018 07:47 PM, Zhengyu Gu wrote:
>>>>>> Please review this patch that adds JNI critical native support to
>>>>>> object pinning.
>>>>>>
>>>>>> Shenandoah does not block GC while JNI critical session is in
>>>>>> progress. This patch allows it to pin
>>>>>> all incoming array objects before critical native call, and unpin
>>>>>> them after call completes.
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199868
>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.00/
>>>>>
>>>>> Looks good to me, but somebody more savvy with runtime stub
>>>>> generation should take a closer look.
>>>>>
>>>>> *) Should probably be "Why we are here?"
>>>>>
>>>>> 2867?? assert(Universe::heap()->supports_object_pinning(), "Why we
>>>>> here?");
>>>>>
>>>>> 2876?? assert(Universe::heap()->supports_object_pinning(), "Why we
>>>>> here?");
>>>>>
>>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>



From rkennke at redhat.com  Thu Jul  5 18:38:00 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 5 Jul 2018 20:38:00 +0200
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
Message-ID: <12288105-0aa8-75c9-8e8e-9941c3e9239b@redhat.com>

One more thing: we might want to move the entry points from
SharedRuntime to CollectedHeap.

Roman

> Ping!!!! anyone? please!
> 
> - Zhengyu
> 
> On 05/02/2018 05:12 PM, Per Liden wrote:
>> Hi,
>>
>> On 05/02/2018 09:41 PM, Zhengyu Gu wrote:
>>> Hi,
>>>
>>> Can I have reviews for this RFR?
>>>
>>> This patch completes object pinning for JNI critical section,
>>> provides critical native support.
>>>
>>> The approach is quite straightforward:
>>>
>>> During generating native wrapper for critical native method, it
>>> generates runtime call to pin every array argument, before unpacks them.
>>>
>>> For pinned objects, it also needs to save them for unpinning after
>>> JNI function call completes.
>>>
>>> If argument is passed on stack, it saves pinned object at the
>>> original slot (as pin_object() may move the object). For register
>>> based arguments, it reuses oop handle area (where GCLocker based
>>> implementation saves register based arguments for safepoints).
>>>
>>> Currently, only Shenandoah uses object pinning for JNI critical
>>> section, this patch has been baked quite some time there. However, I
>>> am new to Runtime Stub code, I would appreciate your comments and
>>> suggestions.
>>>
>>> I rebased patch to jdk/jdk repo.
>>>
>>> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.02/
>>
>> Just want to say that I would really like to see this patch go in. As
>> mentioned, it completes the object pinning story and it's useful for
>> other GCs too (at least ZGC and possibly G1). However, I also agree
>> with Aleksey that some one who really knows this code needs to review
>> this. Unfortunately that's not me. Anyone?
>>
>> cheers,
>> Per
>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> On 04/06/2018 10:35 PM, Zhengyu Gu wrote:
>>>> Offline discussion with Aleksey, he suggested that
>>>> pin/unpin_critical_native_array methods can be made more generic as
>>>> pin/unpin_object.
>>>>
>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.01/
>>>>
>>>> Test:
>>>> ?? Reran all tests, submit-hs tests still clean.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>> On 04/06/2018 08:55 AM, Aleksey Shipilev wrote:
>>>>> On 04/04/2018 07:47 PM, Zhengyu Gu wrote:
>>>>>> Please review this patch that adds JNI critical native support to
>>>>>> object pinning.
>>>>>>
>>>>>> Shenandoah does not block GC while JNI critical session is in
>>>>>> progress. This patch allows it to pin
>>>>>> all incoming array objects before critical native call, and unpin
>>>>>> them after call completes.
>>>>>>
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199868
>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.00/
>>>>>
>>>>> Looks good to me, but somebody more savvy with runtime stub
>>>>> generation should take a closer look.
>>>>>
>>>>> *) Should probably be "Why we are here?"
>>>>>
>>>>> 2867?? assert(Universe::heap()->supports_object_pinning(), "Why we
>>>>> here?");
>>>>>
>>>>> 2876?? assert(Universe::heap()->supports_object_pinning(), "Why we
>>>>> here?");
>>>>>
>>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>



From christian.tornqvist at oracle.com  Thu Jul  5 18:53:53 2018
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 5 Jul 2018 14:53:53 -0400
Subject: OpenJDK wiki still points to old submit-hs repository
In-Reply-To: <CAA-vtUx_uPg7BFZQm5gk7WJxSajEf9UJ8tRN+eOAnrB83iE-gg@mail.gmail.com>
References: <9df06789-808e-1f8f-935b-783e342aaecf@physik.fu-berlin.de>
 <01D84E66-C40B-4EFD-9929-B6DCFA98E9E0@oracle.com>
 <955E9C4F-DBC0-40EE-BEC0-936C3995E32C@oracle.com>
 <CAA-vtUx_uPg7BFZQm5gk7WJxSajEf9UJ8tRN+eOAnrB83iE-gg@mail.gmail.com>
Message-ID: <8F1E3167-00E3-410D-A12A-BEE8E86EEE04@oracle.com>

Hi Thomas,

I?ve update the page with your suggestions, thank your for the feedback!

Thanks,
Christian

> On Jun 13, 2018, at 6:37 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi Christian,
> 
> some small remarks:
> 
> - the sections "Should I close my branch?" and "How do I update my
> branch with the latest upstream changes?" both miss "hg push" at the
> end.
> 
> - also, as a suggested add: to get an overview about how many test
> heads one has still open and maybe forgotten to close, one can use "hg
> log -r "heads(all()) and not closed() and user('<user>') and not
> branch(default)"
> 
> Best Regards, Thomas
> 
> 
> On Tue, Jun 12, 2018 at 6:57 PM, Christian Tornqvist
> <christian.tornqvist at oracle.com> wrote:
>> I?ve updated the page so that it now correctly points to the jdk/submit repo, thanks for noticing this!
>> 
>> Thanks,
>> Christian
>> 
>>> On Jun 12, 2018, at 7:18 07AM, jesper.wilhelmsson at oracle.com wrote:
>>> 
>>> Paging Christian.
>>> (I don't have write access to this page.)
>>> 
>>> Thanks for reporting this Adrian!
>>> 
>>> /Jesper
>>> 
>>>> On 12 Jun 2018, at 15:49, John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de> wrote:
>>>> 
>>>> Hi!
>>>> 
>>>> Just a heads-up: The wiki page for the submit repository is still pointing
>>>> to the the old submit-hs repository. This should be "submit" nowadays,
>>>> "submit-hs" is read-only anyway.
>>>> 
>>>> See: https://wiki.openjdk.java.net/display/Build/Submit+Repo
>>>> 
>>>> Adrian
>>>> 
>>>> --
>>>> .''`.  John Paul Adrian Glaubitz
>>>> : :' :  Debian Developer - glaubitz at debian.org
>>>> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>>>> `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>>> 
>> 


From igor.ignatyev at oracle.com  Thu Jul  5 20:02:49 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 5 Jul 2018 13:02:49 -0700
Subject: RFR(S/M) [trivial] 8206429 : [REDO] 8202561 clean up TEST.groups
Message-ID: <C9E121B5-B98D-4AEB-B651-92936234052C@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
> 243 lines changed: 0 ins; 124 del; 119 mod; 

Hi all,

could you please review this redo of 8202561? 8202561 was backed out b/c our CI infra didn't support multiple test group files. now such configurations are supported, so 8202561 can be re-integrated.
the patch is the exact 8202561 changeset and it has applied clearly.
 
webrev: http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8206429
testing: successfully submitted adhoc jobs which use a "quick" test group in the same way CI system does

Thanks,
-- Igor

From gnu.andrew at redhat.com  Thu Jul  5 20:05:50 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 5 Jul 2018 21:05:50 +0100
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
Message-ID: <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>

On 5 July 2018 at 05:03, David Holmes <david.holmes at oracle.com> wrote:
> Hi Andrew,
>
> As far as I can see this got quite messy. We initially disabled the warning
> to fix the build problem. Then we actually changed the code in 8179887. But
> that broke JFR's use of the API:
>
> https://bugs.openjdk.java.net/browse/JDK-8202835
>

Yes, I saw this just before posting the backport, but couldn't figure out how/if
it related to 8u. There is no JFR in OpenJDK 8u, is there? Certainly,
I don't see
the os_perf_linux.cpp file in Bernard's proposed patch in 8u. Maybe you could
shed some light on this.

> and that and:
>
> https://bugs.openjdk.java.net/browse/JDK-8202794
>
> remain open and unresolved.
>

The JDK side doesn't cause the same problems as the HotSpot side because
it isn't built with -Werror. Currently, I can't build 8u on a system
with a recent
glibc without patching out the readdir_r usage in some way. As you may
guess, it's becoming a bit of a pain. So there's not the same need to
backport this to 8u.

That said, is there a reason the patch hasn't made it into the mainline yet?
I couldn't see any follow-on in the mailing list archive.

> I'd be inclined to disable the build warning for 8u rather than make code
> changes (which will likely still break JFR).

This was my first inclination - and it's what we went with for OpenJDK
7 [0] [1] -
but it brings its own problems. The way it was disabled at first uses inline
pragmas that don't work with older versions of GCC that are used to build
8. Moving the pragma outside the function is problematic because this is an
inline header file.

>
> David
>
>

[0] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/66e04addced6
[1] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/819d329e1fd0
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From thomas.stuefe at gmail.com  Thu Jul  5 20:26:02 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 5 Jul 2018 22:26:02 +0200
Subject: OpenJDK wiki still points to old submit-hs repository
In-Reply-To: <8F1E3167-00E3-410D-A12A-BEE8E86EEE04@oracle.com>
References: <9df06789-808e-1f8f-935b-783e342aaecf@physik.fu-berlin.de>
 <01D84E66-C40B-4EFD-9929-B6DCFA98E9E0@oracle.com>
 <955E9C4F-DBC0-40EE-BEC0-936C3995E32C@oracle.com>
 <CAA-vtUx_uPg7BFZQm5gk7WJxSajEf9UJ8tRN+eOAnrB83iE-gg@mail.gmail.com>
 <8F1E3167-00E3-410D-A12A-BEE8E86EEE04@oracle.com>
Message-ID: <CAA-vtUz3GpWCm0KBsYNVMfArue+d4nyZBiz4TtYvNVjE7XwC2w@mail.gmail.com>

Great, thanks!

..Thomas

On Thu 5. Jul 2018 at 20:53, Christian Tornqvist <
christian.tornqvist at oracle.com> wrote:

> Hi Thomas,
>
> I?ve update the page with your suggestions, thank your for the feedback!
>
> Thanks,
> Christian
>
> > On Jun 13, 2018, at 6:37 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >
> > Hi Christian,
> >
> > some small remarks:
> >
> > - the sections "Should I close my branch?" and "How do I update my
> > branch with the latest upstream changes?" both miss "hg push" at the
> > end.
> >
> > - also, as a suggested add: to get an overview about how many test
> > heads one has still open and maybe forgotten to close, one can use "hg
> > log -r "heads(all()) and not closed() and user('<user>') and not
> > branch(default)"
> >
> > Best Regards, Thomas
> >
> >
> > On Tue, Jun 12, 2018 at 6:57 PM, Christian Tornqvist
> > <christian.tornqvist at oracle.com> wrote:
> >> I?ve updated the page so that it now correctly points to the jdk/submit
> repo, thanks for noticing this!
> >>
> >> Thanks,
> >> Christian
> >>
> >>> On Jun 12, 2018, at 7:18 07AM, jesper.wilhelmsson at oracle.com wrote:
> >>>
> >>> Paging Christian.
> >>> (I don't have write access to this page.)
> >>>
> >>> Thanks for reporting this Adrian!
> >>>
> >>> /Jesper
> >>>
> >>>> On 12 Jun 2018, at 15:49, John Paul Adrian Glaubitz <
> glaubitz at physik.fu-berlin.de> wrote:
> >>>>
> >>>> Hi!
> >>>>
> >>>> Just a heads-up: The wiki page for the submit repository is still
> pointing
> >>>> to the the old submit-hs repository. This should be "submit" nowadays,
> >>>> "submit-hs" is read-only anyway.
> >>>>
> >>>> See: https://wiki.openjdk.java.net/display/Build/Submit+Repo
> >>>>
> >>>> Adrian
> >>>>
> >>>> --
> >>>> .''`.  John Paul Adrian Glaubitz
> >>>> : :' :  Debian Developer - glaubitz at debian.org
> >>>> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> >>>> `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
> >>>
> >>
>
>

From vladimir.kozlov at oracle.com  Thu Jul  5 21:18:48 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 5 Jul 2018 14:18:48 -0700
Subject: RFR(S/M) [trivial] 8206429 : [REDO] 8202561 clean up TEST.groups
In-Reply-To: <C9E121B5-B98D-4AEB-B651-92936234052C@oracle.com>
References: <C9E121B5-B98D-4AEB-B651-92936234052C@oracle.com>
Message-ID: <8bf17bd4-8461-c296-2e1a-4872dd0b3166@oracle.com>

I am fine with re-do if you were able re-test it to verify that it 
actually works. Not like last time.

Thanks,
Vladimir

On 7/5/18 1:02 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
>> 243 lines changed: 0 ins; 124 del; 119 mod;
> 
> Hi all,
> 
> could you please review this redo of 8202561? 8202561 was backed out b/c our CI infra didn't support multiple test group files. now such configurations are supported, so 8202561 can be re-integrated.
> the patch is the exact 8202561 changeset and it has applied clearly.
>   
> webrev: http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8206429
> testing: successfully submitted adhoc jobs which use a "quick" test group in the same way CI system does
> 
> Thanks,
> -- Igor
> 

From igor.ignatyev at oracle.com  Thu Jul  5 21:33:42 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 5 Jul 2018 14:33:42 -0700
Subject: RFR(S/M) [trivial] 8206429 : [REDO] 8202561 clean up TEST.groups
In-Reply-To: <8bf17bd4-8461-c296-2e1a-4872dd0b3166@oracle.com>
References: <C9E121B5-B98D-4AEB-B651-92936234052C@oracle.com>
 <8bf17bd4-8461-c296-2e1a-4872dd0b3166@oracle.com>
Message-ID: <C048D1A2-D18E-4982-851A-D81833093518@oracle.com>

well, I did test it last time, I just didn't expect that some parts of infra do submission a bit weirdly. now (at least as far as I can tell) I tested submission in the exact same way.

-- Igor

> On Jul 5, 2018, at 2:18 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> I am fine with re-do if you were able re-test it to verify that it actually works. Not like last time.
> 
> Thanks,
> Vladimir
> 
> On 7/5/18 1:02 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
>>> 243 lines changed: 0 ins; 124 del; 119 mod;
>> Hi all,
>> could you please review this redo of 8202561? 8202561 was backed out b/c our CI infra didn't support multiple test group files. now such configurations are supported, so 8202561 can be re-integrated.
>> the patch is the exact 8202561 changeset and it has applied clearly.
>>  webrev: http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206429
>> testing: successfully submitted adhoc jobs which use a "quick" test group in the same way CI system does
>> Thanks,
>> -- Igor


From christian.tornqvist at oracle.com  Thu Jul  5 21:49:42 2018
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 5 Jul 2018 17:49:42 -0400
Subject: RFR(S/M) [trivial] 8206429 : [REDO] 8202561 clean up TEST.groups
In-Reply-To: <C048D1A2-D18E-4982-851A-D81833093518@oracle.com>
References: <C9E121B5-B98D-4AEB-B651-92936234052C@oracle.com>
 <8bf17bd4-8461-c296-2e1a-4872dd0b3166@oracle.com>
 <C048D1A2-D18E-4982-851A-D81833093518@oracle.com>
Message-ID: <235FDC96-1564-4D55-97A2-02D5833C9A9B@oracle.com>

I agree with Igor, this wouldn?t have been found by ?normal? pre-integration testing. Change looks good, sorry for the extra work you had to do.

Thanks,
Christian

> On Jul 5, 2018, at 5:33 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> well, I did test it last time, I just didn't expect that some parts of infra do submission a bit weirdly. now (at least as far as I can tell) I tested submission in the exact same way.
> 
> -- Igor
> 
>> On Jul 5, 2018, at 2:18 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>> I am fine with re-do if you were able re-test it to verify that it actually works. Not like last time.
>> 
>> Thanks,
>> Vladimir
>> 
>>> On 7/5/18 1:02 PM, Igor Ignatyev wrote:
>>> http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
>>>> 243 lines changed: 0 ins; 124 del; 119 mod;
>>> Hi all,
>>> could you please review this redo of 8202561? 8202561 was backed out b/c our CI infra didn't support multiple test group files. now such configurations are supported, so 8202561 can be re-integrated.
>>> the patch is the exact 8202561 changeset and it has applied clearly.
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206429
>>> testing: successfully submitted adhoc jobs which use a "quick" test group in the same way CI system does
>>> Thanks,
>>> -- Igor
> 


From david.holmes at oracle.com  Thu Jul  5 21:54:22 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Jul 2018 07:54:22 +1000
Subject: RFR(S/M) [trivial] 8206429 : [REDO] 8202561 clean up TEST.groups
In-Reply-To: <235FDC96-1564-4D55-97A2-02D5833C9A9B@oracle.com>
References: <C9E121B5-B98D-4AEB-B651-92936234052C@oracle.com>
 <8bf17bd4-8461-c296-2e1a-4872dd0b3166@oracle.com>
 <C048D1A2-D18E-4982-851A-D81833093518@oracle.com>
 <235FDC96-1564-4D55-97A2-02D5833C9A9B@oracle.com>
Message-ID: <12a3c68d-143b-949f-ef7a-54a86e4886d3@oracle.com>

+1

Thanks,
David

On 6/07/2018 7:49 AM, Christian Tornqvist wrote:
> I agree with Igor, this wouldn?t have been found by ?normal? pre-integration testing. Change looks good, sorry for the extra work you had to do.
> 
> Thanks,
> Christian
> 
>> On Jul 5, 2018, at 5:33 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>> well, I did test it last time, I just didn't expect that some parts of infra do submission a bit weirdly. now (at least as far as I can tell) I tested submission in the exact same way.
>>
>> -- Igor
>>
>>> On Jul 5, 2018, at 2:18 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>
>>> I am fine with re-do if you were able re-test it to verify that it actually works. Not like last time.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>> On 7/5/18 1:02 PM, Igor Ignatyev wrote:
>>>> http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
>>>>> 243 lines changed: 0 ins; 124 del; 119 mod;
>>>> Hi all,
>>>> could you please review this redo of 8202561? 8202561 was backed out b/c our CI infra didn't support multiple test group files. now such configurations are supported, so 8202561 can be re-integrated.
>>>> the patch is the exact 8202561 changeset and it has applied clearly.
>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8206429/webrev.00/index.html
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8206429
>>>> testing: successfully submitted adhoc jobs which use a "quick" test group in the same way CI system does
>>>> Thanks,
>>>> -- Igor
>>
> 

From david.holmes at oracle.com  Fri Jul  6 01:31:05 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Jul 2018 11:31:05 +1000
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
Message-ID: <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>

On 6/07/2018 6:05 AM, Andrew Hughes wrote:
> On 5 July 2018 at 05:03, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Andrew,
>>
>> As far as I can see this got quite messy. We initially disabled the warning
>> to fix the build problem. Then we actually changed the code in 8179887. But
>> that broke JFR's use of the API:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8202835
>>
> 
> Yes, I saw this just before posting the backport, but couldn't figure out how/if
> it related to 8u. There is no JFR in OpenJDK 8u, is there? Certainly,
> I don't see
> the os_perf_linux.cpp file in Bernard's proposed patch in 8u. Maybe you could
> shed some light on this.

There's no JFR in the open in 8u, but I would expect this to still cause 
the same problem for Oracle's 8u JDK.

>> and that and:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8202794
>>
>> remain open and unresolved.
>>
> 
> The JDK side doesn't cause the same problems as the HotSpot side because
> it isn't built with -Werror. Currently, I can't build 8u on a system
> with a recent
> glibc without patching out the readdir_r usage in some way. As you may
> guess, it's becoming a bit of a pain. So there's not the same need to
> backport this to 8u.
> 
> That said, is there a reason the patch hasn't made it into the mainline yet?
> I couldn't see any follow-on in the mailing list archive.

I can't answer that sorry. I was simply pointing out this this may not 
be as clean and simple as suggested. I certainly couldn't add my review 
to it for 8u as it remains unclear to me whether the fix is suitable.

> 
>> I'd be inclined to disable the build warning for 8u rather than make code
>> changes (which will likely still break JFR).
> 
> This was my first inclination - and it's what we went with for OpenJDK
> 7 [0] [1] -
> but it brings its own problems. The way it was disabled at first uses inline
> pragmas that don't work with older versions of GCC that are used to build
> 8. Moving the pragma outside the function is problematic because this is an
> inline header file.

It's never easy is it. :(

Cheers,
David

>>
>> David
>>
>>
> 
> [0] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/66e04addced6
> [1] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/819d329e1fd0
> 

From david.holmes at oracle.com  Fri Jul  6 01:53:47 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Jul 2018 11:53:47 +1000
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally
 when no debuginfo is stripped
In-Reply-To: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
References: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
Message-ID: <8982397a-6165-3471-e15f-5dc3694027d7@oracle.com>

Hi Severin,

On 6/07/2018 2:41 AM, Severin Gehwolf wrote:
> Hi,
> 
> Please review this 8u-only change. JDK 10+ are not affected.
> 
> For JDK 8 builds which don't perform any debug info stripping no
> .gnu_debuglink sections should get generated. The fix is to move the
> objcopy --add-gnu-debuglink calls into branches which actually perform
> some stripping: all_strip, min_strip. Thoughts?

Has anything changed with the tools here? This has been in place since 
back in 2011 with 7u2 and 8 GA! Why has it only become an issue now?

That's not an objection to the fix, I'm just curious how a problem could 
exist for so long.

Thanks,
David

> Bug: https://bugs.openjdk.java.net/browse/JDK-8206425
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206425/webrev.01/
> 
> Testing: Manually produced a build with no stripping and verified no
> .gnu_debuglink sections got generated.
> 
> $ for i in $(find build/linux-x86_64-normal-server-release/images/j2sdk-image/ \
>   | grep -E 'libjvm.so|libsaproc.so|libjsig.so'); do echo $i
>   readelf --sections $i | grep gnu_debuglink; done
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjsig.so
> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
> 
> Thanks,
> Severin
> 

From Joshua.Zhu at arm.com  Fri Jul  6 03:10:08 2018
From: Joshua.Zhu at arm.com (Joshua Zhu)
Date: Fri, 6 Jul 2018 03:10:08 +0000
Subject: [11] RFR(S) 8206265: assert in TestOptionsWithRanges on aarch64
In-Reply-To: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
Message-ID: <VI1PR08MB30542F11E5F453F1CA0F89E388470@VI1PR08MB3054.eurprd08.prod.outlook.com>

A month later, this case failed again. cmp(reg, imm) is error-prone.
cmp(Rd, Rn, imm) alias is fine but may be ignored by users. 

There was a subject related with cmp(reg, imm) removal.
http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-May/005829.html

Best Regards,
Joshua

From sgehwolf at redhat.com  Fri Jul  6 08:26:26 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 06 Jul 2018 10:26:26 +0200
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added
 unconditionally when no debuginfo is stripped
In-Reply-To: <8982397a-6165-3471-e15f-5dc3694027d7@oracle.com>
References: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
 <8982397a-6165-3471-e15f-5dc3694027d7@oracle.com>
Message-ID: <59dc6ee9d7d77991b72e480c1d62797050425959.camel@redhat.com>

Hi David,

On Fri, 2018-07-06 at 11:53 +1000, David Holmes wrote:
> Hi Severin,
> 
> On 6/07/2018 2:41 AM, Severin Gehwolf wrote:
> > Hi,
> > 
> > Please review this 8u-only change. JDK 10+ are not affected.
> > 
> > For JDK 8 builds which don't perform any debug info stripping no
> > .gnu_debuglink sections should get generated. The fix is to move the
> > objcopy --add-gnu-debuglink calls into branches which actually perform
> > some stripping: all_strip, min_strip. Thoughts?
> 
> Has anything changed with the tools here? This has been in place since 
> back in 2011 with 7u2 and 8 GA! Why has it only become an issue now?

I'm doubtful anything has changed with the tools. This is one of those
patches which we seem to have been carrying downstream for a very long
time. My archeology seems to suggest it started to show up in Fedora 23
in November 2016. If anything, we'd be to blame to not push this fix
upstream earlier.

> That's not an objection to the fix, I'm just curious how a problem could 
> exist for so long.

OK to get this pushed to JDK 8u?

Thanks,
Severin

> Thanks,
> David
> 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8206425
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206425/webrev.01/
> > 
> > Testing: Manually produced a build with no stripping and verified no
> > .gnu_debuglink sections got generated.
> > 
> > $ for i in $(find build/linux-x86_64-normal-server-release/images/j2sdk-image/ \
> >   | grep -E 'libjvm.so|libsaproc.so|libjsig.so'); do echo $i
> >   readelf --sections $i | grep gnu_debuglink; done
> > build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
> > build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
> > build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjsig.so
> > build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
> > 
> > Thanks,
> > Severin
> > 

From david.holmes at oracle.com  Fri Jul  6 09:41:16 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Jul 2018 19:41:16 +1000
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally
 when no debuginfo is stripped
In-Reply-To: <59dc6ee9d7d77991b72e480c1d62797050425959.camel@redhat.com>
References: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
 <8982397a-6165-3471-e15f-5dc3694027d7@oracle.com>
 <59dc6ee9d7d77991b72e480c1d62797050425959.camel@redhat.com>
Message-ID: <51321361-990a-50d3-c25e-d68117825e95@oracle.com>

On 6/07/2018 6:26 PM, Severin Gehwolf wrote:
> Hi David,
> 
> On Fri, 2018-07-06 at 11:53 +1000, David Holmes wrote:
>> Hi Severin,
>>
>> On 6/07/2018 2:41 AM, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Please review this 8u-only change. JDK 10+ are not affected.
>>>
>>> For JDK 8 builds which don't perform any debug info stripping no
>>> .gnu_debuglink sections should get generated. The fix is to move the
>>> objcopy --add-gnu-debuglink calls into branches which actually perform
>>> some stripping: all_strip, min_strip. Thoughts?
>>
>> Has anything changed with the tools here? This has been in place since
>> back in 2011 with 7u2 and 8 GA! Why has it only become an issue now?
> 
> I'm doubtful anything has changed with the tools. This is one of those
> patches which we seem to have been carrying downstream for a very long
> time. My archeology seems to suggest it started to show up in Fedora 23
> in November 2016. If anything, we'd be to blame to not push this fix
> upstream earlier.
> 
>> That's not an objection to the fix, I'm just curious how a problem could
>> exist for so long.
> 
> OK to get this pushed to JDK 8u?

You have your code reviews. Now you need to request approval as per:

http://openjdk.java.net/projects/jdk8u/approval-template.html

Cheers,
David

> 
> Thanks,
> Severin
> 
>> Thanks,
>> David
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8206425
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206425/webrev.01/
>>>
>>> Testing: Manually produced a build with no stripping and verified no
>>> .gnu_debuglink sections got generated.
>>>
>>> $ for i in $(find build/linux-x86_64-normal-server-release/images/j2sdk-image/ \
>>>    | grep -E 'libjvm.so|libsaproc.so|libjsig.so'); do echo $i
>>>    readelf --sections $i | grep gnu_debuglink; done
>>> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
>>> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
>>> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjsig.so
>>> build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
>>>
>>> Thanks,
>>> Severin
>>>

From kevin.walls at oracle.com  Fri Jul  6 09:54:02 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 6 Jul 2018 10:54:02 +0100
Subject: RFR: 8206454: [8u] os::current_stack_pointer() fails to compile on
 later Windows compilers (warning C4172: returning address of local variable)
Message-ID: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>

Hi,

I'd like to get a review of this change for 8u:

8206454: [8u] os::current_stack_pointer() fails to compile on later 
Windows compilers (warning C4172: returning address of local variable)
https://bugs.openjdk.java.net/browse/JDK-8206454

This is part of getting jdk8u to accept later Windows compilers. Not 
changing the code, but adding a conditional? #pragma to let the compiler 
accept the code.

I'll include a diff in text below (can do a webrev if anybody would like 
one...).

Many thanks!
Kevin


bash-4.2$ hg diff src/os_cpu/windows_x86/vm/os_windows_x86.cpp
diff -r 5792d995ed26 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
--- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp????? Wed Jun 27 
03:04:33 2018 -0700
+++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp????? Fri Jul 06 
02:46:48 2018 -0700
@@ -454,11 +454,19 @@
 ?// Returns an estimate of the current stack pointer. Result must be 
guaranteed
 ?// to point into the calling threads stack, and be no lower than the 
current
 ?// stack pointer.
+#if defined(_MSC_VER) && _MSC_VER >= 1900
+// warning C4172: returning address of local variable or temporary: dummy
+#pragma warning( push )
+#pragma warning( disable: 4172 )
+#endif
 ?address os::current_stack_pointer() {
 ?? int dummy;
 ?? address sp = (address)&dummy;
 ?? return sp;
 ?}
+#if defined(_MSC_VER) && _MSC_VER >= 1900
+#pragma warning( pop )
+#endif
 ?#else
 ?// Returns the current stack pointer. Accurate value needed for
 ?// os::verify_stack_alignment().




From sgehwolf at redhat.com  Fri Jul  6 11:21:30 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 06 Jul 2018 13:21:30 +0200
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added
 unconditionally when no debuginfo is stripped
In-Reply-To: <51321361-990a-50d3-c25e-d68117825e95@oracle.com>
References: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
 <8982397a-6165-3471-e15f-5dc3694027d7@oracle.com>
 <59dc6ee9d7d77991b72e480c1d62797050425959.camel@redhat.com>
 <51321361-990a-50d3-c25e-d68117825e95@oracle.com>
Message-ID: <b22f9edffc0c259a728a8ec572553d107c454f0d.camel@redhat.com>

On Fri, 2018-07-06 at 19:41 +1000, David Holmes wrote:
> > 
> > OK to get this pushed to JDK 8u?
> 
> You have your code reviews. Now you need to request approval as per:
> 
> http://openjdk.java.net/projects/jdk8u/approval-template.html

Yes, thanks:
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007623.html

Cheers,
Severin

From kevin.walls at oracle.com  Fri Jul  6 12:27:40 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 6 Jul 2018 13:27:40 +0100
Subject: RFR: 8205677: [8u] casts and type change for 8u to enable later
 Windows compilers
In-Reply-To: <10a72c45-c34a-599a-b771-08d5a7083c62@oracle.com>
References: <10a72c45-c34a-599a-b771-08d5a7083c62@oracle.com>
Message-ID: <0150c644-5b70-84ff-0ee7-3874e4318e6a@oracle.com>

Hi,

I'd like to update my review request:

Item #3, was solved by 8150426 so no change required.

Item #5, changing the return type of the method is not necessary.? The 
error was in src/share/vm/runtime/memprofiler.cpp and can be solved with 
a cast on the offending line.? The result of a long divided by a size_t 
can be cast to a long, and that minimal change is? accepted in all the 
builds:

-????????? OopMapCache::memory_usage() / K);
+????????? (long) (OopMapCache::memory_usage() / K));

Additionally, I've uncovered one more required cast, so item #6 is? 
src/share/vm/classfile/classFileParser.cpp changing an (int) cast to a (u2).

New webrev at http://cr.openjdk.java.net/~kevinw/8205677/webrev.01/

Progress report: with these changes, 8206454 which I just put out for 
review, and one other change re: vnsprintf, the open jdk8u builds with 
VS2017.

Many thanks!
Kevin





On 05/07/2018 09:46, Kevin Walls wrote:
> Hi,
>
> I'd like to get a review of:
>
> 8205677: [8u] casts and type change for 8u to enable later Windows 
> compilers
> https://bugs.openjdk.java.net/browse/JDK-8205677
>
> This is a collection of new small changes aiming to permit 8u to build 
> with later Windows compilers (and also with the current VS2010).
>
> The changes are:
>
> 8u webrev: http://cr.openjdk.java.net/~kevinw/8205677/webrev.00/
>
> Notes:
>
> 1
> hotspot\src\share\vm\classfile\altHashing.cpp(227): warning C4838: 
> conversion from 'unsigned int' to 'const jint' requires a narrowing 
> conversion
>
> (jint) casts are present in the later JDK 
> test/hotspot/gtest/classfile/test_AltHashing.cpp and look like they 
> were in JDK9 from the start.
>
> 2
> hotspot\src\share\vm\gc_implementation\parallelScavenge\gcTaskManager.cpp(1038): 
> warning C4312: 'type cast': conversion from 'unsigned int' to 'Monitor 
> *' of greater size
>
> -? _monitor = (Monitor*) 0xDEAD000F;
> +? _monitor = (Monitor*) (uintptr_t) 0xDEAD000F;
>
> 3
> ..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): error C2440: '=': 
> cannot convert from 'jlong' to 'jlong *'
> ..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): note: Conversion 
> from integral type to pointer type requires reinterpret_cast, C-style 
> cast or function-style cast
>
> -??? *long_at_addr(which) = (long)contents;
> +??? *long_at_addr(which) = (jlong)contents;
>
>
> 4
> ...\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepGeneration.cpp(6833): 
> warning C4334: '<<': result of 32-bit shift implicitly converted to 64 
> bits (was 64-bit shift intended?)
>
> Like in 8197864 where we cast a 1 to an intptr_t before the shift.
>
> ?? assert(mr.end() == (HeapWord*)round_to((intptr_t)mr.end(),
> -??????????????????????? (1 << (_shifter+LogHeapWordSize))),
> +??????????????????????? ((intptr_t) 1 << (_shifter+LogHeapWordSize))),
>
>
> 5
> hotspot\src\share\vm\runtime\memprofiler.cpp(129): warning C4477: 
> 'fprintf' : format string '%6ld' requires an argument of type 'long', 
> but variadic argument 3 has type '::size_t'
>
> OopMapCache::memory_size() is only used in one place, and only when 
> NOTPRODUCT.? Here in 8u, we can make it return a size_t and compile 
> without error.
>
> In jdk10 onwards, after 8186042, this line in memprofiler.cpp 
> hard-codes a 0L instead of OopMapCache::memory_size(), as the tracking 
> of _total_memory_size was removed, but the print was kept to the same 
> format.? I don't think we would remove that statistic in an update
>
>
> Thanks
> Kevin
>
>
>
>
>
>
>


From aph at redhat.com  Fri Jul  6 12:34:50 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 6 Jul 2018 13:34:50 +0100
Subject: [11] RFR(S) 8206265: assert in TestOptionsWithRanges on aarch64
In-Reply-To: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
Message-ID: <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>

On 07/05/2018 06:09 PM, Boris Ulasevich wrote:
> A new instruction cmp(rscratch, Rn, imm) alias is introduced to use it 
> when immediate value can not fit in 12 bit. I believe it's cleaner than 
> using subs.

Maybe so, yes.  So we can delete all but the byte form of cmp(reg, imm), poison
the other forms, and add cmp(reg, reg, imm).  Works for me.

> Alternatively, if someone believes this looks risky for 11 I can propose 
> to just limit SoftwarePrefetchHintDistance. It seems unreasonable to 
> prefetch more than a few cache lines ahead anyway.

That's best for 11.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From david.buck at oracle.com  Fri Jul  6 13:34:03 2018
From: david.buck at oracle.com (David Buck)
Date: Fri, 6 Jul 2018 22:34:03 +0900
Subject: RFR (8u): JDK-8146115: Improve docker container detection and
 resource configuration usage
Message-ID: <996ca977-bf69-825a-d809-16941780f376@oracle.com>

Hi Poonam!

This looks like a good backport of the change and the accompanying 
add-on fixes. Please feel free to add me as a reviewer.

Cheers,
-Buck

-------- Forwarded Message --------
Subject:     Re: RFR (8u): JDK-8146115: Improve docker container 
detection and resource configuration usage
To:     Poonam Parhar <poonam.bajaj at oracle.com>
Organization:     Oracle Corporation
From:     Bob Vandette <bob.vandette at oracle.com>
CC:     hotspot-dev at openjdk.java.net

The latest webrev looks fine.

Bob.

 > On Jun 22, 2018, at 9:07 AM, Poonam Parhar <poonam.bajaj at 
oracle.com> wrote:
 >
 > Hello,
 >
 > Could I get one more review for the docker backport changes, please!
 >
 > The latest webrev including the suggestions from Bob's review is here:
 > http://cr.openjdk.java.net/~poonam/8146115/webrev.02/ 
<http://cr.openjdk.java.net/%7Epoonam/8146115/webrev.02/>
 >
 > Thanks,
 > Poonam
 >
 >
 > On 5/18/18 6:30 AM, Poonam Parhar wrote:
 >> Hello Bob,
 >>
 >> Thanks a lot for reviewing the changes!
 >>
 >> On 5/17/18 11:12 AM, Bob Vandette wrote:
 >>> The backport of my changes look pretty good.
 >>>
 >>> If the new PrintContainerInfo option is only referenced on Linux 
platforms, you might
 >>> want to move it to globals_linux.hpp.
 >> Yes, currently it is being used only on Linux platforms, but I think 
it is a general option and might be used on other platforms at a later 
date.  So I think we can leave it in globals.hpp.
 >>>
 >>> Is there a reason PrintActiveCpus is a diagnostic flag but 
PrintContainerInfo is not?
 >> Yes, PrintContainerInfo should also be a diagnostic option. I have 
changed it.
 >> Updated webrev: 
http://cr.openjdk.java.net/~poonam/8146115/webrev.01/ 
<http://cr.openjdk.java.net/~poonam/8146115/webrev.01/>
 >>
 >>>
 >>> Is it acceptable to add these new VM flags in a backport that won?t 
be supported in the latest release?
 >> Since JDK 9 and later releases use Unified JVM logging, and we don't 
have that in JDK8, a new option is required in 8 to log the information 
which is being logged under 'container' tag in 10 and 11. We will need 
to have a CSR request approved for the new JVM options added as part of 
this backport.
 >>
 >> Thanks,
 >> Poonam
 >>
 >>>
 >>> Bob.
 >>>
 >>>
 >>>> On May 15, 2018, at 4:46 PM, Poonam Parhar <poonam.bajaj at 
oracle.com> <mailto:poonam.bajaj at oracle.com> wrote:
 >>>>
 >>>> Hello,
 >>>>
 >>>> Please review the docker container support changes backported to 
JDK 8u. These changes include the backport of the following enhancement 
and the follow-on bug fixes done on top of that in jdk 10 and 11.
 >>>>
 >>>> Webrev: http://cr.openjdk.java.net/~poonam/8146115/webrev.00/ 
<http://cr.openjdk.java.net/~poonam/8146115/webrev.00/>
 >>>>
 >>>> Enhancement:JDK-8146115: Improve docker container detection and 
resource configuration 
usage<https://bugs.openjdk.java.net/browse/JDK-8146115> 
<https://bugs.openjdk.java.net/browse/JDK-8146115>
 >>>>
 >>>> The changes also include the fixes for the following two bugs:
 >>>> Bug JDK-8186248: Allow more flexibility in selecting Heap % of 
available RAM <https://bugs.openjdk.java.net/browse/JDK-8186248> 
<https://bugs.openjdk.java.net/browse/JDK-8186248><https://bugs.openjdk.java.net/browse/JDK-8190283> 
<https://bugs.openjdk.java.net/browse/JDK-8190283>
 >>>> BugJDK-8190283: <https://bugs.openjdk.java.net/browse/JDK-8190283> 
<https://bugs.openjdk.java.net/browse/JDK-8190283> Default heap sizing 
options select a MaxHeapSize larger than available physical memory in 
some cases <https://bugs.openjdk.java.net/browse/JDK-8190283> 
<https://bugs.openjdk.java.net/browse/JDK-8190283>
 >>>>
 >>>> These changes add a new JVM option 'PrintContainerInfo' for 
tracing container related information which is specific to jdk 8.
 >>>>
 >>>> Testing results (with -XX:+UnlockDiagnosticVMOptions 
-XX:+PrintContainerInfo -XX:+PrintActiveCpus JVM options):
 >>>> --------------
 >>>> poonam at poonam-VirtualBox:~/docker-image$ java TestCPUsMemory
 >>>> Number of Processors: 3
 >>>> Max Memory: 921174016
 >>>> poonam at poonam-VirtualBox:~/docker-image$ sudo docker run --cpus 
1 -m1024m  --rm myimage
 >>>> [sudo] password for poonam:
 >>>> WARNING: Your kernel does not support swap limit capabilities or 
the cgroup is not mounted. Memory limited without swap.
 >>>> OSContainer::init: Initializing Container Support
 >>>> Path to /memory.limit_in_bytes is 
/sys/fs/cgroup/memory/memory.limit_in_bytes
 >>>> Memory Limit is: 1073741824
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: 100000
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> CPU Quota count based on quota/period: 1
 >>>> OSContainer::active_processor_count: 1
 >>>> active_processor_count: determined by OSContainer: 1
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: 100000
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> CPU Quota count based on quota/period: 1
 >>>> OSContainer::active_processor_count: 1
 >>>> active_processor_count: determined by OSContainer: 1
 >>>> Path to /memory.limit_in_bytes is 
/sys/fs/cgroup/memory/memory.limit_in_bytes
 >>>> Memory Limit is: 1073741824
 >>>> total container memory: 1073741824
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: 100000
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> CPU Quota count based on quota/period: 1
 >>>> OSContainer::active_processor_count: 1
 >>>> active_processor_count: determined by OSContainer: 1
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: 100000
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> CPU Quota count based on quota/period: 1
 >>>> OSContainer::active_processor_count: 1
 >>>> active_processor_count: determined by OSContainer: 1
 >>>>
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: 100000
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> CPU Quota count based on quota/period: 1
 >>>> OSContainer::active_processor_count: 1
 >>>> active_processor_count: determined by OSContainer: 1
 >>>> Number of Processors: 1
 >>>> Max Memory: 259522560
 >>>>
 >>>> poonam at poonam-VirtualBox:~/docker-image$ sudo docker run 
--cpu-shares 2048 -m1024m  --rm myimage
 >>>> WARNING: Your kernel does not support swap limit capabilities or 
the cgroup is not mounted. Memory limited without swap.
 >>>> OSContainer::init: Initializing Container Support
 >>>> Path to /memory.limit_in_bytes is 
/sys/fs/cgroup/memory/memory.limit_in_bytes
 >>>> Memory Limit is: 1073741824
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 2048
 >>>> CPU Share count based on shares: 2
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 2048
 >>>> CPU Share count based on shares: 2
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>> Path to /memory.limit_in_bytes is 
/sys/fs/cgroup/memory/memory.limit_in_bytes
 >>>> Memory Limit is: 1073741824
 >>>> total container memory: 1073741824
 >>>> Path to /memory.limit_in_bytes is 
/sys/fs/cgroup/memory/memory.limit_in_bytes
 >>>> Memory Limit is: 1073741824
 >>>> total container memory: 1073741824
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 2048
 >>>> CPU Share count based on shares: 2
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 2048
 >>>> CPU Share count based on shares: 2
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>>
 >>>> active_processor_count: sched_getaffinity processor count: 3
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 2048
 >>>> CPU Share count based on shares: 2
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>> Number of Processors: 2
 >>>> Max Memory: 259522560
 >>>>
 >>>> poonam at poonam-VirtualBox:~/docker-image$ sudo docker run 
--cpuset-cpus 0-1 -m1024m  --rm myimage
 >>>> WARNING: Your kernel does not support swap limit capabilities or 
the cgroup is not mounted. Memory limited without swap.
 >>>> OSContainer::init: Initializing Container Support
 >>>> Path to /memory.limit_in_bytes is 
/sys/fs/cgroup/memory/memory.limit_in_bytes
 >>>> Memory Limit is: 1073741824
 >>>> active_processor_count: sched_getaffinity processor count: 2
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>> active_processor_count: sched_getaffinity processor count: 2
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>> Path to /memory.limit_in_bytes is 
/sys/fs/cgroup/memory/memory.limit_in_bytes
 >>>> Memory Limit is: 1073741824
 >>>> total container memory: 1073741824
 >>>> Path to /memory.limit_in_bytes is 
/sys/fs/cgroup/memory/memory.limit_in_bytes
 >>>> Memory Limit is: 1073741824
 >>>> total container memory: 1073741824
 >>>> active_processor_count: sched_getaffinity processor count: 2
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>> active_processor_count: sched_getaffinity processor count: 2
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>>
 >>>> active_processor_count: sched_getaffinity processor count: 2
 >>>> Path to /cpu.cfs_quota_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
 >>>> CPU Quota is: -1
 >>>> Path to /cpu.cfs_period_us is 
/sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
 >>>> CPU Period is: 100000
 >>>> Path to /cpu.shares is /sys/fs/cgroup/cpu,cpuacct/cpu.shares
 >>>> CPU Shares is: 1024
 >>>> OSContainer::active_processor_count: 2
 >>>> active_processor_count: determined by OSContainer: 2
 >>>> Number of Processors: 2
 >>>> Max Memory: 259522560
 >>>> ------------------
 >>>>
 >>>> Thanks,
 >>>> Poonam
 >>>>
 >>
 >

From gnu.andrew at redhat.com  Fri Jul  6 18:50:22 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 6 Jul 2018 19:50:22 +0100
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
 <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
Message-ID: <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>

On 6 July 2018 at 02:31, David Holmes <david.holmes at oracle.com> wrote:

snip...

>
>
> There's no JFR in the open in 8u, but I would expect this to still cause the
> same problem for Oracle's 8u JDK.
>

Ok, there's not really much I can do to test this then?


snip...

>>
>>> I'd be inclined to disable the build warning for 8u rather than make code
>>> changes (which will likely still break JFR).
>>
>>
>> This was my first inclination - and it's what we went with for OpenJDK
>> 7 [0] [1] -
>> but it brings its own problems. The way it was disabled at first uses
>> inline
>> pragmas that don't work with older versions of GCC that are used to build
>> 8. Moving the pragma outside the function is problematic because this is
>> an
>> inline header file.
>
>
> It's never easy is it. :(
>

Shall I propose this fix instead then?


> Cheers,
> David
>
>
>>>
>>> David
>>>
>>>
>>
>> [0] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/66e04addced6
>> [1] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/819d329e1fd0
>>
>



-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From kim.barrett at oracle.com  Fri Jul  6 20:09:03 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 6 Jul 2018 16:09:03 -0400
Subject: RFR: 8206454: [8u] os::current_stack_pointer() fails to compile
 on later Windows compilers (warning C4172: returning address of local
 variable)
In-Reply-To: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>
References: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>
Message-ID: <279CBF76-F9F1-4E1F-833C-BACE01CFD51B@oracle.com>

> On Jul 6, 2018, at 5:54 AM, Kevin Walls <kevin.walls at oracle.com> wrote:
> 
> Hi,
> 
> I'd like to get a review of this change for 8u:
> 
> 8206454: [8u] os::current_stack_pointer() fails to compile on later Windows compilers (warning C4172: returning address of local variable)
> https://bugs.openjdk.java.net/browse/JDK-8206454
> 
> This is part of getting jdk8u to accept later Windows compilers. Not changing the code, but adding a conditional  #pragma to let the compiler accept the code.

Why is this only being done for jdk8u, and why isn?t it a problem in (say) jdk11 or jdk12?
The code being patched below is still the same.

> I'll include a diff in text below (can do a webrev if anybody would like one...).
> 
> Many thanks!
> Kevin
> 
> 
> bash-4.2$ hg diff src/os_cpu/windows_x86/vm/os_windows_x86.cpp
> diff -r 5792d995ed26 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
> --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp      Wed Jun 27 03:04:33 2018 -0700
> +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp      Fri Jul 06 02:46:48 2018 -0700
> @@ -454,11 +454,19 @@
>  // Returns an estimate of the current stack pointer. Result must be guaranteed
>  // to point into the calling threads stack, and be no lower than the current
>  // stack pointer.
> +#if defined(_MSC_VER) && _MSC_VER >= 1900
> +// warning C4172: returning address of local variable or temporary: dummy
> +#pragma warning( push )
> +#pragma warning( disable: 4172 )
> +#endif
>  address os::current_stack_pointer() {
>    int dummy;
>    address sp = (address)&dummy;
>    return sp;
>  }
> +#if defined(_MSC_VER) && _MSC_VER >= 1900
> +#pragma warning( pop )
> +#endif
>  #else
>  // Returns the current stack pointer. Accurate value needed for
>  // os::verify_stack_alignment().



From kevin.walls at oracle.com  Fri Jul  6 20:37:34 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 6 Jul 2018 21:37:34 +0100
Subject: RFR: 8206454: [8u] os::current_stack_pointer() fails to compile
 on later Windows compilers (warning C4172: returning address of local
 variable)
In-Reply-To: <279CBF76-F9F1-4E1F-833C-BACE01CFD51B@oracle.com>
References: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>
 <279CBF76-F9F1-4E1F-833C-BACE01CFD51B@oracle.com>
Message-ID: <fdfc8bcc-b5f9-527e-98a5-cd518e5a00ec@oracle.com>

Hi Kim -

Good question. 8-)? Yes the same code is there in the latest version 
when I looked, but address os::current_stack_pointer() is within an 
#ifndef AMD64, so I suspect have we never built 32-bit with the later 
VS2017 compiler...

More file context around the 8u suggestion below..

Thanks
Kevin

src/os_cpu/windows_x86/vm/os_windows_x86.cpp

 ?? 452
 ?? 453? #ifndef AMD64
 ?? 454? // Returns an estimate of the current stack pointer. Result 
must be guaranteed
 ?? 455? // to point into the calling threads stack, and be no lower 
than the current
 ?? 456? // stack pointer.
 ?? 457? #if defined(_MSC_VER) && _MSC_VER >= 1900
 ?? 458? // warning C4172: returning address of local variable or 
temporary: dummy
 ?? 459? #pragma warning( push )
 ?? 460? #pragma warning( disable: 4172 )
 ?? 461? #endif
 ?? 462? address os::current_stack_pointer() {
 ?? 463??? int dummy;
 ?? 464??? address sp = (address)&dummy;
 ?? 465??? return sp;
 ?? 466? }
 ?? 467? #if defined(_MSC_VER) && _MSC_VER >= 1900
 ?? 468? #pragma warning( pop )
 ?? 469? #endif
 ?? 470? #else
 ?? 471? // Returns the current stack pointer. Accurate value needed for
 ?? 472? // os::verify_stack_alignment().
 ?? 473? address os::current_stack_pointer() {
 ?? 474??? typedef address get_sp_func();
 ?? 475??? get_sp_func* func = CAST_TO_FN_PTR(get_sp_func*,
 ?? 476 StubRoutines::x86::get_previous_sp_entry());
 ?? 477??? return (*func)();
 ?? 478? }
 ?? 479? #endif
 ?? 480




On 06/07/2018 21:09, Kim Barrett wrote:
>> On Jul 6, 2018, at 5:54 AM, Kevin Walls <kevin.walls at oracle.com> wrote:
>>
>> Hi,
>>
>> I'd like to get a review of this change for 8u:
>>
>> 8206454: [8u] os::current_stack_pointer() fails to compile on later Windows compilers (warning C4172: returning address of local variable)
>> https://bugs.openjdk.java.net/browse/JDK-8206454
>>
>> This is part of getting jdk8u to accept later Windows compilers. Not changing the code, but adding a conditional  #pragma to let the compiler accept the code.
> Why is this only being done for jdk8u, and why isn?t it a problem in (say) jdk11 or jdk12?
> The code being patched below is still the same.
>
>> I'll include a diff in text below (can do a webrev if anybody would like one...).
>>
>> Many thanks!
>> Kevin
>>
>>
>> bash-4.2$ hg diff src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>> diff -r 5792d995ed26 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>> --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp      Wed Jun 27 03:04:33 2018 -0700
>> +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp      Fri Jul 06 02:46:48 2018 -0700
>> @@ -454,11 +454,19 @@
>>   // Returns an estimate of the current stack pointer. Result must be guaranteed
>>   // to point into the calling threads stack, and be no lower than the current
>>   // stack pointer.
>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>> +// warning C4172: returning address of local variable or temporary: dummy
>> +#pragma warning( push )
>> +#pragma warning( disable: 4172 )
>> +#endif
>>   address os::current_stack_pointer() {
>>     int dummy;
>>     address sp = (address)&dummy;
>>     return sp;
>>   }
>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>> +#pragma warning( pop )
>> +#endif
>>   #else
>>   // Returns the current stack pointer. Accurate value needed for
>>   // os::verify_stack_alignment().
>


From ioi.lam at oracle.com  Fri Jul  6 21:33:39 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 6 Jul 2018 14:33:39 -0700
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to link
 to source code
In-Reply-To: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
Message-ID: <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>

Hi,


Since there's interest for this patch, I've finished it for the x86 port:

https://bugs.openjdk.java.net/browse/JDK-8204267
http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/

You can see a sample at

http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt

Incorporating this to other CPU ports should be pretty straight forward. 
You just
need to do something like:

-#define __ _masm->
+#define __ Disassembler::hook<MacroAssembler>(__FILE__, __LINE__, _masm)->

I'll leave it to other CPU port maintainers.

I am testing with hs_tier{1,2}.

Thanks

- Ioi


On 6/4/18 12:12 AM, Ioi Lam wrote:
> Hi Folks,
>
> I've found it very hard to understand the assembler code printed by 
> -XX:+PrintInterpreter. Since the C++ source code that generates the 
> interpreter is fairly well documented, it might be a good idea to 
> print out the source code along with the assembler code.
>
> I've done a quick proof-of-concept by hacking the "__" macro that's 
> used throughout the CPU-dependent sources.
>
> Please let me know if you think this is worth doing. If so, I will try 
> to finish it up and post a real RFR.
>
> Thanks
> - Ioi
>
>
> https://bugs.openjdk.java.net/browse/JDK-8204267
> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00 
>
> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00/hs_interp.S 
>
>
> Here are some examples (if the mailer screws up the long lines, please 
> click the above link):
>
> ifeq? 153 ifeq? [0x00007f830cc93da0, 0x00007f830cc941c0] 1056 bytes
>
> mov??? (%rsp),%eax
> add??? $0x8,%rsp
> test?? %eax,%eax?????????? ;; 2353:?? __ testl(rax, rax);
> jne??? 0x00007f830cc94177? ;; 2354:?? __ jcc(j_not(cc), not_taken);
> mov??? -0x18(%rbp),%rcx??? ;; 2120:?? __ get_method(rcx); // rcx holds 
> method
> mov??? -0x28(%rbp),%rax??? ;; 2121:?? __ profile_taken_branch(rax, 
> rbx); // rax holds updated MDP, rbx
> test?? %rax,%rax
> je???? 0x00007f830cc93dd8
> mov??? 0x8(%rax),%rbx
> add??? $0x1,%rbx
> sbb??? $0x0,%rbx
> mov??? %rbx,0x8(%rax)
> add??? 0x10(%rax),%rax
> mov??? %rax,-0x28(%rbp)
> movswl 0x1(%r13),%edx????? ;; 2133:???? __ load_signed_short(rdx, 
> at_bcp(1));
> bswap? %edx??????????????? ;; 2135:?? __ bswapl(rdx);
> sar??? $0x10,%edx????????? ;; 2138:???? __ sarl(rdx, 16);
> movslq %edx,%rdx?????????? ;; 2140:?? LP64_ONLY(__ movl2ptr(rdx, rdx));
> add??? %rdx,%r13?????????? ;; 2164:?? __ addptr(rbcp, rdx);
> test?? %edx,%edx?????????? ;; 2179:???? __ testl(rdx, 
> rdx);???????????? // check if forward or backward branch
> jns??? 0x00007f830cc93eec? ;; 2180:???? __ jcc(Assembler::positive, 
> dispatch); // count only if backward branch
> mov??? 0x18(%rcx),%rax???? ;; 2184:???? __ movptr(rax, Address(rcx, 
> Method::method_counters_offset()));
> test?? %rax,%rax?????????? ;; 2185:???? __ testptr(rax, rax);
> jne??? 0x00007f830cc93ead? ;; 2186:???? __ jcc(Assembler::notZero, 
> has_counters);
> push?? %rdx??????????????? ;; 2187:???? __ push(rdx);
> push?? %rcx??????????????? ;; 2188:???? __ push(rcx);
> callq? 0x00007f830cc93e09? ;; 2189:???? __ call_VM(noreg, 
> CAST_FROM_FN_PTR(address, InterpreterRuntime::build_method_counters),
>


From kim.barrett at oracle.com  Fri Jul  6 22:32:18 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 6 Jul 2018 18:32:18 -0400
Subject: RFR: 8206454: [8u] os::current_stack_pointer() fails to compile
 on later Windows compilers (warning C4172: returning address of local
 variable)
In-Reply-To: <fdfc8bcc-b5f9-527e-98a5-cd518e5a00ec@oracle.com>
References: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>
 <279CBF76-F9F1-4E1F-833C-BACE01CFD51B@oracle.com>
 <fdfc8bcc-b5f9-527e-98a5-cd518e5a00ec@oracle.com>
Message-ID: <A3A75A0C-215E-4F05-A91C-01EFA719273F@oracle.com>

> On Jul 6, 2018, at 4:37 PM, Kevin Walls <kevin.walls at oracle.com> wrote:
> 
> Hi Kim -
> 
> Good question. 8-)  Yes the same code is there in the latest version when I looked, but address os::current_stack_pointer() is within an #ifndef AMD64, so I suspect have we never built 32-bit with the later VS2017 compiler?

Oh, you are right.  I mis-read that as #ifdef AMD64.

Yeah, we (Oracle) don?t seem to be doing 32bit Windows builds anymore.  Presumably
nobody else is doing so with recent versions of VS and the JDK, else the problem would
have already been known (and probably dealt with).  Since I?m not a big fan of adding
untested code, I?m okay with just addressing this in jdk8u, and leaving the current code
alone until someone complains about it.

Unfortunately, while this change looks okay to me, I?m not even a committer for jdk8,
so you still need a Reviewer.

> More file context around the 8u suggestion below..
> 
> Thanks
> Kevin
> 
> src/os_cpu/windows_x86/vm/os_windows_x86.cpp
> 
>    452
>    453  #ifndef AMD64
>    454  // Returns an estimate of the current stack pointer. Result must be guaranteed
>    455  // to point into the calling threads stack, and be no lower than the current
>    456  // stack pointer.
>    457  #if defined(_MSC_VER) && _MSC_VER >= 1900
>    458  // warning C4172: returning address of local variable or temporary: dummy
>    459  #pragma warning( push )
>    460  #pragma warning( disable: 4172 )
>    461  #endif
>    462  address os::current_stack_pointer() {
>    463    int dummy;
>    464    address sp = (address)&dummy;
>    465    return sp;
>    466  }
>    467  #if defined(_MSC_VER) && _MSC_VER >= 1900
>    468  #pragma warning( pop )
>    469  #endif
>    470  #else
>    471  // Returns the current stack pointer. Accurate value needed for
>    472  // os::verify_stack_alignment().
>    473  address os::current_stack_pointer() {
>    474    typedef address get_sp_func();
>    475    get_sp_func* func = CAST_TO_FN_PTR(get_sp_func*,
>    476 StubRoutines::x86::get_previous_sp_entry());
>    477    return (*func)();
>    478  }
>    479  #endif
>    480
> 
> 
> 
> 
> On 06/07/2018 21:09, Kim Barrett wrote:
>>> On Jul 6, 2018, at 5:54 AM, Kevin Walls <kevin.walls at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I'd like to get a review of this change for 8u:
>>> 
>>> 8206454: [8u] os::current_stack_pointer() fails to compile on later Windows compilers (warning C4172: returning address of local variable)
>>> https://bugs.openjdk.java.net/browse/JDK-8206454
>>> 
>>> This is part of getting jdk8u to accept later Windows compilers. Not changing the code, but adding a conditional  #pragma to let the compiler accept the code.
>> Why is this only being done for jdk8u, and why isn?t it a problem in (say) jdk11 or jdk12?
>> The code being patched below is still the same.
>> 
>>> I'll include a diff in text below (can do a webrev if anybody would like one...).
>>> 
>>> Many thanks!
>>> Kevin
>>> 
>>> 
>>> bash-4.2$ hg diff src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>> diff -r 5792d995ed26 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>> --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp      Wed Jun 27 03:04:33 2018 -0700
>>> +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp      Fri Jul 06 02:46:48 2018 -0700
>>> @@ -454,11 +454,19 @@
>>>  // Returns an estimate of the current stack pointer. Result must be guaranteed
>>>  // to point into the calling threads stack, and be no lower than the current
>>>  // stack pointer.
>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>> +// warning C4172: returning address of local variable or temporary: dummy
>>> +#pragma warning( push )
>>> +#pragma warning( disable: 4172 )
>>> +#endif
>>>  address os::current_stack_pointer() {
>>>    int dummy;
>>>    address sp = (address)&dummy;
>>>    return sp;
>>>  }
>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>> +#pragma warning( pop )
>>> +#endif
>>>  #else
>>>  // Returns the current stack pointer. Accurate value needed for
>>>  // os::verify_stack_alignment().



From kevin.walls at oracle.com  Sat Jul  7 07:22:51 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Sat, 7 Jul 2018 08:22:51 +0100
Subject: RFR: 8206454: [8u] os::current_stack_pointer() fails to compile
 on later Windows compilers (warning C4172: returning address of local
 variable)
In-Reply-To: <A3A75A0C-215E-4F05-A91C-01EFA719273F@oracle.com>
References: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>
 <279CBF76-F9F1-4E1F-833C-BACE01CFD51B@oracle.com>
 <fdfc8bcc-b5f9-527e-98a5-cd518e5a00ec@oracle.com>
 <A3A75A0C-215E-4F05-A91C-01EFA719273F@oracle.com>
Message-ID: <5cdef795-aea1-7238-46a7-c1fb42a8849c@oracle.com>

No problem!? Thanks for bringing this up for clarification.


On 06/07/2018 23:32, Kim Barrett wrote:
>> On Jul 6, 2018, at 4:37 PM, Kevin Walls <kevin.walls at oracle.com> wrote:
>>
>> Hi Kim -
>>
>> Good question. 8-)  Yes the same code is there in the latest version when I looked, but address os::current_stack_pointer() is within an #ifndef AMD64, so I suspect have we never built 32-bit with the later VS2017 compiler?
> Oh, you are right.  I mis-read that as #ifdef AMD64.
>
> Yeah, we (Oracle) don?t seem to be doing 32bit Windows builds anymore.  Presumably
> nobody else is doing so with recent versions of VS and the JDK, else the problem would
> have already been known (and probably dealt with).  Since I?m not a big fan of adding
> untested code, I?m okay with just addressing this in jdk8u, and leaving the current code
> alone until someone complains about it.
>
> Unfortunately, while this change looks okay to me, I?m not even a committer for jdk8,
> so you still need a Reviewer.
>
>> More file context around the 8u suggestion below..
>>
>> Thanks
>> Kevin
>>
>> src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>
>>     452
>>     453  #ifndef AMD64
>>     454  // Returns an estimate of the current stack pointer. Result must be guaranteed
>>     455  // to point into the calling threads stack, and be no lower than the current
>>     456  // stack pointer.
>>     457  #if defined(_MSC_VER) && _MSC_VER >= 1900
>>     458  // warning C4172: returning address of local variable or temporary: dummy
>>     459  #pragma warning( push )
>>     460  #pragma warning( disable: 4172 )
>>     461  #endif
>>     462  address os::current_stack_pointer() {
>>     463    int dummy;
>>     464    address sp = (address)&dummy;
>>     465    return sp;
>>     466  }
>>     467  #if defined(_MSC_VER) && _MSC_VER >= 1900
>>     468  #pragma warning( pop )
>>     469  #endif
>>     470  #else
>>     471  // Returns the current stack pointer. Accurate value needed for
>>     472  // os::verify_stack_alignment().
>>     473  address os::current_stack_pointer() {
>>     474    typedef address get_sp_func();
>>     475    get_sp_func* func = CAST_TO_FN_PTR(get_sp_func*,
>>     476 StubRoutines::x86::get_previous_sp_entry());
>>     477    return (*func)();
>>     478  }
>>     479  #endif
>>     480
>>
>>
>>
>>
>> On 06/07/2018 21:09, Kim Barrett wrote:
>>>> On Jul 6, 2018, at 5:54 AM, Kevin Walls <kevin.walls at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'd like to get a review of this change for 8u:
>>>>
>>>> 8206454: [8u] os::current_stack_pointer() fails to compile on later Windows compilers (warning C4172: returning address of local variable)
>>>> https://bugs.openjdk.java.net/browse/JDK-8206454
>>>>
>>>> This is part of getting jdk8u to accept later Windows compilers. Not changing the code, but adding a conditional  #pragma to let the compiler accept the code.
>>> Why is this only being done for jdk8u, and why isn?t it a problem in (say) jdk11 or jdk12?
>>> The code being patched below is still the same.
>>>
>>>> I'll include a diff in text below (can do a webrev if anybody would like one...).
>>>>
>>>> Many thanks!
>>>> Kevin
>>>>
>>>>
>>>> bash-4.2$ hg diff src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>> diff -r 5792d995ed26 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>> --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp      Wed Jun 27 03:04:33 2018 -0700
>>>> +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp      Fri Jul 06 02:46:48 2018 -0700
>>>> @@ -454,11 +454,19 @@
>>>>   // Returns an estimate of the current stack pointer. Result must be guaranteed
>>>>   // to point into the calling threads stack, and be no lower than the current
>>>>   // stack pointer.
>>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>>> +// warning C4172: returning address of local variable or temporary: dummy
>>>> +#pragma warning( push )
>>>> +#pragma warning( disable: 4172 )
>>>> +#endif
>>>>   address os::current_stack_pointer() {
>>>>     int dummy;
>>>>     address sp = (address)&dummy;
>>>>     return sp;
>>>>   }
>>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>>> +#pragma warning( pop )
>>>> +#endif
>>>>   #else
>>>>   // Returns the current stack pointer. Accurate value needed for
>>>>   // os::verify_stack_alignment().
>


From bsrbnd at gmail.com  Sun Jul  8 10:25:05 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Sun, 8 Jul 2018 12:25:05 +0200
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
 <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
 <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>
Message-ID: <CAEgw74BwRtRER_d7_ymdaRGTsbgp90mYPkO3mfa0aDhXHVBUHQ@mail.gmail.com>

On 6 July 2018 at 20:50, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> On 6 July 2018 at 02:31, David Holmes <david.holmes at oracle.com> wrote:
>
> snip...
>
>>
>>
>> There's no JFR in the open in 8u, but I would expect this to still cause the
>> same problem for Oracle's 8u JDK.
>>
>
> Ok, there's not really much I can do to test this then?
>
>
> snip...
>
>>>
>>>> I'd be inclined to disable the build warning for 8u rather than make code
>>>> changes (which will likely still break JFR).
>>>
>>>
>>> This was my first inclination - and it's what we went with for OpenJDK
>>> 7 [0] [1] -
>>> but it brings its own problems. The way it was disabled at first uses
>>> inline
>>> pragmas that don't work with older versions of GCC that are used to build
>>> 8. Moving the pragma outside the function is problematic because this is
>>> an
>>> inline header file.
>>
>>
>> It's never easy is it. :(
>>
>
> Shall I propose this fix instead then?

Note that I also provided a variant of the fix only in 'os::readdir'
which shouldn't break JFR:

https://bugs.openjdk.java.net/secure/attachment/76645/os_readdir2.patch

Maybe this could make it for 8u?
Bernard


>> Cheers,
>> David
>>
>>
>>>>
>>>> David
>>>>
>>>>
>>>
>>> [0] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/66e04addced6
>>> [1] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/819d329e1fd0
>>>
>>
>
>
>
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Web Site: http://fuseyism.com
> Twitter: https://twitter.com/gnu_andrew_java
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From kim.barrett at oracle.com  Sun Jul  8 16:00:15 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sun, 8 Jul 2018 12:00:15 -0400
Subject: RFR[12]: 8204834: Fix confusing "allocate" naming in OopStorage 
Message-ID: <C1844510-BADC-4E80-B1F2-525461568582@oracle.com>

Please review this nomenclature change in the implementation of
OopStorage.  This is a followup to JDK-8204097; in the review of that
change Coleen noted that some names were confusing, especially
"allocate_list()", which is an accessor and doesn't allocate anything!

This is a mostly mechanical change:

AllocateList => AllocationList  
_allocate_list => _allocation_list 
allocate_list() => allocation_list()  

AllocateEntry => AllocationListEntry
_allocate_entry => _allocation_list_entry
allocate_entry() => allocation_list_entry()

_allocate_mutex => _allocation_mutex

There are a few non-mechanical changes in comments, to make the
comments consistently use the same names as the code.  For example,
some underscores were added when referring to members in comments.
Also fixed a few related typos.

CR:
https://bugs.openjdk.java.net/browse/JDK-8204834

Webrev:
http://cr.openjdk.java.net/~kbarrett/8204834/open.00/

Testing:
mach5 tier1


From david.holmes at oracle.com  Mon Jul  9 00:35:07 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Jul 2018 10:35:07 +1000
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <CAEgw74BwRtRER_d7_ymdaRGTsbgp90mYPkO3mfa0aDhXHVBUHQ@mail.gmail.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
 <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
 <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>
 <CAEgw74BwRtRER_d7_ymdaRGTsbgp90mYPkO3mfa0aDhXHVBUHQ@mail.gmail.com>
Message-ID: <53b265f2-902f-8754-d50b-92693fd8ce27@oracle.com>



On 8/07/2018 8:25 PM, B. Blaser wrote:
> On 6 July 2018 at 20:50, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>> On 6 July 2018 at 02:31, David Holmes <david.holmes at oracle.com> wrote:
>>
>> snip...
>>
>>>
>>>
>>> There's no JFR in the open in 8u, but I would expect this to still cause the
>>> same problem for Oracle's 8u JDK.
>>>
>>
>> Ok, there's not really much I can do to test this then?
>>
>>
>> snip...
>>
>>>>
>>>>> I'd be inclined to disable the build warning for 8u rather than make code
>>>>> changes (which will likely still break JFR).
>>>>
>>>>
>>>> This was my first inclination - and it's what we went with for OpenJDK
>>>> 7 [0] [1] -
>>>> but it brings its own problems. The way it was disabled at first uses
>>>> inline
>>>> pragmas that don't work with older versions of GCC that are used to build
>>>> 8. Moving the pragma outside the function is problematic because this is
>>>> an
>>>> inline header file.
>>>
>>>
>>> It's never easy is it. :(
>>>
>>
>> Shall I propose this fix instead then?
> 
> Note that I also provided a variant of the fix only in 'os::readdir'
> which shouldn't break JFR:
> 
> https://bugs.openjdk.java.net/secure/attachment/76645/os_readdir2.patch
> 
> Maybe this could make it for 8u?

This is linux specific code but it seems to be using internal knowledge 
of how a struct dirent is laid out on Linux. I'd also have to ensure 
this gets tested with JFR on 8u.

I'll leave it to Andrew to decide on the above fix, or the makefile 
warning fix. I'll Review whichever is chosen.

Thanks,
David

> Bernard
> 
> 
>>> Cheers,
>>> David
>>>
>>>
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>
>>>> [0] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/66e04addced6
>>>> [1] http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/819d329e1fd0
>>>>
>>>
>>
>>
>>
>> --
>> Andrew :)
>>
>> Senior Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Web Site: http://fuseyism.com
>> Twitter: https://twitter.com/gnu_andrew_java
>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From david.holmes at oracle.com  Mon Jul  9 02:38:15 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Jul 2018 12:38:15 +1000
Subject: RFR: 8206454: [8u] os::current_stack_pointer() fails to compile
 on later Windows compilers (warning C4172: returning address of local
 variable)
In-Reply-To: <5cdef795-aea1-7238-46a7-c1fb42a8849c@oracle.com>
References: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>
 <279CBF76-F9F1-4E1F-833C-BACE01CFD51B@oracle.com>
 <fdfc8bcc-b5f9-527e-98a5-cd518e5a00ec@oracle.com>
 <A3A75A0C-215E-4F05-A91C-01EFA719273F@oracle.com>
 <5cdef795-aea1-7238-46a7-c1fb42a8849c@oracle.com>
Message-ID: <72c0f2d2-1666-95f8-27f7-6251b357e998@oracle.com>

Hi Kevin,

I note we currently never use push/pop on Windows, rather we use the 
pattern:

#pragma warning( disable : NNN )
<code>
#pragma warning( default : NNN )

Do older 8u compilers support the push/pop pragma warning capability?

Thanks,
David

On 7/07/2018 5:22 PM, Kevin Walls wrote:
> No problem!? Thanks for bringing this up for clarification.
> 
> 
> On 06/07/2018 23:32, Kim Barrett wrote:
>>> On Jul 6, 2018, at 4:37 PM, Kevin Walls <kevin.walls at oracle.com> wrote:
>>>
>>> Hi Kim -
>>>
>>> Good question. 8-)? Yes the same code is there in the latest version 
>>> when I looked, but address os::current_stack_pointer() is within an 
>>> #ifndef AMD64, so I suspect have we never built 32-bit with the later 
>>> VS2017 compiler?
>> Oh, you are right.? I mis-read that as #ifdef AMD64.
>>
>> Yeah, we (Oracle) don?t seem to be doing 32bit Windows builds 
>> anymore.? Presumably
>> nobody else is doing so with recent versions of VS and the JDK, else 
>> the problem would
>> have already been known (and probably dealt with).? Since I?m not a 
>> big fan of adding
>> untested code, I?m okay with just addressing this in jdk8u, and 
>> leaving the current code
>> alone until someone complains about it.
>>
>> Unfortunately, while this change looks okay to me, I?m not even a 
>> committer for jdk8,
>> so you still need a Reviewer.
>>
>>> More file context around the 8u suggestion below..
>>>
>>> Thanks
>>> Kevin
>>>
>>> src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>
>>> ??? 452
>>> ??? 453? #ifndef AMD64
>>> ??? 454? // Returns an estimate of the current stack pointer. Result 
>>> must be guaranteed
>>> ??? 455? // to point into the calling threads stack, and be no lower 
>>> than the current
>>> ??? 456? // stack pointer.
>>> ??? 457? #if defined(_MSC_VER) && _MSC_VER >= 1900
>>> ??? 458? // warning C4172: returning address of local variable or 
>>> temporary: dummy
>>> ??? 459? #pragma warning( push )
>>> ??? 460? #pragma warning( disable: 4172 )
>>> ??? 461? #endif
>>> ??? 462? address os::current_stack_pointer() {
>>> ??? 463??? int dummy;
>>> ??? 464??? address sp = (address)&dummy;
>>> ??? 465??? return sp;
>>> ??? 466? }
>>> ??? 467? #if defined(_MSC_VER) && _MSC_VER >= 1900
>>> ??? 468? #pragma warning( pop )
>>> ??? 469? #endif
>>> ??? 470? #else
>>> ??? 471? // Returns the current stack pointer. Accurate value needed for
>>> ??? 472? // os::verify_stack_alignment().
>>> ??? 473? address os::current_stack_pointer() {
>>> ??? 474??? typedef address get_sp_func();
>>> ??? 475??? get_sp_func* func = CAST_TO_FN_PTR(get_sp_func*,
>>> ??? 476 StubRoutines::x86::get_previous_sp_entry());
>>> ??? 477??? return (*func)();
>>> ??? 478? }
>>> ??? 479? #endif
>>> ??? 480
>>>
>>>
>>>
>>>
>>> On 06/07/2018 21:09, Kim Barrett wrote:
>>>>> On Jul 6, 2018, at 5:54 AM, Kevin Walls <kevin.walls at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'd like to get a review of this change for 8u:
>>>>>
>>>>> 8206454: [8u] os::current_stack_pointer() fails to compile on later 
>>>>> Windows compilers (warning C4172: returning address of local variable)
>>>>> https://bugs.openjdk.java.net/browse/JDK-8206454
>>>>>
>>>>> This is part of getting jdk8u to accept later Windows compilers. 
>>>>> Not changing the code, but adding a conditional? #pragma to let the 
>>>>> compiler accept the code.
>>>> Why is this only being done for jdk8u, and why isn?t it a problem in 
>>>> (say) jdk11 or jdk12?
>>>> The code being patched below is still the same.
>>>>
>>>>> I'll include a diff in text below (can do a webrev if anybody would 
>>>>> like one...).
>>>>>
>>>>> Many thanks!
>>>>> Kevin
>>>>>
>>>>>
>>>>> bash-4.2$ hg diff src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>>> diff -r 5792d995ed26 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>>> --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp????? Wed Jun 27 
>>>>> 03:04:33 2018 -0700
>>>>> +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp????? Fri Jul 06 
>>>>> 02:46:48 2018 -0700
>>>>> @@ -454,11 +454,19 @@
>>>>> ? // Returns an estimate of the current stack pointer. Result must 
>>>>> be guaranteed
>>>>> ? // to point into the calling threads stack, and be no lower than 
>>>>> the current
>>>>> ? // stack pointer.
>>>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>>>> +// warning C4172: returning address of local variable or 
>>>>> temporary: dummy
>>>>> +#pragma warning( push )
>>>>> +#pragma warning( disable: 4172 )
>>>>> +#endif
>>>>> ? address os::current_stack_pointer() {
>>>>> ??? int dummy;
>>>>> ??? address sp = (address)&dummy;
>>>>> ??? return sp;
>>>>> ? }
>>>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>>>> +#pragma warning( pop )
>>>>> +#endif
>>>>> ? #else
>>>>> ? // Returns the current stack pointer. Accurate value needed for
>>>>> ? // os::verify_stack_alignment().
>>
> 

From david.holmes at oracle.com  Mon Jul  9 04:08:22 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Jul 2018 14:08:22 +1000
Subject: RFR: 8205677: [8u] casts and type change for 8u to enable later
 Windows compilers
In-Reply-To: <0150c644-5b70-84ff-0ee7-3874e4318e6a@oracle.com>
References: <10a72c45-c34a-599a-b771-08d5a7083c62@oracle.com>
 <0150c644-5b70-84ff-0ee7-3874e4318e6a@oracle.com>
Message-ID: <1e4b6a41-e782-05c4-429a-12229d2acf3a@oracle.com>

Hi Kevin,

All seems fine. One comment below.

On 6/07/2018 10:27 PM, Kevin Walls wrote:
> Hi,
> 
> I'd like to update my review request:
> 
> Item #3, was solved by 8150426 so no change required.
> 
> Item #5, changing the return type of the method is not necessary.? The 
> error was in src/share/vm/runtime/memprofiler.cpp and can be solved with 
> a cast on the offending line.? The result of a long divided by a size_t 
> can be cast to a long, and that minimal change is? accepted in all the 
> builds:
> 
> -????????? OopMapCache::memory_usage() / K);
> +????????? (long) (OopMapCache::memory_usage() / K));

I actually thing the correct thing to do is change the return type. We 
should generally never use a raw C long in hotspot due to its varying 
size depending on platform (ILP32, LP64, LLP64). But that goes beyond 
addressing a compiler warning.

Thanks,
David

> Additionally, I've uncovered one more required cast, so item #6 is 
> src/share/vm/classfile/classFileParser.cpp changing an (int) cast to a 
> (u2).
> 
> New webrev at http://cr.openjdk.java.net/~kevinw/8205677/webrev.01/
> 
> Progress report: with these changes, 8206454 which I just put out for 
> review, and one other change re: vnsprintf, the open jdk8u builds with 
> VS2017.
> 
> Many thanks!
> Kevin
> 
> 
> 
> 
> 
> On 05/07/2018 09:46, Kevin Walls wrote:
>> Hi,
>>
>> I'd like to get a review of:
>>
>> 8205677: [8u] casts and type change for 8u to enable later Windows 
>> compilers
>> https://bugs.openjdk.java.net/browse/JDK-8205677
>>
>> This is a collection of new small changes aiming to permit 8u to build 
>> with later Windows compilers (and also with the current VS2010).
>>
>> The changes are:
>>
>> 8u webrev: http://cr.openjdk.java.net/~kevinw/8205677/webrev.00/
>>
>> Notes:
>>
>> 1
>> hotspot\src\share\vm\classfile\altHashing.cpp(227): warning C4838: 
>> conversion from 'unsigned int' to 'const jint' requires a narrowing 
>> conversion
>>
>> (jint) casts are present in the later JDK 
>> test/hotspot/gtest/classfile/test_AltHashing.cpp and look like they 
>> were in JDK9 from the start.
>>
>> 2
>> hotspot\src\share\vm\gc_implementation\parallelScavenge\gcTaskManager.cpp(1038): 
>> warning C4312: 'type cast': conversion from 'unsigned int' to 'Monitor 
>> *' of greater size
>>
>> -? _monitor = (Monitor*) 0xDEAD000F;
>> +? _monitor = (Monitor*) (uintptr_t) 0xDEAD000F;
>>
>> 3
>> ..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): error C2440: '=': 
>> cannot convert from 'jlong' to 'jlong *'
>> ..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): note: Conversion 
>> from integral type to pointer type requires reinterpret_cast, C-style 
>> cast or function-style cast
>>
>> -??? *long_at_addr(which) = (long)contents;
>> +??? *long_at_addr(which) = (jlong)contents;
>>
>>
>> 4
>> ...\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepGeneration.cpp(6833): 
>> warning C4334: '<<': result of 32-bit shift implicitly converted to 64 
>> bits (was 64-bit shift intended?)
>>
>> Like in 8197864 where we cast a 1 to an intptr_t before the shift.
>>
>> ?? assert(mr.end() == (HeapWord*)round_to((intptr_t)mr.end(),
>> -??????????????????????? (1 << (_shifter+LogHeapWordSize))),
>> +??????????????????????? ((intptr_t) 1 << (_shifter+LogHeapWordSize))),
>>
>>
>> 5
>> hotspot\src\share\vm\runtime\memprofiler.cpp(129): warning C4477: 
>> 'fprintf' : format string '%6ld' requires an argument of type 'long', 
>> but variadic argument 3 has type '::size_t'
>>
>> OopMapCache::memory_size() is only used in one place, and only when 
>> NOTPRODUCT.? Here in 8u, we can make it return a size_t and compile 
>> without error.
>>
>> In jdk10 onwards, after 8186042, this line in memprofiler.cpp 
>> hard-codes a 0L instead of OopMapCache::memory_size(), as the tracking 
>> of _total_memory_size was removed, but the print was kept to the same 
>> format.? I don't think we would remove that statistic in an update
>>
>>
>> Thanks
>> Kevin
>>
>>
>>
>>
>>
>>
>>
> 

From david.holmes at oracle.com  Mon Jul  9 04:12:40 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Jul 2018 14:12:40 +1000
Subject: RFR[12]: 8204834: Fix confusing "allocate" naming in OopStorage
In-Reply-To: <C1844510-BADC-4E80-B1F2-525461568582@oracle.com>
References: <C1844510-BADC-4E80-B1F2-525461568582@oracle.com>
Message-ID: <fd3b2823-3031-825d-90cd-b178cbf21e50@oracle.com>

That seems fine to me Kim.

Thanks,
David

On 9/07/2018 2:00 AM, Kim Barrett wrote:
> Please review this nomenclature change in the implementation of
> OopStorage.  This is a followup to JDK-8204097; in the review of that
> change Coleen noted that some names were confusing, especially
> "allocate_list()", which is an accessor and doesn't allocate anything!
> 
> This is a mostly mechanical change:
> 
> AllocateList => AllocationList
> _allocate_list => _allocation_list
> allocate_list() => allocation_list()
> 
> AllocateEntry => AllocationListEntry
> _allocate_entry => _allocation_list_entry
> allocate_entry() => allocation_list_entry()
> 
> _allocate_mutex => _allocation_mutex
> 
> There are a few non-mechanical changes in comments, to make the
> comments consistently use the same names as the code.  For example,
> some underscores were added when referring to members in comments.
> Also fixed a few related typos.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8204834
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8204834/open.00/
> 
> Testing:
> mach5 tier1
> 

From thomas.schatzl at oracle.com  Mon Jul  9 08:47:58 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 09 Jul 2018 10:47:58 +0200
Subject: RFR[12]: 8204834: Fix confusing "allocate" naming in OopStorage
In-Reply-To: <C1844510-BADC-4E80-B1F2-525461568582@oracle.com>
References: <C1844510-BADC-4E80-B1F2-525461568582@oracle.com>
Message-ID: <b2f7f5c92047c0bdf556f2b33794054a71462919.camel@oracle.com>

Hi,

On Sun, 2018-07-08 at 12:00 -0400, Kim Barrett wrote:
> Please review this nomenclature change in the implementation of
> OopStorage.  This is a followup to JDK-8204097; in the review of that
> change Coleen noted that some names were confusing, especially
> "allocate_list()", which is an accessor and doesn't allocate
> anything!
> 
> This is a mostly mechanical change:
> 
[...]
>
> There are a few non-mechanical changes in comments, to make the
> comments consistently use the same names as the code.  For example,
> some underscores were added when referring to members in comments.
> Also fixed a few related typos.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8204834
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8204834/open.00/
> 

  looks good to me.

Thomas


From kevin.walls at oracle.com  Mon Jul  9 11:00:38 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 9 Jul 2018 12:00:38 +0100
Subject: RFR: 8206454: [8u] os::current_stack_pointer() fails to compile
 on later Windows compilers (warning C4172: returning address of local
 variable)
In-Reply-To: <72c0f2d2-1666-95f8-27f7-6251b357e998@oracle.com>
References: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>
 <279CBF76-F9F1-4E1F-833C-BACE01CFD51B@oracle.com>
 <fdfc8bcc-b5f9-527e-98a5-cd518e5a00ec@oracle.com>
 <A3A75A0C-215E-4F05-A91C-01EFA719273F@oracle.com>
 <5cdef795-aea1-7238-46a7-c1fb42a8849c@oracle.com>
 <72c0f2d2-1666-95f8-27f7-6251b357e998@oracle.com>
Message-ID: <3c7579aa-ba25-7580-eeae-1b3115d01db9@oracle.com>


Hi David, sure no problem we can do the "default" after the code we want 
to affect here.

I only wanted to put the #pragma within the #if for compiler level, not 
to change what the older compiler does.? (I have (now) run the existing 
VS2010 build always doing the #pragma, and also using the push/pop, and 
they are all OK too.? I'd still like to go with with the condition and 
not change anything about existing builds.)

Updated diff below.

Thanks!
Kevin

bash-4.2$ hg diff
diff -r ad057f2e3211 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
--- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp????? Wed Jul 04 
03:02:43 2018 -0400
+++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp????? Mon Jul 09 
01:10:18 2018 -0700
@@ -454,11 +454,18 @@
 ?// Returns an estimate of the current stack pointer. Result must be 
guaranteed
 ?// to point into the calling threads stack, and be no lower than the 
current
 ?// stack pointer.
+#if defined(_MSC_VER) && _MSC_VER >= 1900
+// warning C4172: returning address of local variable or temporary: dummy
+#pragma warning(disable: 4172)
+#endif
 ?address os::current_stack_pointer() {
 ?? int dummy;
 ?? address sp = (address)&dummy;
 ?? return sp;
 ?}
+#if defined(_MSC_VER) && _MSC_VER >= 1900
+#pragma warning(default: 4172)
+#endif
 ?#else
 ?// Returns the current stack pointer. Accurate value needed for
 ?// os::verify_stack_alignment().




On 09/07/2018 03:38, David Holmes wrote:
> Hi Kevin,
>
> I note we currently never use push/pop on Windows, rather we use the 
> pattern:
>
> #pragma warning( disable : NNN )
> <code>
> #pragma warning( default : NNN )
>
> Do older 8u compilers support the push/pop pragma warning capability?
>
> Thanks,
> David
>
> On 7/07/2018 5:22 PM, Kevin Walls wrote:
>> No problem!? Thanks for bringing this up for clarification.
>>
>>
>> On 06/07/2018 23:32, Kim Barrett wrote:
>>>> On Jul 6, 2018, at 4:37 PM, Kevin Walls <kevin.walls at oracle.com> 
>>>> wrote:
>>>>
>>>> Hi Kim -
>>>>
>>>> Good question. 8-)? Yes the same code is there in the latest 
>>>> version when I looked, but address os::current_stack_pointer() is 
>>>> within an #ifndef AMD64, so I suspect have we never built 32-bit 
>>>> with the later VS2017 compiler?
>>> Oh, you are right.? I mis-read that as #ifdef AMD64.
>>>
>>> Yeah, we (Oracle) don?t seem to be doing 32bit Windows builds 
>>> anymore.? Presumably
>>> nobody else is doing so with recent versions of VS and the JDK, else 
>>> the problem would
>>> have already been known (and probably dealt with).? Since I?m not a 
>>> big fan of adding
>>> untested code, I?m okay with just addressing this in jdk8u, and 
>>> leaving the current code
>>> alone until someone complains about it.
>>>
>>> Unfortunately, while this change looks okay to me, I?m not even a 
>>> committer for jdk8,
>>> so you still need a Reviewer.
>>>
>>>> More file context around the 8u suggestion below..
>>>>
>>>> Thanks
>>>> Kevin
>>>>
>>>> src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>>
>>>> ??? 452
>>>> ??? 453? #ifndef AMD64
>>>> ??? 454? // Returns an estimate of the current stack pointer. 
>>>> Result must be guaranteed
>>>> ??? 455? // to point into the calling threads stack, and be no 
>>>> lower than the current
>>>> ??? 456? // stack pointer.
>>>> ??? 457? #if defined(_MSC_VER) && _MSC_VER >= 1900
>>>> ??? 458? // warning C4172: returning address of local variable or 
>>>> temporary: dummy
>>>> ??? 459? #pragma warning( push )
>>>> ??? 460? #pragma warning( disable: 4172 )
>>>> ??? 461? #endif
>>>> ??? 462? address os::current_stack_pointer() {
>>>> ??? 463??? int dummy;
>>>> ??? 464??? address sp = (address)&dummy;
>>>> ??? 465??? return sp;
>>>> ??? 466? }
>>>> ??? 467? #if defined(_MSC_VER) && _MSC_VER >= 1900
>>>> ??? 468? #pragma warning( pop )
>>>> ??? 469? #endif
>>>> ??? 470? #else
>>>> ??? 471? // Returns the current stack pointer. Accurate value 
>>>> needed for
>>>> ??? 472? // os::verify_stack_alignment().
>>>> ??? 473? address os::current_stack_pointer() {
>>>> ??? 474??? typedef address get_sp_func();
>>>> ??? 475??? get_sp_func* func = CAST_TO_FN_PTR(get_sp_func*,
>>>> ??? 476 StubRoutines::x86::get_previous_sp_entry());
>>>> ??? 477??? return (*func)();
>>>> ??? 478? }
>>>> ??? 479? #endif
>>>> ??? 480
>>>>
>>>>
>>>>
>>>>
>>>> On 06/07/2018 21:09, Kim Barrett wrote:
>>>>>> On Jul 6, 2018, at 5:54 AM, Kevin Walls <kevin.walls at oracle.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to get a review of this change for 8u:
>>>>>>
>>>>>> 8206454: [8u] os::current_stack_pointer() fails to compile on 
>>>>>> later Windows compilers (warning C4172: returning address of 
>>>>>> local variable)
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206454
>>>>>>
>>>>>> This is part of getting jdk8u to accept later Windows compilers. 
>>>>>> Not changing the code, but adding a conditional? #pragma to let 
>>>>>> the compiler accept the code.
>>>>> Why is this only being done for jdk8u, and why isn?t it a problem 
>>>>> in (say) jdk11 or jdk12?
>>>>> The code being patched below is still the same.
>>>>>
>>>>>> I'll include a diff in text below (can do a webrev if anybody 
>>>>>> would like one...).
>>>>>>
>>>>>> Many thanks!
>>>>>> Kevin
>>>>>>
>>>>>>
>>>>>> bash-4.2$ hg diff src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>>>> diff -r 5792d995ed26 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>>>> --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp Wed Jun 27 
>>>>>> 03:04:33 2018 -0700
>>>>>> +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp Fri Jul 06 
>>>>>> 02:46:48 2018 -0700
>>>>>> @@ -454,11 +454,19 @@
>>>>>> ? // Returns an estimate of the current stack pointer. Result 
>>>>>> must be guaranteed
>>>>>> ? // to point into the calling threads stack, and be no lower 
>>>>>> than the current
>>>>>> ? // stack pointer.
>>>>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>>>>> +// warning C4172: returning address of local variable or 
>>>>>> temporary: dummy
>>>>>> +#pragma warning( push )
>>>>>> +#pragma warning( disable: 4172 )
>>>>>> +#endif
>>>>>> ? address os::current_stack_pointer() {
>>>>>> ??? int dummy;
>>>>>> ??? address sp = (address)&dummy;
>>>>>> ??? return sp;
>>>>>> ? }
>>>>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>>>>> +#pragma warning( pop )
>>>>>> +#endif
>>>>>> ? #else
>>>>>> ? // Returns the current stack pointer. Accurate value needed for
>>>>>> ? // os::verify_stack_alignment().
>>>
>>


From david.holmes at oracle.com  Mon Jul  9 11:19:57 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Jul 2018 21:19:57 +1000
Subject: RFR: 8206454: [8u] os::current_stack_pointer() fails to compile
 on later Windows compilers (warning C4172: returning address of local
 variable)
In-Reply-To: <3c7579aa-ba25-7580-eeae-1b3115d01db9@oracle.com>
References: <a5023ffe-3e7b-4dfd-a70c-23995093c3be@oracle.com>
 <279CBF76-F9F1-4E1F-833C-BACE01CFD51B@oracle.com>
 <fdfc8bcc-b5f9-527e-98a5-cd518e5a00ec@oracle.com>
 <A3A75A0C-215E-4F05-A91C-01EFA719273F@oracle.com>
 <5cdef795-aea1-7238-46a7-c1fb42a8849c@oracle.com>
 <72c0f2d2-1666-95f8-27f7-6251b357e998@oracle.com>
 <3c7579aa-ba25-7580-eeae-1b3115d01db9@oracle.com>
Message-ID: <cb6f0e52-ce07-8bc9-7e2c-1742da85e4ee@oracle.com>

Hi Kevin,

On 9/07/2018 9:00 PM, Kevin Walls wrote:
> 
> Hi David, sure no problem we can do the "default" after the code we want 
> to affect here.

Okay if that works then that seems fine.

Thanks,
David

> I only wanted to put the #pragma within the #if for compiler level, not 
> to change what the older compiler does.? (I have (now) run the existing 
> VS2010 build always doing the #pragma, and also using the push/pop, and 
> they are all OK too.? I'd still like to go with with the condition and 
> not change anything about existing builds.)
> 
> Updated diff below.
> 
> Thanks!
> Kevin
> 
> bash-4.2$ hg diff
> diff -r ad057f2e3211 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
> --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp????? Wed Jul 04 
> 03:02:43 2018 -0400
> +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp????? Mon Jul 09 
> 01:10:18 2018 -0700
> @@ -454,11 +454,18 @@
>  ?// Returns an estimate of the current stack pointer. Result must be 
> guaranteed
>  ?// to point into the calling threads stack, and be no lower than the 
> current
>  ?// stack pointer.
> +#if defined(_MSC_VER) && _MSC_VER >= 1900
> +// warning C4172: returning address of local variable or temporary: dummy
> +#pragma warning(disable: 4172)
> +#endif
>  ?address os::current_stack_pointer() {
>  ?? int dummy;
>  ?? address sp = (address)&dummy;
>  ?? return sp;
>  ?}
> +#if defined(_MSC_VER) && _MSC_VER >= 1900
> +#pragma warning(default: 4172)
> +#endif
>  ?#else
>  ?// Returns the current stack pointer. Accurate value needed for
>  ?// os::verify_stack_alignment().
> 
> 
> 
> 
> On 09/07/2018 03:38, David Holmes wrote:
>> Hi Kevin,
>>
>> I note we currently never use push/pop on Windows, rather we use the 
>> pattern:
>>
>> #pragma warning( disable : NNN )
>> <code>
>> #pragma warning( default : NNN )
>>
>> Do older 8u compilers support the push/pop pragma warning capability?
>>
>> Thanks,
>> David
>>
>> On 7/07/2018 5:22 PM, Kevin Walls wrote:
>>> No problem!? Thanks for bringing this up for clarification.
>>>
>>>
>>> On 06/07/2018 23:32, Kim Barrett wrote:
>>>>> On Jul 6, 2018, at 4:37 PM, Kevin Walls <kevin.walls at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> Hi Kim -
>>>>>
>>>>> Good question. 8-)? Yes the same code is there in the latest 
>>>>> version when I looked, but address os::current_stack_pointer() is 
>>>>> within an #ifndef AMD64, so I suspect have we never built 32-bit 
>>>>> with the later VS2017 compiler?
>>>> Oh, you are right.? I mis-read that as #ifdef AMD64.
>>>>
>>>> Yeah, we (Oracle) don?t seem to be doing 32bit Windows builds 
>>>> anymore.? Presumably
>>>> nobody else is doing so with recent versions of VS and the JDK, else 
>>>> the problem would
>>>> have already been known (and probably dealt with).? Since I?m not a 
>>>> big fan of adding
>>>> untested code, I?m okay with just addressing this in jdk8u, and 
>>>> leaving the current code
>>>> alone until someone complains about it.
>>>>
>>>> Unfortunately, while this change looks okay to me, I?m not even a 
>>>> committer for jdk8,
>>>> so you still need a Reviewer.
>>>>
>>>>> More file context around the 8u suggestion below..
>>>>>
>>>>> Thanks
>>>>> Kevin
>>>>>
>>>>> src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>>>
>>>>> ??? 452
>>>>> ??? 453? #ifndef AMD64
>>>>> ??? 454? // Returns an estimate of the current stack pointer. 
>>>>> Result must be guaranteed
>>>>> ??? 455? // to point into the calling threads stack, and be no 
>>>>> lower than the current
>>>>> ??? 456? // stack pointer.
>>>>> ??? 457? #if defined(_MSC_VER) && _MSC_VER >= 1900
>>>>> ??? 458? // warning C4172: returning address of local variable or 
>>>>> temporary: dummy
>>>>> ??? 459? #pragma warning( push )
>>>>> ??? 460? #pragma warning( disable: 4172 )
>>>>> ??? 461? #endif
>>>>> ??? 462? address os::current_stack_pointer() {
>>>>> ??? 463??? int dummy;
>>>>> ??? 464??? address sp = (address)&dummy;
>>>>> ??? 465??? return sp;
>>>>> ??? 466? }
>>>>> ??? 467? #if defined(_MSC_VER) && _MSC_VER >= 1900
>>>>> ??? 468? #pragma warning( pop )
>>>>> ??? 469? #endif
>>>>> ??? 470? #else
>>>>> ??? 471? // Returns the current stack pointer. Accurate value 
>>>>> needed for
>>>>> ??? 472? // os::verify_stack_alignment().
>>>>> ??? 473? address os::current_stack_pointer() {
>>>>> ??? 474??? typedef address get_sp_func();
>>>>> ??? 475??? get_sp_func* func = CAST_TO_FN_PTR(get_sp_func*,
>>>>> ??? 476 StubRoutines::x86::get_previous_sp_entry());
>>>>> ??? 477??? return (*func)();
>>>>> ??? 478? }
>>>>> ??? 479? #endif
>>>>> ??? 480
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 06/07/2018 21:09, Kim Barrett wrote:
>>>>>>> On Jul 6, 2018, at 5:54 AM, Kevin Walls <kevin.walls at oracle.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'd like to get a review of this change for 8u:
>>>>>>>
>>>>>>> 8206454: [8u] os::current_stack_pointer() fails to compile on 
>>>>>>> later Windows compilers (warning C4172: returning address of 
>>>>>>> local variable)
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206454
>>>>>>>
>>>>>>> This is part of getting jdk8u to accept later Windows compilers. 
>>>>>>> Not changing the code, but adding a conditional? #pragma to let 
>>>>>>> the compiler accept the code.
>>>>>> Why is this only being done for jdk8u, and why isn?t it a problem 
>>>>>> in (say) jdk11 or jdk12?
>>>>>> The code being patched below is still the same.
>>>>>>
>>>>>>> I'll include a diff in text below (can do a webrev if anybody 
>>>>>>> would like one...).
>>>>>>>
>>>>>>> Many thanks!
>>>>>>> Kevin
>>>>>>>
>>>>>>>
>>>>>>> bash-4.2$ hg diff src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>>>>> diff -r 5792d995ed26 src/os_cpu/windows_x86/vm/os_windows_x86.cpp
>>>>>>> --- a/src/os_cpu/windows_x86/vm/os_windows_x86.cpp Wed Jun 27 
>>>>>>> 03:04:33 2018 -0700
>>>>>>> +++ b/src/os_cpu/windows_x86/vm/os_windows_x86.cpp Fri Jul 06 
>>>>>>> 02:46:48 2018 -0700
>>>>>>> @@ -454,11 +454,19 @@
>>>>>>> ? // Returns an estimate of the current stack pointer. Result 
>>>>>>> must be guaranteed
>>>>>>> ? // to point into the calling threads stack, and be no lower 
>>>>>>> than the current
>>>>>>> ? // stack pointer.
>>>>>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>>>>>> +// warning C4172: returning address of local variable or 
>>>>>>> temporary: dummy
>>>>>>> +#pragma warning( push )
>>>>>>> +#pragma warning( disable: 4172 )
>>>>>>> +#endif
>>>>>>> ? address os::current_stack_pointer() {
>>>>>>> ??? int dummy;
>>>>>>> ??? address sp = (address)&dummy;
>>>>>>> ??? return sp;
>>>>>>> ? }
>>>>>>> +#if defined(_MSC_VER) && _MSC_VER >= 1900
>>>>>>> +#pragma warning( pop )
>>>>>>> +#endif
>>>>>>> ? #else
>>>>>>> ? // Returns the current stack pointer. Accurate value needed for
>>>>>>> ? // os::verify_stack_alignment().
>>>>
>>>
> 

From coleen.phillimore at oracle.com  Mon Jul  9 11:37:24 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 9 Jul 2018 07:37:24 -0400
Subject: RFR[12]: 8204834: Fix confusing "allocate" naming in OopStorage
In-Reply-To: <C1844510-BADC-4E80-B1F2-525461568582@oracle.com>
References: <C1844510-BADC-4E80-B1F2-525461568582@oracle.com>
Message-ID: <f2b846ae-698a-058c-e4bc-29bde911e313@oracle.com>


http://cr.openjdk.java.net/~kbarrett/8204834/open.00/src/hotspot/share/gc/shared/oopStorage.inline.hpp.udiff.html

+// Blocks in a AllocationList.

a => an

Thank you for doing this renaming, Kim.? This reads a lot better for me.

Coleen


On 7/8/18 12:00 PM, Kim Barrett wrote:
> Please review this nomenclature change in the implementation of
> OopStorage.  This is a followup to JDK-8204097; in the review of that
> change Coleen noted that some names were confusing, especially
> "allocate_list()", which is an accessor and doesn't allocate anything!
>
> This is a mostly mechanical change:
>
> AllocateList => AllocationList
> _allocate_list => _allocation_list
> allocate_list() => allocation_list()
>
> AllocateEntry => AllocationListEntry
> _allocate_entry => _allocation_list_entry
> allocate_entry() => allocation_list_entry()
>
> _allocate_mutex => _allocation_mutex
>
> There are a few non-mechanical changes in comments, to make the
> comments consistently use the same names as the code.  For example,
> some underscores were added when referring to members in comments.
> Also fixed a few related typos.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8204834
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8204834/open.00/
>
> Testing:
> mach5 tier1
>


From tobias.hartmann at oracle.com  Mon Jul  9 11:58:02 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 9 Jul 2018 13:58:02 +0200
Subject: [11] RFR(S): 8205472: Deadlock in Kitchensink when trying to print
 compile queues causing timeout
Message-ID: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>

Hi,

please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8205472
http://cr.openjdk.java.net/~thartmann/8205472/webrev.00/

When registering a compiled method in ciEnv::register_method() the compiler thread acquires the
MethodCompileQueue_lock and then performs a safepoint check before acquiring the Compile_lock as
well. If we enter a safepoint, the compiler thread is still holding the MethodCompileQueue_lock
while the VM thread may execute the VM_PrintCompileQueue VM operation which requires the
MethodCompileQueue_lock as well. We deadlock.

This bug is very intermittent and I was only able to reproduce it by modifying the VM to always
enter a safepoint (see comments in JIRA). The solution is to not acquire the MethodCompileQueue_lock
in CompileBroker::print_compile_queues() because we only execute that code at a safepoint anyway
(VM_PrintCompileQueue has evaluation_mode() == _safepoint).

Thanks,
Tobias

From aph at redhat.com  Mon Jul  9 13:57:53 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 9 Jul 2018 14:57:53 +0100
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
Message-ID: <3431da70-33bc-d3db-35b7-8208909b8201@redhat.com>

On 06/15/2018 12:55 PM, Zhengyu Gu wrote:
> Ping!!!! anyone? please!

How did you test this?  Do you have code that exercises the interface?
If so, please put it on cr.openjdk.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From rkennke at redhat.com  Mon Jul  9 14:04:47 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 9 Jul 2018 16:04:47 +0200
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <3431da70-33bc-d3db-35b7-8208909b8201@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <3431da70-33bc-d3db-35b7-8208909b8201@redhat.com>
Message-ID: <51cd3a90-f2f3-e714-a0ae-8f9d0619796f@redhat.com>

Am 09.07.2018 um 15:57 schrieb Andrew Haley:
> On 06/15/2018 12:55 PM, Zhengyu Gu wrote:
>> Ping!!!! anyone? please!
> 
> How did you test this?  Do you have code that exercises the interface?
> If so, please put it on cr.openjdk.
> 

We have tests in Shenandoah. We would upstream it, but it requires a GC
that supports pinning. AFAIK, ZGC devs *intend* to support pinning, and
for G1 it should be easy as well. But it's not there yet.

This is the test:
http://hg.openjdk.java.net/shenandoah/jdk/file/266e6a543eaa/test/hotspot/jtreg/gc/shenandoah/CriticalNativeStress.java

Zhengyu: do you see a way to test this even without a supporting GC?

Roman


From zgu at redhat.com  Mon Jul  9 14:17:14 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 9 Jul 2018 10:17:14 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <3431da70-33bc-d3db-35b7-8208909b8201@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <3431da70-33bc-d3db-35b7-8208909b8201@redhat.com>
Message-ID: <9ea85ace-fe7a-b608-5613-0b0520dde253@redhat.com>

Hi Andrew,

On 07/09/2018 09:57 AM, Andrew Haley wrote:
> On 06/15/2018 12:55 PM, Zhengyu Gu wrote:
>> Ping!!!! anyone? please!
> 
> How did you test this?  Do you have code that exercises the interface?
> If so, please put it on cr.openjdk.
> 

So far, only Shenandoah supports object pinning API, so there are a 
couple of jtreg tests in Shenandoah repos:

gc/shenandoah/CriticalNativeArgs.java
gc/shenandoah/CriticalNativeStress.java


Thanks,

-Zhengyu


From zgu at redhat.com  Mon Jul  9 14:26:41 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 9 Jul 2018 10:26:41 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <51cd3a90-f2f3-e714-a0ae-8f9d0619796f@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <3431da70-33bc-d3db-35b7-8208909b8201@redhat.com>
 <51cd3a90-f2f3-e714-a0ae-8f9d0619796f@redhat.com>
Message-ID: <15fb2ab9-fd36-79f1-c7bd-467b8ac9799e@redhat.com>



On 07/09/2018 10:04 AM, Roman Kennke wrote:
> Am 09.07.2018 um 15:57 schrieb Andrew Haley:
>> On 06/15/2018 12:55 PM, Zhengyu Gu wrote:
>>> Ping!!!! anyone? please!
>>
>> How did you test this?  Do you have code that exercises the interface?
>> If so, please put it on cr.openjdk.
>>
> 
> We have tests in Shenandoah. We would upstream it, but it requires a GC
> that supports pinning. AFAIK, ZGC devs *intend* to support pinning, and
> for G1 it should be easy as well. But it's not there yet.
> 
> This is the test:
> http://hg.openjdk.java.net/shenandoah/jdk/file/266e6a543eaa/test/hotspot/jtreg/gc/shenandoah/CriticalNativeStress.java
> 
> Zhengyu: do you see a way to test this even without a supporting GC?

I am afraid not.

-Zhengyu


> 
> Roman
> 

From boris.ulasevich at bell-sw.com  Mon Jul  9 14:31:12 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Mon, 9 Jul 2018 17:31:12 +0300
Subject: [11] RFR(XS) 8206265: assert in TestOptionsWithRanges on aarch64
In-Reply-To: <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
Message-ID: <8dfc4b6c-90e3-d12c-4c7d-d89fdbaf707e@bell-sw.com>

Ok. Please review the simple change for 11:

https://bugs.openjdk.java.net/browse/JDK-8206265
http://cr.openjdk.java.net/~bulasevich/8206265/webrev.05

regards,
Boris

On 06.07.2018 15:34, Andrew Haley wrote:
> On 07/05/2018 06:09 PM, Boris Ulasevich wrote:
>> A new instruction cmp(rscratch, Rn, imm) alias is introduced to use it
>> when immediate value can not fit in 12 bit. I believe it's cleaner than
>> using subs.
> 
> Maybe so, yes.  So we can delete all but the byte form of cmp(reg, imm), poison
> the other forms, and add cmp(reg, reg, imm).  Works for me.
> 
>> Alternatively, if someone believes this looks risky for 11 I can propose
>> to just limit SoftwarePrefetchHintDistance. It seems unreasonable to
>> prefetch more than a few cache lines ahead anyway.
> 
> That's best for 11.

From boris.ulasevich at bell-sw.com  Mon Jul  9 14:31:45 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Mon, 9 Jul 2018 17:31:45 +0300
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instuction
In-Reply-To: <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
Message-ID: <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>

And please review the following change for openjdk-12:

http://cr.openjdk.java.net/~bulasevich/8206895/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8206895

Byte form of cmp instruction was added. For bigger constants we are 
supposed to state _imm12 postfix implicitly or use cmp(reg,reg,imm) macro.

thanks,
Boris

On 06.07.2018 15:34, Andrew Haley wrote:
> On 07/05/2018 06:09 PM, Boris Ulasevich wrote:
>> A new instruction cmp(rscratch, Rn, imm) alias is introduced to use it
>> when immediate value can not fit in 12 bit. I believe it's cleaner than
>> using subs.
> 
> Maybe so, yes.  So we can delete all but the byte form of cmp(reg, imm), poison
> the other forms, and add cmp(reg, reg, imm).  Works for me.
> 
>> Alternatively, if someone believes this looks risky for 11 I can propose
>> to just limit SoftwarePrefetchHintDistance. It seems unreasonable to
>> prefetch more than a few cache lines ahead anyway.
> 
> That's best for 11.
> 

From aph at redhat.com  Mon Jul  9 14:43:11 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 9 Jul 2018 15:43:11 +0100
Subject: [11] RFR(XS) 8206265: assert in TestOptionsWithRanges on aarch64
In-Reply-To: <8dfc4b6c-90e3-d12c-4c7d-d89fdbaf707e@bell-sw.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8dfc4b6c-90e3-d12c-4c7d-d89fdbaf707e@bell-sw.com>
Message-ID: <95fa4b63-1665-f331-3fbc-0323b088db1b@redhat.com>

On 07/09/2018 03:31 PM, Boris Ulasevich wrote:
> https://bugs.openjdk.java.net/browse/JDK-8206265
> http://cr.openjdk.java.net/~bulasevich/8206265/webrev.05

OK, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Mon Jul  9 14:50:16 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 9 Jul 2018 15:50:16 +0100
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instuction
In-Reply-To: <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
Message-ID: <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>

On 07/09/2018 03:31 PM, Boris Ulasevich wrote:
> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8206895
> 
> Byte form of cmp instruction was added. For bigger constants we are 
> supposed to state _imm12 postfix implicitly or use cmp(reg,reg,imm) macro.

I don't think that making cmp an alias for subs helps anyone:

+  inline void cmp(Register Rd, Register Rn, unsigned imm32)  { subs(Rd, Rn, imm32); }

I think the best suggestion was to make the 8-bit cmp the only form
allowed, mark the larger cmp as deprecated, and force the user to use
subs.  That would be easier to read than cmp_imm12().

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From gnu.andrew at redhat.com  Mon Jul  9 15:01:51 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 9 Jul 2018 16:01:51 +0100
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <53b265f2-902f-8754-d50b-92693fd8ce27@oracle.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
 <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
 <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>
 <CAEgw74BwRtRER_d7_ymdaRGTsbgp90mYPkO3mfa0aDhXHVBUHQ@mail.gmail.com>
 <53b265f2-902f-8754-d50b-92693fd8ce27@oracle.com>
Message-ID: <CABi63P4bMb7VgjosOBtTA-H8sV-PxzP+tsC4kcyArAZacixWwg@mail.gmail.com>

On 9 July 2018 at 01:35, David Holmes <david.holmes at oracle.com> wrote:
>
snip...

>>
>> Note that I also provided a variant of the fix only in 'os::readdir'
>> which shouldn't break JFR:
>>
>> https://bugs.openjdk.java.net/secure/attachment/76645/os_readdir2.patch
>>
>> Maybe this could make it for 8u?
>
>
> This is linux specific code but it seems to be using internal knowledge of
> how a struct dirent is laid out on Linux. I'd also have to ensure this gets
> tested with JFR on 8u.
>
> I'll leave it to Andrew to decide on the above fix, or the makefile warning
> fix. I'll Review whichever is chosen.
>
> Thanks,
> David
>
>
>> Bernard
>>
>>

It's difficult for me to really just on Bernand's patch as I don't
know what problem
we're trying to solve. At the very least, it needs to be documented why that
memory copy is taking place.

I can propose a variant of the warning fix, but I think it has to involve moving
the readdir function out of os_linux.inline.hpp and into os_linux.cpp so the
warning pragmas can be safely applied.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From coleen.phillimore at oracle.com  Mon Jul  9 15:30:48 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 9 Jul 2018 11:30:48 -0400
Subject: RFR JDK-8206394 : ResourceMark in AOTCompiledMethod::metadata_do, 
 AOTCompiledMethod::clear_inline_caches ,
 CompiledMethod::clear_ic_stubs , 
 CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks when
 CompiledIC_at is used ?
In-Reply-To: <CAA-vtUwrqYxgtf_fmCtnzVT3k6s4MhmZ89aK=4TU6BceRWKOhw@mail.gmail.com>
References: <74d4f74ddb934d33a712887edd606d24@sap.com>
 <284b43ad-bec2-f479-7068-84945e4c89d0@oracle.com>
 <31df82f18d7b4b6bbf514676dfdf171e@sap.com>
 <74183e10-314b-1e5b-b7ce-c5f8172fb665@oracle.com>
 <CAA-vtUwrqYxgtf_fmCtnzVT3k6s4MhmZ89aK=4TU6BceRWKOhw@mail.gmail.com>
Message-ID: <eb91e4a8-0a63-2f41-79b7-c5d7995cd375@oracle.com>



On 7/5/18 2:27 PM, Thomas St?fe wrote:
> Hi Coleen,
>
> On Thu, Jul 5, 2018 at 7:29 PM,  <coleen.phillimore at oracle.com> wrote:
>> Some ResourceMarks are missing because they might clear other resource
>> allocated memory when they return.  This usually occurs with the
>> print_on(outputStream*) methods because logStream or stringStream may be
>> expanded in the print function and you don't want it cleared on return.
> Not LogStream, we explicitly refactored that to not use ResourceArea
> anymore: https://bugs.openjdk.java.net/browse/JDK-8181917
>
> I think stringStream should not use ResourceArea either. One should
> avoid handing pointers to resourceArea up and down the stack so much.
> For stringStream this is especially evil since whether this
> crashes/asserts depends on when the buffer is resized, and that
> depends on the content written to the stream, and that is highly
> runtime dependent and difficult to test.
>
> If we keep doing this, maybe we could at least modify
> stringStream::write() to assert on the ResourceMark equality every
> time it is called instead of just when the buffer gets resized. What
> do you think?

I have to confess that I wasn't paying attention to the LogStream 
change, but it seems that doing the same sort of thing for stringStream 
would be a good idea.

Thanks,
Coleen

>
> ..Thomas
>
>> There may also be a ResourceMark further up the call chain for these cases.
>> So you have to be careful with this.
>>
>>
>> On 7/5/18 12:18 PM, Baesken, Matthias wrote:
>>> Great , thanks for your help !
>>>
>>>
>>> Btw.  while looking a bit more at the  ResourceMark usages  , I found
>>> that the    name_and_sig_as_C_string()   calls  are mostly
>>>      in the codebase with a  related ResourceMark .
>>>
>>> However it is not done always,  for example ;   do you think it is missing
>>> at these places or not needed?
>>>
>>>
>>> hotspot/share/classfile/verifier.cpp#626
>>>
>>> 623void ClassVerifier::verify_method(const methodHandle& m, TRAPS) {
>>> 624  HandleMark hm(THREAD);
>>
>> The HandleMark is probably not needed here though.  A ResourceMark does seem
>> like a good idea here.
>>
>> Coleen
>>
>>> 625  _method = m;   // initialize _method
>>> 626  log_info(verification)("Verifying method %s",
>>> m->name_and_sig_as_C_string());
>>>
>>>
>>> hotspot/share/classfile/classLoader.cpp#2045
>>>
>>> void ClassLoader::compile_the_world_in(char* name, Handle loader, TRAPS) {
>>>
>>> 2058                if (HAS_PENDING_EXCEPTION) {
>>> 2059                  clear_pending_exception_if_not_oom(CHECK);
>>> 2060                  tty->print_cr("CompileTheWorld (%d) : Skipping
>>> method: %s", _compile_the_world_class_counter,
>>> m->name_and_sig_as_C_string());
>>> 2061                } else {
>>> 2062                  _compile_the_world_method_counter++;
>>> 2063                }
>>> 2064              }
>>> 2065            } else {
>>> 2066              tty->print_cr("CompileTheWorld (%d) : Skipping method:
>>> %s", _compile_the_world_class_counter, m->name_and_sig_as_C_string());
>>> 2067            }
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Donnerstag, 5. Juli 2018 18:07
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>> Subject: Re: RFR JDK-8206394 : ResourceMark in
>>>> AOTCompiledMethod::metadata_do,
>>>> AOTCompiledMethod::clear_inline_caches ,
>>>> CompiledMethod::clear_ic_stubs ,
>>>> CompiledMethod::cleanup_inline_caches_impl - was : RE: ResourceMarks
>>>> when CompiledIC_at is used ?
>>>>
>>>> Looks good. I will test it and push if it passed.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 7/5/18 2:14 AM, Baesken, Matthias wrote:
>>>>> Hi Vladimir, thanks for looking into it !
>>>>>
>>>>> Please review :
>>>>>
>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8206394/
>>>>>
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8206394
>>>>>
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>>>> Sent: Mittwoch, 4. Juli 2018 19:43
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>>>> Subject: Re: ResourceMarks when CompiledIC_at is used ?
>>>>>>
>>>>>> Thank you, Matthias
>>>>>>
>>>>>> Yes, I checked all these places and they have to be fixed. Please, file
>>>>>> a bug for jdk11.
>>>>>>
>>>>>> Vladimir
>>>>>>
>>>>>> On 7/4/18 7:44 AM, Baesken, Matthias wrote:
>>>>>>> Hello,   I recently looked at   8164293: HotSpot leaking memory in
>>>>>>> long-
>>>>>> running requests
>>>>>>> http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/8dfbb002197a
>>>>>>>
>>>>>>> where a number of missing ResourceMarks were added .
>>>>>>> I think some of those ResourceMarks were added  because of
>>>>>> CompiledIC_at  in the changed  functions .
>>>>>>> I checked for  other CompiledIC_at    in the hs coding ,  and found
>>>>>>> some
>>>>>> other places (see below) where  ResourceMarks  are missing as well.
>>>>>>> Should they be added ?
>>>>>>>
>>>>>>> Best regards, Matthias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> src/hotspot/share/aot/aotCompiledMethod.cpp
>>>>>>>
>>>>>>> void AOTCompiledMethod::metadata_do(void f(Metadata*)) {
>>>>>>> .....
>>>>>>> 274      } else if (iter.type() == relocInfo::virtual_call_type) {
>>>>>>> 275        // Check compiledIC holders associated with this nmethod
>>>>>>> 276        CompiledIC *ic = CompiledIC_at(&iter);
>>>>>>> <---------------------------
>>>> ----
>>>>>> -----
>>>>>>>
>>>>>>>         and
>>>>>>>
>>>>>>> 441void AOTCompiledMethod::clear_inline_caches() {
>>>>>>> 442  assert(SafepointSynchronize::is_at_safepoint(), "cleaning of IC's
>>>> only
>>>>>> allowed at safepoint");
>>>>>>> 443  if (is_zombie()) {
>>>>>>> 444    return;
>>>>>>> 445  }
>>>>>>> 446
>>>>>>> 447  RelocIterator iter(this);
>>>>>>> 448  while (iter.next()) {
>>>>>>> 449    iter.reloc()->clear_inline_cache();
>>>>>>> 450    if (iter.type() == relocInfo::opt_virtual_call_type) {
>>>>>>> 451      CompiledIC* cic = CompiledIC_at(&iter);
>>>>>>> <---------------------------
>>>> ----
>>>>>> -----
>>>>>>> 452      assert(cic->is_clean(), "!");
>>>>>>> 453      nativePltCall_at(iter.addr())->set_stub_to_clean();
>>>>>>> 454    }
>>>>>>> 455  }
>>>>>>> 456}
>>>>>>>
>>>>>>> src/hotspot/share/code/compiledMethod.cpp
>>>>>>>
>>>>>>> 326void CompiledMethod::clear_ic_stubs() {
>>>>>>> 327  assert_locked_or_safepoint(CompiledIC_lock);
>>>>>>> 328  RelocIterator iter(this);
>>>>>>> 329  while(iter.next()) {
>>>>>>> 330    if (iter.type() == relocInfo::virtual_call_type) {
>>>>>>> 331      CompiledIC* ic = CompiledIC_at(&iter);
>>>>>>> <---------------------------
>>>> ----
>>>>>> -----
>>>>>>> 332      ic->clear_ic_stub();
>>>>>>> 333    }
>>>>>>> 334  }
>>>>>>> 335}
>>>>>>>
>>>>>>>
>>>>>>> 547bool CompiledMethod::cleanup_inline_caches_impl(bool parallel,
>>>> bool
>>>>>> unloading_occurred, bool clean_all) {
>>>>>>> 548  assert_locked_or_safepoint(CompiledIC_lock);
>>>>>>> 549  bool postponed = false;
>>>>>>> 550
>>>>>>> 551  // Find all calls in an nmethod and clear the ones that point to
>>>>>>> non-
>>>>>> entrant,
>>>>>>> 552  // zombie and unloaded nmethods.
>>>>>>> 553  RelocIterator iter(this, oops_reloc_begin());
>>>>>>> 554  while(iter.next()) {
>>>>>>> 555
>>>>>>> 556    switch (iter.type()) {
>>>>>>> 557
>>>>>>> 558    case relocInfo::virtual_call_type:
>>>>>>> 559      if (unloading_occurred) {
>>>>>>> 560        // If class unloading occurred we first clear ICs where the
>>>>>>> cached
>>>>>> metadata
>>>>>>> 561        // is referring to an unloaded klass or method.
>>>>>>> 562        clean_ic_if_metadata_is_dead(CompiledIC_at(&iter));
>>>>>>> <------
>>>> ---
>>>>>> ---------------------------
>>


From boris.ulasevich at bell-sw.com  Mon Jul  9 15:32:28 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Mon, 9 Jul 2018 18:32:28 +0300
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instuction
In-Reply-To: <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
 <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>
Message-ID: <b3d89836-26fc-fb99-a7cd-2e0a7e4d342e@bell-sw.com>

I am not sure how to mark instruction deprecated. Why don't just remove 
it and update all the usage points? Here is the updated review:

http://cr.openjdk.java.net/~bulasevich/8206895/webrev.00

Boris

On 09.07.2018 17:50, Andrew Haley wrote:
> On 07/09/2018 03:31 PM, Boris Ulasevich wrote:
>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8206895
>>
>> Byte form of cmp instruction was added. For bigger constants we are
>> supposed to state _imm12 postfix implicitly or use cmp(reg,reg,imm) macro.
> 
> I don't think that making cmp an alias for subs helps anyone:
> 
> +  inline void cmp(Register Rd, Register Rn, unsigned imm32)  { subs(Rd, Rn, imm32); }
> 
> I think the best suggestion was to make the 8-bit cmp the only form
> allowed, mark the larger cmp as deprecated, and force the user to use
> subs.  That would be easier to read than cmp_imm12().
> 

From boris.ulasevich at bell-sw.com  Mon Jul  9 15:33:18 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Mon, 9 Jul 2018 18:33:18 +0300
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instuction
In-Reply-To: <b3d89836-26fc-fb99-a7cd-2e0a7e4d342e@bell-sw.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
 <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>
 <b3d89836-26fc-fb99-a7cd-2e0a7e4d342e@bell-sw.com>
Message-ID: <bcd327d0-4093-f3ba-c6be-ccbb1a9a7db8@bell-sw.com>

sorry. updated review link:
http://cr.openjdk.java.net/~bulasevich/8206895/webrev.01

On 09.07.2018 18:32, Boris Ulasevich wrote:
> I am not sure how to mark instruction deprecated. Why don't just remove 
> it and update all the usage points? Here is the updated review:
> 
> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.01
> 
> Boris
> 
> On 09.07.2018 17:50, Andrew Haley wrote:
>> On 07/09/2018 03:31 PM, Boris Ulasevich wrote:
>>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.00
>>> https://bugs.openjdk.java.net/browse/JDK-8206895
>>>
>>> Byte form of cmp instruction was added. For bigger constants we are
>>> supposed to state _imm12 postfix implicitly or use cmp(reg,reg,imm) 
>>> macro.
>>
>> I don't think that making cmp an alias for subs helps anyone:
>>
>> +? inline void cmp(Register Rd, Register Rn, unsigned imm32)? { 
>> subs(Rd, Rn, imm32); }
>>
>> I think the best suggestion was to make the 8-bit cmp the only form
>> allowed, mark the larger cmp as deprecated, and force the user to use
>> subs.? That would be easier to read than cmp_imm12().
>>

From boris.ulasevich at bell-sw.com  Mon Jul  9 15:35:45 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Mon, 9 Jul 2018 18:35:45 +0300
Subject: [11] RFR(XS) 8206265: assert in TestOptionsWithRanges on aarch64
In-Reply-To: <95fa4b63-1665-f331-3fbc-0323b088db1b@redhat.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8dfc4b6c-90e3-d12c-4c7d-d89fdbaf707e@bell-sw.com>
 <95fa4b63-1665-f331-3fbc-0323b088db1b@redhat.com>
Message-ID: <ca6538ab-6cd5-b857-95f0-00c3c759a9fd@bell-sw.com>

Thank you!

On 09.07.2018 17:43, Andrew Haley wrote:
> On 07/09/2018 03:31 PM, Boris Ulasevich wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8206265
>> http://cr.openjdk.java.net/~bulasevich/8206265/webrev.05
> 
> OK, thanks.
> 

From aph at redhat.com  Mon Jul  9 15:54:47 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 9 Jul 2018 16:54:47 +0100
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instuction
In-Reply-To: <bcd327d0-4093-f3ba-c6be-ccbb1a9a7db8@bell-sw.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
 <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>
 <b3d89836-26fc-fb99-a7cd-2e0a7e4d342e@bell-sw.com>
 <bcd327d0-4093-f3ba-c6be-ccbb1a9a7db8@bell-sw.com>
Message-ID: <6f3111d3-b8e7-6784-54d1-7ab384d6bcb0@redhat.com>

On 07/09/2018 04:33 PM, Boris Ulasevich wrote:
> sorry. updated review link:
> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.01
> 
> On 09.07.2018 18:32, Boris Ulasevich wrote:
>> I am not sure how to mark instruction deprecated.

http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-May/005840.html

 Why don't just remove
>> it and update all the usage points? Here is the updated review:
>>
>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.01
>>
>> Boris
>>
>> On 09.07.2018 17:50, Andrew Haley wrote:
>>> On 07/09/2018 03:31 PM, Boris Ulasevich wrote:
>>>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.00
>>>> https://bugs.openjdk.java.net/browse/JDK-8206895
>>>>
>>>> Byte form of cmp instruction was added. For bigger constants we are
>>>> supposed to state _imm12 postfix implicitly or use cmp(reg,reg,imm) 
>>>> macro.
>>>
>>> I don't think that making cmp an alias for subs helps anyone:
>>>
>>> +? inline void cmp(Register Rd, Register Rn, unsigned imm32)? { 
>>> subs(Rd, Rn, imm32); }
>>>
>>> I think the best suggestion was to make the 8-bit cmp the only form
>>> allowed, mark the larger cmp as deprecated, and force the user to use
>>> subs.? That would be easier to read than cmp_imm12().
>>>


-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From gnu.andrew at redhat.com  Mon Jul  9 15:55:17 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 9 Jul 2018 16:55:17 +0100
Subject: [8u] [RFR] Request for Review of Backport of JDK-8197429: Increased
 stack guard causes segfaults on x86-32
Message-ID: <CABi63P6YM0upX3aeL28Nby6FJbOhKJqZUQNY2_GP6AO0vQaB5A@mail.gmail.com>

[CCing hotspot list for review]

Bug: https://bugs.openjdk.java.net/browse/JDK-8197429
Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8197429/webrev.01/
Original review thread:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030076.html

The code patch is largely the same, with the only
difference that 8 still uses StackYellowPages
and StackRedPages rather than the
JavaThread::stack_red_zone_size() and
JavaThread::stack_yellow_zone_size() functions.

The test differs in that the 8u version needs to
also compile the C code within the test.
I based this on test/runtime/InitialThreadOverflow.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From bsrbnd at gmail.com  Mon Jul  9 16:59:36 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Mon, 9 Jul 2018 18:59:36 +0200
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <CABi63P4bMb7VgjosOBtTA-H8sV-PxzP+tsC4kcyArAZacixWwg@mail.gmail.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
 <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
 <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>
 <CAEgw74BwRtRER_d7_ymdaRGTsbgp90mYPkO3mfa0aDhXHVBUHQ@mail.gmail.com>
 <53b265f2-902f-8754-d50b-92693fd8ce27@oracle.com>
 <CABi63P4bMb7VgjosOBtTA-H8sV-PxzP+tsC4kcyArAZacixWwg@mail.gmail.com>
Message-ID: <CAEgw74DLFrnSVsvZx=b7gMX7vK1yfKaG=pJAMj0BL6LK7u9MQA@mail.gmail.com>

On 9 July 2018 at 17:01, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> On 9 July 2018 at 01:35, David Holmes <david.holmes at oracle.com> wrote:
>>
> snip...
>
>>>
>>> Note that I also provided a variant of the fix only in 'os::readdir'
>>> which shouldn't break JFR:
>>>
>>> https://bugs.openjdk.java.net/secure/attachment/76645/os_readdir2.patch
>>>
>>> Maybe this could make it for 8u?
>>
>>
>> This is linux specific code but it seems to be using internal knowledge of
>> how a struct dirent is laid out on Linux. I'd also have to ensure this gets
>> tested with JFR on 8u.
>>
>> I'll leave it to Andrew to decide on the above fix, or the makefile warning
>> fix. I'll Review whichever is chosen.
>>
>> Thanks,
>> David
>>
>>
>>> Bernard
>>>
>>>
>
> It's difficult for me to really just on Bernand's patch as I don't
> know what problem
> we're trying to solve. At the very least, it needs to be documented why that
> memory copy is taking place.

I think the problem is important since it's still present in 11 & 12
and should probably be solved, see:

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

Unfortunately, the current fix:

http://hg.openjdk.java.net/jdk/jdk/rev/746229cc1ab0

for:

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

alters 'os::readdir' behavior because the 'dbuf' parameter isn't used
anymore which breaks some callers that are expecting it to be filled,
for example:

http://hg.openjdk.java.net/jdk/jdk/file/0fad17c646c9/src/hotspot/os/linux/os_perf_linux.cpp#l905

The following test reveals the problem:

http://hg.openjdk.java.net/jdk/jdk/file/0fad17c646c9/test/jdk/jdk/jfr/event/os/TestSystemProcess.java

This probably means that 11 & 12 would have to be fixed with either:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032445.html

or:

https://bugs.openjdk.java.net/secure/attachment/76645/os_readdir2.patch

I guess the second one is an easier patch for 8 as it doesn't imply
JFR to be fixed (which was closed in 8, I think?).
Both patches I suggested for 11 are passing tier1 + the failing
'TestSystemProcess'.

So, we can disable the warning for 8 but the process iterator will
still remain broken in 11 & 12.

What should we do?

Bernard


> I can propose a variant of the warning fix, but I think it has to involve moving
> the readdir function out of os_linux.inline.hpp and into os_linux.cpp so the
> warning pragmas can be safely applied.
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Web Site: http://fuseyism.com
> Twitter: https://twitter.com/gnu_andrew_java
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From kim.barrett at oracle.com  Mon Jul  9 17:25:48 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Jul 2018 13:25:48 -0400
Subject: RFR[12]: 8204834: Fix confusing "allocate" naming in OopStorage
In-Reply-To: <f2b846ae-698a-058c-e4bc-29bde911e313@oracle.com>
References: <C1844510-BADC-4E80-B1F2-525461568582@oracle.com>
 <f2b846ae-698a-058c-e4bc-29bde911e313@oracle.com>
Message-ID: <F8C87A11-51EB-4383-9B2A-9F6468C79933@oracle.com>

> On Jul 9, 2018, at 7:37 AM, coleen.phillimore at oracle.com wrote:
> 
> 
> http://cr.openjdk.java.net/~kbarrett/8204834/open.00/src/hotspot/share/gc/shared/oopStorage.inline.hpp.udiff.html
> 
> +// Blocks in a AllocationList.
> 
> a => an

Fixed.

> Thank you for doing this renaming, Kim.  This reads a lot better for me.
> 
> Coleen

Thanks, Coleen, David, and Thomas.

> 
> 
> On 7/8/18 12:00 PM, Kim Barrett wrote:
>> Please review this nomenclature change in the implementation of
>> OopStorage.  This is a followup to JDK-8204097; in the review of that
>> change Coleen noted that some names were confusing, especially
>> "allocate_list()", which is an accessor and doesn't allocate anything!
>> 
>> This is a mostly mechanical change:
>> 
>> AllocateList => AllocationList
>> _allocate_list => _allocation_list
>> allocate_list() => allocation_list()
>> 
>> AllocateEntry => AllocationListEntry
>> _allocate_entry => _allocation_list_entry
>> allocate_entry() => allocation_list_entry()
>> 
>> _allocate_mutex => _allocation_mutex
>> 
>> There are a few non-mechanical changes in comments, to make the
>> comments consistently use the same names as the code.  For example,
>> some underscores were added when referring to members in comments.
>> Also fixed a few related typos.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8204834
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8204834/open.00/
>> 
>> Testing:
>> mach5 tier1



From vladimir.kozlov at oracle.com  Mon Jul  9 17:31:26 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 9 Jul 2018 10:31:26 -0700
Subject: [11] RFR(S): 8205472: Deadlock in Kitchensink when trying to
 print compile queues causing timeout
In-Reply-To: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
References: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
Message-ID: <7b8c1192-032c-ee60-34f0-3b9d1e49ba3d@oracle.com>

Good.

thanks,
Vladimir

On 7/9/18 4:58 AM, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8205472
> http://cr.openjdk.java.net/~thartmann/8205472/webrev.00/
> 
> When registering a compiled method in ciEnv::register_method() the compiler thread acquires the
> MethodCompileQueue_lock and then performs a safepoint check before acquiring the Compile_lock as
> well. If we enter a safepoint, the compiler thread is still holding the MethodCompileQueue_lock
> while the VM thread may execute the VM_PrintCompileQueue VM operation which requires the
> MethodCompileQueue_lock as well. We deadlock.
> 
> This bug is very intermittent and I was only able to reproduce it by modifying the VM to always
> enter a safepoint (see comments in JIRA). The solution is to not acquire the MethodCompileQueue_lock
> in CompileBroker::print_compile_queues() because we only execute that code at a safepoint anyway
> (VM_PrintCompileQueue has evaluation_mode() == _safepoint).
> 
> Thanks,
> Tobias
> 

From kim.barrett at oracle.com  Mon Jul  9 17:33:29 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Jul 2018 13:33:29 -0400
Subject: [11] RFR(S): 8205472: Deadlock in Kitchensink when trying to
 print compile queues causing timeout
In-Reply-To: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
References: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
Message-ID: <63CB0D40-4CE2-4C4B-B26F-40A2DB011016@oracle.com>

> On Jul 9, 2018, at 7:58 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8205472
> http://cr.openjdk.java.net/~thartmann/8205472/webrev.00/
> 
> When registering a compiled method in ciEnv::register_method() the compiler thread acquires the
> MethodCompileQueue_lock and then performs a safepoint check before acquiring the Compile_lock as
> well. If we enter a safepoint, the compiler thread is still holding the MethodCompileQueue_lock
> while the VM thread may execute the VM_PrintCompileQueue VM operation which requires the
> MethodCompileQueue_lock as well. We deadlock.
> 
> This bug is very intermittent and I was only able to reproduce it by modifying the VM to always
> enter a safepoint (see comments in JIRA). The solution is to not acquire the MethodCompileQueue_lock
> in CompileBroker::print_compile_queues() because we only execute that code at a safepoint anyway
> (VM_PrintCompileQueue has evaluation_mode() == _safepoint).
> 
> Thanks,
> Tobias

Looks good.


From kim.barrett at oracle.com  Mon Jul  9 17:45:24 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Jul 2018 13:45:24 -0400
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <CABi63P4bMb7VgjosOBtTA-H8sV-PxzP+tsC4kcyArAZacixWwg@mail.gmail.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
 <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
 <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>
 <CAEgw74BwRtRER_d7_ymdaRGTsbgp90mYPkO3mfa0aDhXHVBUHQ@mail.gmail.com>
 <53b265f2-902f-8754-d50b-92693fd8ce27@oracle.com>
 <CABi63P4bMb7VgjosOBtTA-H8sV-PxzP+tsC4kcyArAZacixWwg@mail.gmail.com>
Message-ID: <797A13D6-8751-4A17-B5DD-291DC91A00EA@oracle.com>

> On Jul 9, 2018, at 11:01 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> 
> I can propose a variant of the warning fix, but I think it has to involve moving
> the readdir function out of os_linux.inline.hpp and into os_linux.cpp so the
> warning pragmas can be safely applied.

I was about to suggest that.

> -- 
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Web Site: http://fuseyism.com
> Twitter: https://twitter.com/gnu_andrew_java
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222



From hohensee at amazon.com  Mon Jul  9 21:40:07 2018
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 9 Jul 2018 21:40:07 +0000
Subject: FW: [Mach5] mach5-one-phh-JDK-8196989-20180709-1506-30329: Build
 tasks UNSTABLE. Test tasks UNSTABLE.
In-Reply-To: <1862132892.167.1531151325672.JavaMail.root@sca00lwf.us.oracle.com>
References: <1862132892.167.1531151325672.JavaMail.root@sca00lwf.us.oracle.com>
Message-ID: <6CEA36BF-572D-4A84-9FC5-6E92E544011C@amazon.com>

Hi all,

I?m getting what looks to be build failures on Solaris and Windows from the submit repo. Builds fine on OSX both product and fastdebug. I?d be grateful if someone could send me log snippets that show the problem.

Thanks,

Paul

From: "do-not-reply at oracle.com" <do-not-reply at oracle.com>
Reply-To: "mach5_admin_ww_grp at oracle.com" <mach5_admin_ww_grp at oracle.com>
Date: Monday, July 9, 2018 at 8:48 AM
To: "Hohensee, Paul" <hohensee at amazon.com>
Subject: [Mach5] mach5-one-phh-JDK-8196989-20180709-1506-30329: Build tasks UNSTABLE. Test tasks UNSTABLE.

Build Details: 2018-07-09-1502560.hohensee.source
0 Failed Tests
Mach5 Tasks Results Summary

  *   UNABLE_TO_RUN: 21
  *   NA: 0
  *   FAILED: 0
  *   EXECUTED_WITH_FAILURE: 6
  *   KILLED: 0
  *   PASSED: 48

Build
8 Not run

     *   solaris-sparcv9-solaris-sparcv9-build-8 error while building, return value: 2
     *   solaris-sparcv9-debug-solaris-sparcv9-build-9 error while building, return value: 2
     *   solaris-sparcv9-install-solaris-sparcv9-build-16 Dependency task failed: mach5...30329-solaris-sparcv9-solaris-sparcv9-build-8
     *   windows-x64-windows-x64-build-10 error while building, return value: 2
     *   windows-x64-debug-windows-x64-build-11 error while building, return value: 2
     *   windows-x64-install-windows-x64-build-17 Dependency task failed: EOnQt7AjO
     *   windows-x64-open-windows-x64-build-12 error while building, return value: 2
     *   windows-x64-open-debug-windows-x64-build-13 error while building, return value: 2

Test
19 Not run

     *   tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-57 Dependency task failed: mach5...30329-solaris-sparcv9-solaris-sparcv9-build-8
     *   tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-58 Dependency task failed: mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
     *   tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-20 Dependency task failed: EOnQt7AjO
     *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-debug-26 Dependency task failed: EOnQt7AkO
     *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-29 Dependency task failed: EOnQt7AkO
     *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-32 Dependency task failed: EOnQt7AkO
     *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_3-windows-x64-debug-35 Dependency task failed: EOnQt7AkO
     *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_not_xcomp-windows-x64-debug-38 Dependency task failed: EOnQt7AkO
     *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_1-windows-x64-debug-41 Dependency task failed: EOnQt7AkO
     *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_2-windows-x64-debug-44 Dependency task failed: EOnQt7AkO
     *   See all 19...

From calvin.cheung at oracle.com  Mon Jul  9 22:01:23 2018
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Mon, 09 Jul 2018 15:01:23 -0700
Subject: FW: [Mach5] mach5-one-phh-JDK-8196989-20180709-1506-30329: Build
 tasks UNSTABLE. Test tasks UNSTABLE.
In-Reply-To: <6CEA36BF-572D-4A84-9FC5-6E92E544011C@amazon.com>
References: <1862132892.167.1531151325672.JavaMail.root@sca00lwf.us.oracle.com>
 <6CEA36BF-572D-4A84-9FC5-6E92E544011C@amazon.com>
Message-ID: <5B43DB33.5090204@oracle.com>

Hi Paul,

For the Solaris build error:
----------
jib > === Output from failing command(s) repeated here ===
jib > * For target hotspot_variant-server_libjvm_objs_filemap.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1AllocRegion.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1Allocator.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1Arguments.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1BarrierSet.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1BlockOffsetTable.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1CardCounts.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1CardTable.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1CodeBlobClosure.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1CollectedHeap.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp", 
line 5064: Error: TraceMemoryManagerStats is not a direct base class of 
TraceConcMemoryManagerStats.
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp", 
line 5068: Error: The function "initialize" must have a prototype.
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp", 
line 5082: Error: The function "initialize" must have a prototype.
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp", 
line 5095: Error: The function "initialize" must have a prototype.
jib > 5 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1CollectionSet.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1CollectorPolicy.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1ConcurrentMark.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1ConcurrentMark.cpp", 
line 954: Error: Too many arguments in cast to TraceConcMemoryManagerStats.
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1ConcurrentMark.cpp", 
line 969: Error: Too many arguments in cast to TraceConcMemoryManagerStats.
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1ConcurrentMark.cpp", 
line 1141: Error: Too many initializers for tms.
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1ConcurrentMark.cpp", 
line 1359: Error: Too many initializers for tms.
jib > 5 Error(s) detected.
jib > * For target 
hotspot_variant-server_libjvm_objs_g1ConcurrentMarkBitMap.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target 
hotspot_variant-server_libjvm_objs_g1ConcurrentMarkObjArrayProcessor.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target 
hotspot_variant-server_libjvm_objs_g1ConcurrentMarkThread.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1EvacFailure.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1FullCollector.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1FullGCAdjustTask.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1FullGCCompactTask.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1FullGCMarkTask.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1FullGCMarker.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1FullGCOopClosures.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1FullGCPrepareTask.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target 
hotspot_variant-server_libjvm_objs_g1FullGCReferenceProcessorExecutor.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1FullGCScope.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib > * For target hotspot_variant-server_libjvm_objs_g1GCPhaseTimes.o:
jib > 
"/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/open/src/hotspot/share/gc/g1/g1CollectedHeap.hpp", 
line 1447: Error: TraceMemoryManagerStats is not defined.
jib > 1 Error(s) detected.
jib >
jib > * All command lines available in 
/scratch/opt/mach5/mesos/work_dir/a1007550-7ef6-41f7-953b-610a3dc6effc/workspace/build/solaris-sparcv9-debug/make-support/failure-logs.
jib > === End of repeated output ===

-----

For Windows build error:
------
jib > 
t:/workspace/open/src/hotspot/share/gc/g1/g1MonitoringSupport.cpp(224): 
error C2220: warning treated as error - no 'object' file generated
jib > 
t:/workspace/open/src/hotspot/share/gc/g1/g1MonitoringSupport.cpp(224): 
warning C4267: 'initializing': conversion from 'size_t' to 'uint', 
possible loss of data
jib > 
t:/workspace/open/src/hotspot/share/gc/g1/g1MonitoringSupport.cpp(240): 
warning C4267: 'initializing': conversion from 'size_t' to 'uint', 
possible loss of data
jib > lib/CompileJvm.gmk:149: recipe for target 
'/cygdrive/t/workspace/build/windows-x64-debug/hotspot/variant-server/libjvm/objs/g1MonitoringSupport.obj' 
failed
jib > make[3]: *** 
[/cygdrive/t/workspace/build/windows-x64-debug/hotspot/variant-server/libjvm/objs/g1MonitoringSupport.obj] 
Error 1
------

Both product and fastdebug builds have the same error.

thanks,
Calvin

On 7/9/18, 2:40 PM, Hohensee, Paul wrote:
> Hi all,
>
> I?m getting what looks to be build failures on Solaris and Windows from the submit repo. Builds fine on OSX both product and fastdebug. I?d be grateful if someone could send me log snippets that show the problem.
>
> Thanks,
>
> Paul
>
> From: "do-not-reply at oracle.com"<do-not-reply at oracle.com>
> Reply-To: "mach5_admin_ww_grp at oracle.com"<mach5_admin_ww_grp at oracle.com>
> Date: Monday, July 9, 2018 at 8:48 AM
> To: "Hohensee, Paul"<hohensee at amazon.com>
> Subject: [Mach5] mach5-one-phh-JDK-8196989-20180709-1506-30329: Build tasks UNSTABLE. Test tasks UNSTABLE.
>
> Build Details: 2018-07-09-1502560.hohensee.source
> 0 Failed Tests
> Mach5 Tasks Results Summary
>
>    *   UNABLE_TO_RUN: 21
>    *   NA: 0
>    *   FAILED: 0
>    *   EXECUTED_WITH_FAILURE: 6
>    *   KILLED: 0
>    *   PASSED: 48
>
> Build
> 8 Not run
>
>       *   solaris-sparcv9-solaris-sparcv9-build-8 error while building, return value: 2
>       *   solaris-sparcv9-debug-solaris-sparcv9-build-9 error while building, return value: 2
>       *   solaris-sparcv9-install-solaris-sparcv9-build-16 Dependency task failed: mach5...30329-solaris-sparcv9-solaris-sparcv9-build-8
>       *   windows-x64-windows-x64-build-10 error while building, return value: 2
>       *   windows-x64-debug-windows-x64-build-11 error while building, return value: 2
>       *   windows-x64-install-windows-x64-build-17 Dependency task failed: EOnQt7AjO
>       *   windows-x64-open-windows-x64-build-12 error while building, return value: 2
>       *   windows-x64-open-debug-windows-x64-build-13 error while building, return value: 2
>
> Test
> 19 Not run
>
>       *   tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-57 Dependency task failed: mach5...30329-solaris-sparcv9-solaris-sparcv9-build-8
>       *   tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-58 Dependency task failed: mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>       *   tier1-product-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-20 Dependency task failed: EOnQt7AjO
>       *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_common-windows-x64-debug-26 Dependency task failed: EOnQt7AkO
>       *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-29 Dependency task failed: EOnQt7AkO
>       *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-32 Dependency task failed: EOnQt7AkO
>       *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_3-windows-x64-debug-35 Dependency task failed: EOnQt7AkO
>       *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_not_xcomp-windows-x64-debug-38 Dependency task failed: EOnQt7AkO
>       *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_1-windows-x64-debug-41 Dependency task failed: EOnQt7AkO
>       *   tier1-debug-jdk_open_test_hotspot_jtreg_tier1_gc_2-windows-x64-debug-44 Dependency task failed: EOnQt7AkO
>       *   See all 19...

From david.holmes at oracle.com  Tue Jul 10 02:16:15 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Jul 2018 12:16:15 +1000
Subject: [11] RFR(S): 8205472: Deadlock in Kitchensink when trying to
 print compile queues causing timeout
In-Reply-To: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
References: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
Message-ID: <2ae8e23f-f246-c43e-1657-3cd335e6aff5@oracle.com>

Hi Tobias,

On 9/07/2018 9:58 PM, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8205472
> http://cr.openjdk.java.net/~thartmann/8205472/webrev.00/
> 
> When registering a compiled method in ciEnv::register_method() the compiler thread acquires the
> MethodCompileQueue_lock and then performs a safepoint check before acquiring the Compile_lock as
> well. If we enter a safepoint, the compiler thread is still holding the MethodCompileQueue_lock
> while the VM thread may execute the VM_PrintCompileQueue VM operation which requires the
> MethodCompileQueue_lock as well. We deadlock.
> 
> This bug is very intermittent and I was only able to reproduce it by modifying the VM to always
> enter a safepoint (see comments in JIRA). The solution is to not acquire the MethodCompileQueue_lock
> in CompileBroker::print_compile_queues() because we only execute that code at a safepoint anyway
> (VM_PrintCompileQueue has evaluation_mode() == _safepoint).

Note that what you describe is only one half of the safety issue here. 
Executing the code only at a safepoint ensures some degree of mutual 
exclusion, but you also have to ensure that other code that would 
acquire that lock, can not enter a safepoint with that lock held, when 
the state protected by the lock may be inconsistent with the logic that 
will be executed at the safepoint.

Cheers,
David



> Thanks,
> Tobias
> 

From david.holmes at oracle.com  Tue Jul 10 02:21:27 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Jul 2018 12:21:27 +1000
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <CAEgw74DLFrnSVsvZx=b7gMX7vK1yfKaG=pJAMj0BL6LK7u9MQA@mail.gmail.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
 <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
 <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>
 <CAEgw74BwRtRER_d7_ymdaRGTsbgp90mYPkO3mfa0aDhXHVBUHQ@mail.gmail.com>
 <53b265f2-902f-8754-d50b-92693fd8ce27@oracle.com>
 <CABi63P4bMb7VgjosOBtTA-H8sV-PxzP+tsC4kcyArAZacixWwg@mail.gmail.com>
 <CAEgw74DLFrnSVsvZx=b7gMX7vK1yfKaG=pJAMj0BL6LK7u9MQA@mail.gmail.com>
Message-ID: <572ccd74-0a5c-571a-06ca-922ab16b8201@oracle.com>



On 10/07/2018 2:59 AM, B. Blaser wrote:
> On 9 July 2018 at 17:01, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>> On 9 July 2018 at 01:35, David Holmes <david.holmes at oracle.com> wrote:
>>>
>> snip...
>>
>>>>
>>>> Note that I also provided a variant of the fix only in 'os::readdir'
>>>> which shouldn't break JFR:
>>>>
>>>> https://bugs.openjdk.java.net/secure/attachment/76645/os_readdir2.patch
>>>>
>>>> Maybe this could make it for 8u?
>>>
>>>
>>> This is linux specific code but it seems to be using internal knowledge of
>>> how a struct dirent is laid out on Linux. I'd also have to ensure this gets
>>> tested with JFR on 8u.
>>>
>>> I'll leave it to Andrew to decide on the above fix, or the makefile warning
>>> fix. I'll Review whichever is chosen.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Bernard
>>>>
>>>>
>>
>> It's difficult for me to really just on Bernand's patch as I don't
>> know what problem
>> we're trying to solve. At the very least, it needs to be documented why that
>> memory copy is taking place.
> 
> I think the problem is important since it's still present in 11 & 12
> and should probably be solved, see:
> 
> https://bugs.openjdk.java.net/browse/JDK-8202835
> 
> Unfortunately, the current fix:
> 
> http://hg.openjdk.java.net/jdk/jdk/rev/746229cc1ab0
> 
> for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8179887
> 
> alters 'os::readdir' behavior because the 'dbuf' parameter isn't used
> anymore which breaks some callers that are expecting it to be filled,
> for example:
> 
> http://hg.openjdk.java.net/jdk/jdk/file/0fad17c646c9/src/hotspot/os/linux/os_perf_linux.cpp#l905
> 
> The following test reveals the problem:
> 
> http://hg.openjdk.java.net/jdk/jdk/file/0fad17c646c9/test/jdk/jdk/jfr/event/os/TestSystemProcess.java
> 
> This probably means that 11 & 12 would have to be fixed with either:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032445.html
> 
> or:
> 
> https://bugs.openjdk.java.net/secure/attachment/76645/os_readdir2.patch
> 
> I guess the second one is an easier patch for 8 as it doesn't imply
> JFR to be fixed (which was closed in 8, I think?).
> Both patches I suggested for 11 are passing tier1 + the failing
> 'TestSystemProcess'.
> 
> So, we can disable the warning for 8 but the process iterator will
> still remain broken in 11 & 12.
> 
> What should we do?

The immediate issue in 8u is a build failure due to the warning. Fixing 
the warning, via compiler directives, addresses that. The other open 
bugs can deal with the problem of trying to switch to readdir.

Cheers,
David

> 
> Bernard
> 
> 
>> I can propose a variant of the warning fix, but I think it has to involve moving
>> the readdir function out of os_linux.inline.hpp and into os_linux.cpp so the
>> warning pragmas can be safely applied.
>> --
>> Andrew :)
>>
>> Senior Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Web Site: http://fuseyism.com
>> Twitter: https://twitter.com/gnu_andrew_java
>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From Zhongwei.Yao at arm.com  Tue Jul 10 03:24:18 2018
From: Zhongwei.Yao at arm.com (Zhongwei Yao)
Date: Tue, 10 Jul 2018 03:24:18 +0000
Subject: Will there be any "Graal Sync" for JDK 11 repo
Message-ID: <DB6PR0802MB21505CEA026F324448BE54C69D5B0@DB6PR0802MB2150.eurprd08.prod.outlook.com>

Hi, all,

Since the following patch fixed a critical issue for ARMv8.1:
  https://github.com/oracle/graal/pull/484/commits/af8e8b56b93e14bcdb808f2ca8079e9256879af1
Without this fix, current OpenJDK AOT feature on ARMv8.1 system is not able to work.

So my question is whether this fix will be included in the JDK 11 by some Graal to JDK 11 Sync?

If not, shall I manually fix it in JDK11?


--
Best regards,
Zhongwei

From vladimir.kozlov at oracle.com  Tue Jul 10 04:45:21 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 9 Jul 2018 21:45:21 -0700
Subject: [11] RFR(M) 8206135: Building jvm with AOT but without JVMCI should
 fail at configure time
Message-ID: <c7acb02b-aa0f-d04c-dd4c-c7ae7e4f46cd@oracle.com>

http://cr.openjdk.java.net/~kvn/8206135/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8206135

Several configure issues was found related to jvmci, graal and aot build.

Main problem is related values specified with --with-jvm-features were ignored. For example, JVMCI 
module was still built even with --with-jvm-features=-jvmci but JVMCI code was excluded from Hotspot 
VM. AOT tool will be build but Hotspot compilation fails (as in bug report) when jvmci or graal was 
disabled.

Note, jvmci and Graal modules build and Hotspot code are controlled only by --with-jvm-features flag.

AOT is controlled by special --enable-aot/--diable-aot flag and --with-jvm-features (inclusion of 
AOT code in Hotspot is controlled by jvm-features check). But configure AOT code ignored 
--with-jvm-features aot settings.

Fixes:

1. Exclude jdk.internal.vm.ci module build when --with-jvm-features=-jvmci specified
2. Removed duplicated message for forced aot disabling.
3. Check DISABLED_JVM_FEATURES list (negative values listed in --with-jvm-features) for jvmci, graal 
and aot to disable them.
4. Disable aot if graal is disabled and issue error if aot build was explicitly enabled by --enable-aot.
5. Issue error if --with-jvm-features=aot is specified by aot can't be build or is disabled. 
--enable-aot should be used instead of --with-jvm-features=aot because it has additional checks 
(presence of sources).

Tested with build-tier1, hs-tier1, hs-tier2. Also the same testing but with 
--with-jvm-features=-jvmci and --with-jvm-features=-graal configure flags.

Thanks,
Vladimir

From tobias.hartmann at oracle.com  Tue Jul 10 07:09:05 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 10 Jul 2018 09:09:05 +0200
Subject: [11] RFR(S): 8205472: Deadlock in Kitchensink when trying to
 print compile queues causing timeout
In-Reply-To: <7b8c1192-032c-ee60-34f0-3b9d1e49ba3d@oracle.com>
References: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
 <7b8c1192-032c-ee60-34f0-3b9d1e49ba3d@oracle.com>
Message-ID: <bd4e49ea-95c4-aec0-7f38-7ff0737954ea@oracle.com>

Hi Vladimir,

thanks for the review.

Best regards,
Tobias

On 09.07.2018 19:31, Vladimir Kozlov wrote:
> Good.
> 
> thanks,
> Vladimir
> 
> On 7/9/18 4:58 AM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch:
>> https://bugs.openjdk.java.net/browse/JDK-8205472
>> http://cr.openjdk.java.net/~thartmann/8205472/webrev.00/
>>
>> When registering a compiled method in ciEnv::register_method() the compiler thread acquires the
>> MethodCompileQueue_lock and then performs a safepoint check before acquiring the Compile_lock as
>> well. If we enter a safepoint, the compiler thread is still holding the MethodCompileQueue_lock
>> while the VM thread may execute the VM_PrintCompileQueue VM operation which requires the
>> MethodCompileQueue_lock as well. We deadlock.
>>
>> This bug is very intermittent and I was only able to reproduce it by modifying the VM to always
>> enter a safepoint (see comments in JIRA). The solution is to not acquire the MethodCompileQueue_lock
>> in CompileBroker::print_compile_queues() because we only execute that code at a safepoint anyway
>> (VM_PrintCompileQueue has evaluation_mode() == _safepoint).
>>
>> Thanks,
>> Tobias
>>

From tobias.hartmann at oracle.com  Tue Jul 10 07:09:21 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 10 Jul 2018 09:09:21 +0200
Subject: [11] RFR(S): 8205472: Deadlock in Kitchensink when trying to
 print compile queues causing timeout
In-Reply-To: <63CB0D40-4CE2-4C4B-B26F-40A2DB011016@oracle.com>
References: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
 <63CB0D40-4CE2-4C4B-B26F-40A2DB011016@oracle.com>
Message-ID: <57e13e0b-a82b-5fe6-e416-a5c4debcd2ae@oracle.com>

Hi Kim,

thanks for the review.

Best regards,
Tobias

On 09.07.2018 19:33, Kim Barrett wrote:
>> On Jul 9, 2018, at 7:58 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>
>> Hi,
>>
>> please review the following patch:
>> https://bugs.openjdk.java.net/browse/JDK-8205472
>> http://cr.openjdk.java.net/~thartmann/8205472/webrev.00/
>>
>> When registering a compiled method in ciEnv::register_method() the compiler thread acquires the
>> MethodCompileQueue_lock and then performs a safepoint check before acquiring the Compile_lock as
>> well. If we enter a safepoint, the compiler thread is still holding the MethodCompileQueue_lock
>> while the VM thread may execute the VM_PrintCompileQueue VM operation which requires the
>> MethodCompileQueue_lock as well. We deadlock.
>>
>> This bug is very intermittent and I was only able to reproduce it by modifying the VM to always
>> enter a safepoint (see comments in JIRA). The solution is to not acquire the MethodCompileQueue_lock
>> in CompileBroker::print_compile_queues() because we only execute that code at a safepoint anyway
>> (VM_PrintCompileQueue has evaluation_mode() == _safepoint).
>>
>> Thanks,
>> Tobias
> 
> Looks good.
> 

From tobias.hartmann at oracle.com  Tue Jul 10 07:26:41 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 10 Jul 2018 09:26:41 +0200
Subject: [11] RFR(S): 8205472: Deadlock in Kitchensink when trying to
 print compile queues causing timeout
In-Reply-To: <2ae8e23f-f246-c43e-1657-3cd335e6aff5@oracle.com>
References: <e1d9c5f4-0651-a702-633a-0c9230d31b94@oracle.com>
 <2ae8e23f-f246-c43e-1657-3cd335e6aff5@oracle.com>
Message-ID: <7c72b8ba-c2d5-68c8-b007-f8ce1dccdeb9@oracle.com>

Hi David,

thanks for the review.

On 10.07.2018 04:16, David Holmes wrote:
> Note that what you describe is only one half of the safety issue here. Executing the code only at a
> safepoint ensures some degree of mutual exclusion, but you also have to ensure that other code that
> would acquire that lock, can not enter a safepoint with that lock held, when the state protected by
> the lock may be inconsistent with the logic that will be executed at the safepoint.

Yes, ciEnv::register_method() has a NoSafepointVerifier right after acquiring the locks and as far
as I can tell other code that acquires the MethodCompileQueue_lock should not enter a safepoint with
an inconsistent state that would break the CompileBroker::print_compile_queues() code.

Thanks,
Tobias

From aph at redhat.com  Tue Jul 10 08:31:33 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 10 Jul 2018 09:31:33 +0100
Subject: Will there be any "Graal Sync" for JDK 11 repo
In-Reply-To: <DB6PR0802MB21505CEA026F324448BE54C69D5B0@DB6PR0802MB2150.eurprd08.prod.outlook.com>
References: <DB6PR0802MB21505CEA026F324448BE54C69D5B0@DB6PR0802MB2150.eurprd08.prod.outlook.com>
Message-ID: <74d8e82e-b9e0-f086-ad42-2188ed19450f@redhat.com>

On 07/10/2018 04:24 AM, Zhongwei Yao wrote:
> If not, shall I manually fix it in JDK11?

Yes.  Propose it and I'll review it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From kevin.walls at oracle.com  Tue Jul 10 09:58:14 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Tue, 10 Jul 2018 10:58:14 +0100
Subject: RFR: 8205677: [8u] casts and type change for 8u to enable later
 Windows compilers
In-Reply-To: <1e4b6a41-e782-05c4-429a-12229d2acf3a@oracle.com>
References: <10a72c45-c34a-599a-b771-08d5a7083c62@oracle.com>
 <0150c644-5b70-84ff-0ee7-3874e4318e6a@oracle.com>
 <1e4b6a41-e782-05c4-429a-12229d2acf3a@oracle.com>
Message-ID: <5ee0a35d-38b3-5092-283a-08eeade4d47e@oracle.com>

Thanks David --

#5: My initial webrev changing only the return type of 
OopMapCache::memory_size() isn't going to work everywhere, the VS2017 
compiler doesn't accept a size_t into a printf %l format, so we would 
still want a cast to make that line work.

But it is odd that the fprintf line uses UINTX_FORMAT_W for the two 
items which are the result of "size_t / size_t", but then uses %l rather 
than INTX_FORMAT_W for the result of "long / size_t".

INTX_FORMAT_W does work, but as it's a size, and shouldn't really be 
signed anyway, making OopMapCache::memory_usage()? return size_t and 
changing the fprintf format to UINTX_FORMAT_W to match the others makes 
things consistent.

http://cr.openjdk.java.net/~kevinw/8205677/webrev.02/

Thanks!
Kevin




On 09/07/2018 05:08, David Holmes wrote:
> Hi Kevin,
>
> All seems fine. One comment below.
>
> On 6/07/2018 10:27 PM, Kevin Walls wrote:
>> Hi,
>>
>> I'd like to update my review request:
>>
>> Item #3, was solved by 8150426 so no change required.
>>
>> Item #5, changing the return type of the method is not necessary.? 
>> The error was in src/share/vm/runtime/memprofiler.cpp and can be 
>> solved with a cast on the offending line.? The result of a long 
>> divided by a size_t can be cast to a long, and that minimal change is 
>> accepted in all the builds:
>>
>> -????????? OopMapCache::memory_usage() / K);
>> +????????? (long) (OopMapCache::memory_usage() / K));
>
> I actually thing the correct thing to do is change the return type. We 
> should generally never use a raw C long in hotspot due to its varying 
> size depending on platform (ILP32, LP64, LLP64). But that goes beyond 
> addressing a compiler warning.
>
> Thanks,
> David
>
>> Additionally, I've uncovered one more required cast, so item #6 is 
>> src/share/vm/classfile/classFileParser.cpp changing an (int) cast to 
>> a (u2).
>>
>> New webrev at http://cr.openjdk.java.net/~kevinw/8205677/webrev.01/
>>
>> Progress report: with these changes, 8206454 which I just put out for 
>> review, and one other change re: vnsprintf, the open jdk8u builds 
>> with VS2017.
>>
>> Many thanks!
>> Kevin
>>
>>
>>
>>
>>
>> On 05/07/2018 09:46, Kevin Walls wrote:
>>> Hi,
>>>
>>> I'd like to get a review of:
>>>
>>> 8205677: [8u] casts and type change for 8u to enable later Windows 
>>> compilers
>>> https://bugs.openjdk.java.net/browse/JDK-8205677
>>>
>>> This is a collection of new small changes aiming to permit 8u to 
>>> build with later Windows compilers (and also with the current VS2010).
>>>
>>> The changes are:
>>>
>>> 8u webrev: http://cr.openjdk.java.net/~kevinw/8205677/webrev.00/
>>>
>>> Notes:
>>>
>>> 1
>>> hotspot\src\share\vm\classfile\altHashing.cpp(227): warning C4838: 
>>> conversion from 'unsigned int' to 'const jint' requires a narrowing 
>>> conversion
>>>
>>> (jint) casts are present in the later JDK 
>>> test/hotspot/gtest/classfile/test_AltHashing.cpp and look like they 
>>> were in JDK9 from the start.
>>>
>>> 2
>>> hotspot\src\share\vm\gc_implementation\parallelScavenge\gcTaskManager.cpp(1038): 
>>> warning C4312: 'type cast': conversion from 'unsigned int' to 
>>> 'Monitor *' of greater size
>>>
>>> -? _monitor = (Monitor*) 0xDEAD000F;
>>> +? _monitor = (Monitor*) (uintptr_t) 0xDEAD000F;
>>>
>>> 3
>>> ..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): error C2440: 
>>> '=': cannot convert from 'jlong' to 'jlong *'
>>> ..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): note: Conversion 
>>> from integral type to pointer type requires reinterpret_cast, 
>>> C-style cast or function-style cast
>>>
>>> -??? *long_at_addr(which) = (long)contents;
>>> +??? *long_at_addr(which) = (jlong)contents;
>>>
>>>
>>> 4
>>> ...\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepGeneration.cpp(6833): 
>>> warning C4334: '<<': result of 32-bit shift implicitly converted to 
>>> 64 bits (was 64-bit shift intended?)
>>>
>>> Like in 8197864 where we cast a 1 to an intptr_t before the shift.
>>>
>>> ?? assert(mr.end() == (HeapWord*)round_to((intptr_t)mr.end(),
>>> -??????????????????????? (1 << (_shifter+LogHeapWordSize))),
>>> +??????????????????????? ((intptr_t) 1 << (_shifter+LogHeapWordSize))),
>>>
>>>
>>> 5
>>> hotspot\src\share\vm\runtime\memprofiler.cpp(129): warning C4477: 
>>> 'fprintf' : format string '%6ld' requires an argument of type 
>>> 'long', but variadic argument 3 has type '::size_t'
>>>
>>> OopMapCache::memory_size() is only used in one place, and only when 
>>> NOTPRODUCT.? Here in 8u, we can make it return a size_t and compile 
>>> without error.
>>>
>>> In jdk10 onwards, after 8186042, this line in memprofiler.cpp 
>>> hard-codes a 0L instead of OopMapCache::memory_size(), as the 
>>> tracking of _total_memory_size was removed, but the print was kept 
>>> to the same format.? I don't think we would remove that statistic in 
>>> an update
>>>
>>>
>>> Thanks
>>> Kevin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>


From Zhongwei.Yao at arm.com  Tue Jul 10 10:49:34 2018
From: Zhongwei.Yao at arm.com (Zhongwei Yao)
Date: Tue, 10 Jul 2018 10:49:34 +0000
Subject: Will there be any "Graal Sync" for JDK 11 repo
In-Reply-To: <74d8e82e-b9e0-f086-ad42-2188ed19450f@redhat.com>
References: <DB6PR0802MB21505CEA026F324448BE54C69D5B0@DB6PR0802MB2150.eurprd08.prod.outlook.com>,
 <74d8e82e-b9e0-f086-ad42-2188ed19450f@redhat.com>
Message-ID: <DB6PR0802MB215042EFA4E23026D58CACCF9D5B0@DB6PR0802MB2150.eurprd08.prod.outlook.com>

Sure, I will.

--
Best regards,
Zhongwei

________________________________________
From: Andrew Haley <aph at redhat.com>
Sent: Tuesday, July 10, 2018 4:31 PM
To: Zhongwei Yao; graal-dev at openjdk.java.net; hotspot-dev
Cc: nd
Subject: Re: Will there be any "Graal Sync" for JDK 11 repo

On 07/10/2018 04:24 AM, Zhongwei Yao wrote:
> If not, shall I manually fix it in JDK11?

Yes.  Propose it and I'll review it.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From erik.joelsson at oracle.com  Tue Jul 10 16:55:45 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Jul 2018 09:55:45 -0700
Subject: [11] RFR(M) 8206135: Building jvm with AOT but without JVMCI
 should fail at configure time
In-Reply-To: <c7acb02b-aa0f-d04c-dd4c-c7ae7e4f46cd@oracle.com>
References: <c7acb02b-aa0f-d04c-dd4c-c7ae7e4f46cd@oracle.com>
Message-ID: <7b745d6e-1905-f244-70c8-3ab9ad07929b@oracle.com>

Looks good, thanks for fixing this.

/Erik


On 2018-07-09 21:45, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8206135/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8206135
>
> Several configure issues was found related to jvmci, graal and aot build.
>
> Main problem is related values specified with --with-jvm-features were 
> ignored. For example, JVMCI module was still built even with 
> --with-jvm-features=-jvmci but JVMCI code was excluded from Hotspot 
> VM. AOT tool will be build but Hotspot compilation fails (as in bug 
> report) when jvmci or graal was disabled.
>
> Note, jvmci and Graal modules build and Hotspot code are controlled 
> only by --with-jvm-features flag.
>
> AOT is controlled by special --enable-aot/--diable-aot flag and 
> --with-jvm-features (inclusion of AOT code in Hotspot is controlled by 
> jvm-features check). But configure AOT code ignored 
> --with-jvm-features aot settings.
>
> Fixes:
>
> 1. Exclude jdk.internal.vm.ci module build when 
> --with-jvm-features=-jvmci specified
> 2. Removed duplicated message for forced aot disabling.
> 3. Check DISABLED_JVM_FEATURES list (negative values listed in 
> --with-jvm-features) for jvmci, graal and aot to disable them.
> 4. Disable aot if graal is disabled and issue error if aot build was 
> explicitly enabled by --enable-aot.
> 5. Issue error if --with-jvm-features=aot is specified by aot can't be 
> build or is disabled. --enable-aot should be used instead of 
> --with-jvm-features=aot because it has additional checks (presence of 
> sources).
>
> Tested with build-tier1, hs-tier1, hs-tier2. Also the same testing but 
> with --with-jvm-features=-jvmci and --with-jvm-features=-graal 
> configure flags.
>
> Thanks,
> Vladimir


From vladimir.kozlov at oracle.com  Tue Jul 10 17:00:54 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 10 Jul 2018 10:00:54 -0700
Subject: [11] RFR(M) 8206135: Building jvm with AOT but without JVMCI
 should fail at configure time
In-Reply-To: <7b745d6e-1905-f244-70c8-3ab9ad07929b@oracle.com>
References: <c7acb02b-aa0f-d04c-dd4c-c7ae7e4f46cd@oracle.com>
 <7b745d6e-1905-f244-70c8-3ab9ad07929b@oracle.com>
Message-ID: <97d6104b-947b-6d78-494e-ea53aaa28930@oracle.com>

Thank you, Erik

Vladimir

On 7/10/18 9:55 AM, Erik Joelsson wrote:
> Looks good, thanks for fixing this.
> 
> /Erik
> 
> 
> On 2018-07-09 21:45, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8206135/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8206135
>>
>> Several configure issues was found related to jvmci, graal and aot build.
>>
>> Main problem is related values specified with --with-jvm-features were ignored. For example, JVMCI module was still 
>> built even with --with-jvm-features=-jvmci but JVMCI code was excluded from Hotspot VM. AOT tool will be build but 
>> Hotspot compilation fails (as in bug report) when jvmci or graal was disabled.
>>
>> Note, jvmci and Graal modules build and Hotspot code are controlled only by --with-jvm-features flag.
>>
>> AOT is controlled by special --enable-aot/--diable-aot flag and --with-jvm-features (inclusion of AOT code in Hotspot 
>> is controlled by jvm-features check). But configure AOT code ignored --with-jvm-features aot settings.
>>
>> Fixes:
>>
>> 1. Exclude jdk.internal.vm.ci module build when --with-jvm-features=-jvmci specified
>> 2. Removed duplicated message for forced aot disabling.
>> 3. Check DISABLED_JVM_FEATURES list (negative values listed in --with-jvm-features) for jvmci, graal and aot to 
>> disable them.
>> 4. Disable aot if graal is disabled and issue error if aot build was explicitly enabled by --enable-aot.
>> 5. Issue error if --with-jvm-features=aot is specified by aot can't be build or is disabled. --enable-aot should be 
>> used instead of --with-jvm-features=aot because it has additional checks (presence of sources).
>>
>> Tested with build-tier1, hs-tier1, hs-tier2. Also the same testing but with --with-jvm-features=-jvmci and 
>> --with-jvm-features=-graal configure flags.
>>
>> Thanks,
>> Vladimir
> 

From david.griffiths at gmail.com  Tue Jul 10 17:06:28 2018
From: david.griffiths at gmail.com (David Griffiths)
Date: Tue, 10 Jul 2018 18:06:28 +0100
Subject: Bug in getPCDescNearDbg?
Message-ID: <CAF+hkWpEGXa-c=SSbtQua6c5VsV=vAR5gLTuCRr-tvfXZ2hyjg@mail.gmail.com>

I've using OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode) and
running with:

-Xcomp -XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions
'-XX:CompileCommand=print,java/math/*.*'

and looking at the resulting ScopeDesc and PCDesc descriptors. It appears
as though the BCI calculated by getPCDescNearDbg is off by one and I just
want to check if I'm interpreting things correctly.

As an example, here are some snippets of the assembler output (some lines
removed for clarity):

  0x00007fe041783348: sub    $0x1b0,%rsp        ;*aload_1
                                                ; -
java.math.BigInteger::oddModPow at 0 (line 2682)
  0x00007fe041783377: mov    %rdi,%rsi          ;*invokevirtual equals
                                                ; -
java.math.BigInteger::oddModPow at 4 (line 2682)
  0x00007fe04178338f: jne    0x00007fe041784624  ;*ifeq
                                                ; -
java.math.BigInteger::oddModPow at 7 (line 2682)
  0x00007fe041783395: mov    0xc(%rsi),%edi     ;*getfield signum
                                                ; -
java.math.BigInteger::oddModPow at 13 (line 2686)
  0x00007fe04178339b: je     0x00007fe04178460b  ;*ifne
                                                ; -
java.math.BigInteger::oddModPow at 16 (line 2686)
  0x00007fe0417833a1: mov    0x20(%rsi),%esi    ;*getfield mag
                                                ; -
java.math.BigInteger::oddModPow at 24 (line 2689)
  0x00007fe0417833af: callq  0x00007fe041046020  ; OopMap{[176]=Oop
[168]=Oop off=148}
                                                ;*invokevirtual clone
                                                ; -
java.math.BigInteger::oddModPow at 27 (line 2689)
  0x00007fe0417833de: mov    %rax,%r11          ;*checkcast
                                                ; -
java.math.BigInteger::oddModPow at 30 (line 2689)
  0x00007fe0417833e1: mov    %r11,0xd0(%rsp)
  0x00007fe0417833e9: mov    0xa8(%rsp),%rdx
  0x00007fe0417833f1: mov    0x20(%rdx),%r13d   ;*getfield mag
                                                ; -
java.math.BigInteger::oddModPow at 35 (line 2690)
  0x00007fe0417833f5: mov    %r13,0xc8(%rsp)
  0x00007fe041783405: mov    0x20(%rcx),%r8d    ;*getfield mag
                                                ; -
java.math.BigInteger::oddModPow at 41 (line 2691)

If we take the PC 7fe0417833f1 as an example then this is part of the code
for BCI 35, line 2690. If I print out the PCDesc entries I see:

real pc = 7fe04178334f, bci = 0
real pc = 7fe04178337a, bci = 4
real pc = 7fe041783384, bci = 4
real pc = 7fe041783395, bci = 7
real pc = 7fe041783398, bci = 13
real pc = 7fe0417833a1, bci = 16
real pc = 7fe0417833a4, bci = 24
real pc = 7fe0417833b4, bci = 27
real pc = 7fe0417833e1, bci = 30
real pc = 7fe0417833f5, bci = 35
real pc = 7fe041783409, bci = 41

So it appears that the "real pc" address 7fe0417833f5 represents the _end_
of BCI 35. But getPCDescNearDbg obviously interprets these real pc
addresses as the _beginning_ of the code for that BCI and thus gets the
wrong line number.

Is this a bug in getPCDescNearDbg or am I misinterpreting things?

Cheers,

David

From lois.foltan at oracle.com  Tue Jul 10 18:58:47 2018
From: lois.foltan at oracle.com (Lois Foltan)
Date: Tue, 10 Jul 2018 14:58:47 -0400
Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
 include module and class loader information
In-Reply-To: <f5667bfb-4139-ba72-ef57-4ff014da0ce6@oracle.com>
References: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
 <f5667bfb-4139-ba72-ef57-4ff014da0ce6@oracle.com>
Message-ID: <b4b8affc-3abb-2552-70a7-f90f663464e3@oracle.com>

On 7/5/2018 10:06 AM, Harold David Seigel wrote:

> Hi Lois,
>
> This change looks good!
>
> Can you fix the indentation at lines 523 - 525 and 1262 - 1264 in 
> klassVtable.cpp?? No need for a new webrev.

Thanks Harold for the review! I fixed the indentation.
Lois

>
> Thanks, Harold
>
>
> On 6/27/2018 9:20 AM, Lois Foltan wrote:
>> Please review this change to migrate existing loader constraint 
>> LinkageErrors to the new error message format proposal.? The actual 
>> wording of the loader constraint messages has not changed. Module and 
>> class loader information have been moved into the error message's 
>> REASON section.? This change also removes the method 
>> java_lang_ClassLoader::describe_external() in favor of 
>> Klass::class_in_module_of_loader().
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611/webrev/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8205611
>>
>> JDK-8166633 outlines a new proposal where error messages follow a 
>> format of ERRROR: PROBLEM (REASON) where the PROBLEM is aggressively 
>> simple (and definitely avoids arbitrary-length loader names) so the 
>> REASON bears all the cost of explaining the PROBLEM with more 
>> specifics.? See the proposal in more detail at 
>> https://bugs.openjdk.java.net/browse/JDK-8166633. The new utility 
>> method Klass::class_in_module_of_loader() implements the proposed 
>> format.
>>
>> Some example text:
>>
>> (JDK 11) 'DuplicateLE_Test_Loader_IF' @<id> (instance of 
>> PreemptingClassLoader, child of 'app' 
>> jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate 
>> interface definition for test.J.
>> to
>> (JDK 12) loader 'DuplicateLE_Test_Loader_IF' @6eeee674 attempted 
>> duplicate interface definition for test.J. (test.J is in unnamed 
>> module of loader 'DuplicateLE_Test_Loader_IF' @6eeee674, parent 
>> loader 'app')
>>
>>
>> (JDK 11) loader constraint violation: loader PreemptingClassLoader 
>> @<id> (instance of PreemptingClassLoader, child of 'app' 
>> jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load class 
>> test.D_ambgs. A different class with the same name was previously 
>> loaded by 'app' (instance of 
>> jdk.internal.loader.ClassLoaders$AppClassLoader).
>> to
>> (JDK 12) loader constraint violation: loader PreemptingClassLoader 
>> @5bc79a1c wants to load class test.D_ambgs. A different class with 
>> the same name was previously loaded by 'app'. (test.D_ambgs is in 
>> unnamed module of loader 'app')
>>
>>
>> (JDK 11) loader constraint violation for class test.Task: when 
>> selecting overriding method test.Task.m()Ltest/Foo; the class loader 
>> PreemptingClassLoader @<id> (instance of PreemptingClassLoader, child 
>> of 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) of the 
>> selected method's type test.Task, and the class loader 'app' 
>> (instance of jdk.internal.loader.ClassLoaders$AppClassLoader) for its 
>> super type test.J have different Class objects for the type test.Foo 
>> used in the signature
>> to
>> (JDK 12) loader constraint violation for class test.Task: when 
>> selecting overriding method test.Task.m()Ltest/Foo; the class loader 
>> PreemptingClassLoader @7884e077 of the selected method's type 
>> test.Task, and the class loader 'app' for its super type test.J have 
>> different Class objects for the type test.Foo used in the signature 
>> (test.Task is in unnamed module of loader PreemptingClassLoader 
>> @7884e077, parent loader 'app'; test.J is in unnamed module of loader 
>> 'app')
>>
>>
>> Testing: hs-tier(1-3), jdk-tier(1-3) complete
>> ?????????????? hs-tier(4,5) in progress
>> ?????????????? JCK vm, lang in progress
>>
>> Thanks,
>> Lois
>


From gromero at linux.vnet.ibm.com  Tue Jul 10 20:14:44 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 10 Jul 2018 17:14:44 -0300
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
Message-ID: <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>

Hi Swati,

As David pointed out, it's necessary to determine if that bug qualifies as P3 in
order to get it into JDK 11 RDP1.

AFAICS, that bug was never triaged explicitly and got its current priority (P4)
from the default.

Once it's defined the correct integration version, I can sponsor that change
for you. I think there won't be any updates for JDK 11 (contrary to what
happened for JDK 10), but I think we can understand how distros are handling
it and so find out if there is a possibility to get the change into the
distros once it's pushed to JDK 12.


David, Alan,

I could not find a documentation on how to formally triage a bug. For instance,
on [1] I see Alan used some markers as "ILW =" and "MLH = " but I don't know if
these markers are only for Oracle internal control. Do you know how could I
triage that bug? I understand its risk of integration is small but even tho I
think it's necessary to bring up additional information on that to combine in a
final bug priority.

Thanks.


Best regards,
Gustavo

[1] https://bugs.openjdk.java.net/browse/JDK-8206953

On 07/03/2018 03:06 AM, David Holmes wrote:
> Looks fine.
> 
> Thanks,
> David
> 
> On 3/07/2018 3:08 PM, Swati Sharma wrote:
>> Hi David,
>>
>> I have added NULL check for _numa_bitmask_isbitset in isbound_to_single_node() method.
>>
>> Hosted:http://cr.openjdk.java.net/~gromero/8189922/v2/ <http://cr.openjdk.java.net/~gromero/8189922/v2/>
>>
>> Swati
>>
>> On Mon, Jul 2, 2018 at 5:54 AM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Swati,
>>
>>     I took a look at this though I'm not familiar with the functional
>>     operation of the NUMA API's - I'm relying on Gustavo and Derek to
>>     spot any actual usage errors there.
>>
>>     In isbound_to_single_node() there is no NULL check for
>>     _numa_bitmask_isbitset (which seems to be the normal pattern for
>>     using all of these function pointers).
>>
>>     Otherwise this seems fine.
>>
>>     Thanks,
>>     David
>>
>>
>>     On 30/06/2018 2:46 AM, Swati Sharma wrote:
>>
>>            Hi,
>>
>>         Could I get a review for this change that affects the JVM when
>>         there are
>>         pinned memory nodes please?
>>
>>         It's already reviewed and tested on PPC64 and on AARCH64 by
>>         Gustavo and
>>         Derek, however both are not Reviewers so I need additional
>>         reviews for that
>>         change.
>>
>>
>>         Thanks in advance.
>>
>>         Swati
>>
>>         On Tue, Jun 19, 2018 at 5:58 PM, Swati Sharma
>>         <swatibits14 at gmail.com <mailto:swatibits14 at gmail.com>> wrote:
>>
>>             Hi All,
>>
>>             Here is the numa information of the system :
>>             swati at java-diesel1:~$ numactl -H
>>             available: 8 nodes (0-7)
>>             node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
>>             node 0 size: 64386 MB
>>             node 0 free: 64134 MB
>>             node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
>>             node 1 size: 64509 MB
>>             node 1 free: 64232 MB
>>             node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
>>             node 2 size: 64509 MB
>>             node 2 free: 64215 MB
>>             node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
>>             node 3 size: 64509 MB
>>             node 3 free: 64157 MB
>>             node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 102 103
>>             node 4 size: 64509 MB
>>             node 4 free: 64336 MB
>>             node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109
>>             110 111
>>             node 5 size: 64509 MB
>>             node 5 free: 64352 MB
>>             node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117
>>             118 119
>>             node 6 size: 64509 MB
>>             node 6 free: 64359 MB
>>             node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125
>>             126 127
>>             node 7 size: 64508 MB
>>             node 7 free: 64350 MB
>>             node distances:
>>             node   0   1   2   3   4   5   6   7
>>                 0:  10  16  16  16  32  32  32  32
>>                 1:  16  10  16  16  32  32  32  32
>>                 2:  16  16  10  16  32  32  32  32
>>                 3:  16  16  16  10  32  32  32  32
>>                 4:  32  32  32  32  10  16  16  16
>>                 5:  32  32  32  32  16  10  16  16
>>                 6:  32  32  32  32  16  16  10  16
>>                 7:  32  32  32  32  16  16  16  10
>>
>>             Thanks,
>>             Swati
>>
>>             On Tue, Jun 19, 2018 at 12:00 AM, Gustavo Romero <
>>             gromero at linux.vnet.ibm.com
>>             <mailto:gromero at linux.vnet.ibm.com>> wrote:
>>
>>                 Hi Swati,
>>
>>                 On 06/16/2018 02:52 PM, Swati Sharma wrote:
>>
>>                     Hi All,
>>
>>                     This is my first patch,I would appreciate if anyone
>>                     can review the fix:
>>
>>                     Bug :
>>                     https://bugs.openjdk.java.net/browse/JDK-8189922
>>                     <https://bugs.openjdk.java.net/browse/JDK-8189922> <
>>                     https://bugs.openjdk.java.net/browse/JDK-8189922
>>                     <https://bugs.openjdk.java.net/browse/JDK-8189922>>
>>                     Webrev
>>                     :http://cr.openjdk.java.net/~gromero/8189922/v1
>>                     <http://cr.openjdk.java.net/~gromero/8189922/v1>
>>
>>                     The bug is about JVM flag UseNUMA which bypasses the
>>                     user specified
>>                     numactl --membind option and divides the whole heap
>>                     in lgrps according to
>>                     available numa nodes.
>>
>>                     The proposed solution is to disable UseNUMA if bound
>>                     to single numa
>>                     node. In case more than one numa node binding,
>>                     create the lgrps according
>>                     to bound nodes.If there is no binding, then JVM will
>>                     divide the whole heap
>>                     based on the number of NUMA nodes available on the
>>                     system.
>>
>>                     I appreciate Gustavo's help for fixing the thread
>>                     allocation based on
>>                     numa distance for membind which was a dangling issue
>>                     associated with main
>>                     patch.
>>
>>
>>                 Thanks. I have no further comments on it. LGTM.
>>
>>
>>                 Best regards,
>>                 Gustavo
>>
>>                 PS: Please, provide numactl -H information when
>>                 possible. It helps to
>>                 grasp
>>                 promptly the actual NUMA topology in question :)
>>
>>                 Tested the fix by running specjbb2015 composite workload
>>                 on 8 NUMA node
>>
>>                     system.
>>                     Case 1 : Single NUMA node bind
>>                     numactl --cpunodebind=0 --membind=0 java -Xmx24g
>>                     -Xms24g -Xmn22g
>>                     -XX:+UseNUMA
>>                     -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>>                     <composite_application>
>>                     Before Patch: gc.log
>>                     eden space 22511616K(22GB), 12% used
>>                            lgrp 0 space 2813952K, 100% used
>>                            lgrp 1 space 2813952K, 0% used
>>                            lgrp 2 space 2813952K, 0% used
>>                            lgrp 3 space 2813952K, 0% used
>>                            lgrp 4 space 2813952K, 0% used
>>                            lgrp 5 space 2813952K, 0% used
>>                            lgrp 6 space 2813952K, 0% used
>>                            lgrp 7 space 2813952K, 0% used
>>                     After Patch : gc.log
>>                     eden space 46718976K(45GB), 99% used(NUMA disabled)
>>
>>                     Case 2 : Multiple NUMA node bind
>>                     numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g
>>                     -Xmx50g -Xmn45g
>>                     -XX:+UseNUMA
>>                     -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>>                     <composite_application>
>>                     Before Patch :gc.log
>>                     eden space 46718976K, 6% used
>>                            lgrp 0 space 5838848K, 14% used
>>                            lgrp 1 space 5838848K, 0% used
>>                            lgrp 2 space 5838848K, 0% used
>>                            lgrp 3 space 5838848K, 0% used
>>                            lgrp 4 space 5838848K, 0% used
>>                            lgrp 5 space 5838848K, 0% used
>>                            lgrp 6 space 5838848K, 0% used
>>                            lgrp 7 space 5847040K, 35% used
>>                     After Patch : gc.log
>>                     eden space 46718976K(45GB), 99% used
>>                             lgrp 0 space 23359488K(23.5GB), 100% used
>>                             lgrp 7 space 23359488K(23.5GB), 99% used
>>
>>
>>                     Note: The proposed solution is only for numactl
>>                     membind option.The fix
>>                     is not for --cpunodebind and localalloc which is a
>>                     separate bug bug
>>                     https://bugs.openjdk.java.net/browse/JDK-8205051
>>                     <https://bugs.openjdk.java.net/browse/JDK-8205051>
>>                     and fix is in progress
>>                     on this.
>>
>>                     Thanks,
>>                     Swati Sharma
>>                     Software Engineer -2 at AMD
>>
>>
>>
>>
>>
> 


From kim.barrett at oracle.com  Tue Jul 10 20:18:11 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 10 Jul 2018 16:18:11 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r 
Message-ID: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>

Please review this change to the various os::readdir implementations
for POSIX platforms to no longer use readdir_r, but instead use
readdir.  readdir_r has been deprecated by glibc and at least some BSD
variants, and seems to have been a mistake from the get-go.  See the
readdir_r Portability Note in recent versions of the glibc
documentation, e.g.
https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html.

Because we're no longer using readdir_r, the second argument for
os::readdir is now unused by any platform's implementation.  So we've
removed that argument, as well as the associated helper function
os::readdir_buf_size().  All callers have been updated to no longer
allocate and pass along the buffer for the second argument.

As part of this, merged all the (now identical) non-Windows
implementations of os::opendir, os::readdir, and os::closedir into
os_posix.cpp.  This means the os wrappers are no longer inlined, but
these aren't performance critical.

This also eliminated some "approximations" of the proper size for the
dirent argument that weren't correct (c.f. the deprecation rationale).
These places should have been using readdir_buf_size(), which would
have forced some of them to use C heap instead of stack allocation.

Eliminating the 2nd argument for os::readdir required fixing some uses
in jfr.  Some implementations of
SystemProcessInterface::SystemProcesses::ProcessIterator assumed the
second argument would always contain the same information as the
result, when the result is non-NULL.  But that was not part of the
os::readdir contract, and was never true for the Windows port (though
the Windows port uses a different mechanism for getting process info).
With JDK-8179887 it is no longer true for the Linux port either, which
broke some things in jfr; see JDK-8202835.  That bug is being fixed as
part of changing jfr for the new os::readdir signature, and the
relevant test is being reinstated.

Also updated various unqualified calls to opendir/closedir that were
actually calling the dirent.h functions directly to instead use the os
wrappers, for consistency.

Note that this is undoing the readdir-related parts of JDK-4647546.  

CR:
https://bugs.openjdk.java.net/browse/JDK-8202353
https://bugs.openjdk.java.net/browse/JDK-8202835

Webrev:
http://cr.openjdk.java.net/~kbarrett/8202353/open.00/

Testing:
mach5 tier1-5.
tier5 is where TestSystemProcess.java is run.
There are a number of jfr tests in tier3-4 that use process iterators on
relevant platforms.
There are tests related to PerfCounters scattered through tier1-3.


From david.holmes at oracle.com  Tue Jul 10 21:39:04 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Jul 2018 07:39:04 +1000
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
 <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
Message-ID: <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>

Hi Gustavo,

On 11/07/2018 6:14 AM, Gustavo Romero wrote:
> Hi Swati,
> 
> As David pointed out, it's necessary to determine if that bug qualifies 
> as P3 in order to get it into JDK 11 RDP1.
> 
> AFAICS, that bug was never triaged explicitly and got its current 
> priority (P4) from the default.

Actually no, the P4 was from the (Oracle internal) ILW prioritization 
scheme.

For this to be a P3 it needs to be shown either that the impact is quite 
significant (IIUC it's only a mild performance issue based on the bug 
report); or that the likelihood of this being encountered is very high 
(again it seems not that likely based on the info in the bug report).

HTH.

David
-----


> 
> Once it's defined the correct integration version, I can sponsor that 
> change
> for you. I think there won't be any updates for JDK 11 (contrary to what
> happened for JDK 10), but I think we can understand how distros are 
> handling
> it and so find out if there is a possibility to get the change into the
> distros once it's pushed to JDK 12.
> 
> 
> David, Alan,
> 
> I could not find a documentation on how to formally triage a bug. For 
> instance,
> on [1] I see Alan used some markers as "ILW =" and "MLH = " but I don't 
> know if
> these markers are only for Oracle internal control. Do you know how could I
> triage that bug? I understand its risk of integration is small but even 
> tho I
> think it's necessary to bring up additional information on that to 
> combine in a
> final bug priority.
> 
> Thanks.
> 
> 
> Best regards,
> Gustavo
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8206953
> 
> On 07/03/2018 03:06 AM, David Holmes wrote:
>> Looks fine.
>>
>> Thanks,
>> David
>>
>> On 3/07/2018 3:08 PM, Swati Sharma wrote:
>>> Hi David,
>>>
>>> I have added NULL check for _numa_bitmask_isbitset in 
>>> isbound_to_single_node() method.
>>>
>>> Hosted:http://cr.openjdk.java.net/~gromero/8189922/v2/ 
>>> <http://cr.openjdk.java.net/~gromero/8189922/v2/>
>>>
>>> Swati
>>>
>>> On Mon, Jul 2, 2018 at 5:54 AM, David Holmes <david.holmes at oracle.com 
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> ??? Hi Swati,
>>>
>>> ??? I took a look at this though I'm not familiar with the functional
>>> ??? operation of the NUMA API's - I'm relying on Gustavo and Derek to
>>> ??? spot any actual usage errors there.
>>>
>>> ??? In isbound_to_single_node() there is no NULL check for
>>> ??? _numa_bitmask_isbitset (which seems to be the normal pattern for
>>> ??? using all of these function pointers).
>>>
>>> ??? Otherwise this seems fine.
>>>
>>> ??? Thanks,
>>> ??? David
>>>
>>>
>>> ??? On 30/06/2018 2:46 AM, Swati Sharma wrote:
>>>
>>> ?????????? Hi,
>>>
>>> ??????? Could I get a review for this change that affects the JVM when
>>> ??????? there are
>>> ??????? pinned memory nodes please?
>>>
>>> ??????? It's already reviewed and tested on PPC64 and on AARCH64 by
>>> ??????? Gustavo and
>>> ??????? Derek, however both are not Reviewers so I need additional
>>> ??????? reviews for that
>>> ??????? change.
>>>
>>>
>>> ??????? Thanks in advance.
>>>
>>> ??????? Swati
>>>
>>> ??????? On Tue, Jun 19, 2018 at 5:58 PM, Swati Sharma
>>> ??????? <swatibits14 at gmail.com <mailto:swatibits14 at gmail.com>> wrote:
>>>
>>> ??????????? Hi All,
>>>
>>> ??????????? Here is the numa information of the system :
>>> ??????????? swati at java-diesel1:~$ numactl -H
>>> ??????????? available: 8 nodes (0-7)
>>> ??????????? node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
>>> ??????????? node 0 size: 64386 MB
>>> ??????????? node 0 free: 64134 MB
>>> ??????????? node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
>>> ??????????? node 1 size: 64509 MB
>>> ??????????? node 1 free: 64232 MB
>>> ??????????? node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
>>> ??????????? node 2 size: 64509 MB
>>> ??????????? node 2 free: 64215 MB
>>> ??????????? node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
>>> ??????????? node 3 size: 64509 MB
>>> ??????????? node 3 free: 64157 MB
>>> ??????????? node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 
>>> 102 103
>>> ??????????? node 4 size: 64509 MB
>>> ??????????? node 4 free: 64336 MB
>>> ??????????? node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109
>>> ??????????? 110 111
>>> ??????????? node 5 size: 64509 MB
>>> ??????????? node 5 free: 64352 MB
>>> ??????????? node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117
>>> ??????????? 118 119
>>> ??????????? node 6 size: 64509 MB
>>> ??????????? node 6 free: 64359 MB
>>> ??????????? node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125
>>> ??????????? 126 127
>>> ??????????? node 7 size: 64508 MB
>>> ??????????? node 7 free: 64350 MB
>>> ??????????? node distances:
>>> ??????????? node?? 0?? 1?? 2?? 3?? 4?? 5?? 6?? 7
>>> ??????????????? 0:? 10? 16? 16? 16? 32? 32? 32? 32
>>> ??????????????? 1:? 16? 10? 16? 16? 32? 32? 32? 32
>>> ??????????????? 2:? 16? 16? 10? 16? 32? 32? 32? 32
>>> ??????????????? 3:? 16? 16? 16? 10? 32? 32? 32? 32
>>> ??????????????? 4:? 32? 32? 32? 32? 10? 16? 16? 16
>>> ??????????????? 5:? 32? 32? 32? 32? 16? 10? 16? 16
>>> ??????????????? 6:? 32? 32? 32? 32? 16? 16? 10? 16
>>> ??????????????? 7:? 32? 32? 32? 32? 16? 16? 16? 10
>>>
>>> ??????????? Thanks,
>>> ??????????? Swati
>>>
>>> ??????????? On Tue, Jun 19, 2018 at 12:00 AM, Gustavo Romero <
>>> ??????????? gromero at linux.vnet.ibm.com
>>> ??????????? <mailto:gromero at linux.vnet.ibm.com>> wrote:
>>>
>>> ??????????????? Hi Swati,
>>>
>>> ??????????????? On 06/16/2018 02:52 PM, Swati Sharma wrote:
>>>
>>> ??????????????????? Hi All,
>>>
>>> ??????????????????? This is my first patch,I would appreciate if anyone
>>> ??????????????????? can review the fix:
>>>
>>> ??????????????????? Bug :
>>> ??????????????????? https://bugs.openjdk.java.net/browse/JDK-8189922
>>> ??????????????????? <https://bugs.openjdk.java.net/browse/JDK-8189922> <
>>> ??????????????????? https://bugs.openjdk.java.net/browse/JDK-8189922
>>> ??????????????????? <https://bugs.openjdk.java.net/browse/JDK-8189922>>
>>> ??????????????????? Webrev
>>> ??????????????????? :http://cr.openjdk.java.net/~gromero/8189922/v1
>>> ??????????????????? <http://cr.openjdk.java.net/~gromero/8189922/v1>
>>>
>>> ??????????????????? The bug is about JVM flag UseNUMA which bypasses the
>>> ??????????????????? user specified
>>> ??????????????????? numactl --membind option and divides the whole heap
>>> ??????????????????? in lgrps according to
>>> ??????????????????? available numa nodes.
>>>
>>> ??????????????????? The proposed solution is to disable UseNUMA if bound
>>> ??????????????????? to single numa
>>> ??????????????????? node. In case more than one numa node binding,
>>> ??????????????????? create the lgrps according
>>> ??????????????????? to bound nodes.If there is no binding, then JVM will
>>> ??????????????????? divide the whole heap
>>> ??????????????????? based on the number of NUMA nodes available on the
>>> ??????????????????? system.
>>>
>>> ??????????????????? I appreciate Gustavo's help for fixing the thread
>>> ??????????????????? allocation based on
>>> ??????????????????? numa distance for membind which was a dangling issue
>>> ??????????????????? associated with main
>>> ??????????????????? patch.
>>>
>>>
>>> ??????????????? Thanks. I have no further comments on it. LGTM.
>>>
>>>
>>> ??????????????? Best regards,
>>> ??????????????? Gustavo
>>>
>>> ??????????????? PS: Please, provide numactl -H information when
>>> ??????????????? possible. It helps to
>>> ??????????????? grasp
>>> ??????????????? promptly the actual NUMA topology in question :)
>>>
>>> ??????????????? Tested the fix by running specjbb2015 composite workload
>>> ??????????????? on 8 NUMA node
>>>
>>> ??????????????????? system.
>>> ??????????????????? Case 1 : Single NUMA node bind
>>> ??????????????????? numactl --cpunodebind=0 --membind=0 java -Xmx24g
>>> ??????????????????? -Xms24g -Xmn22g
>>> ??????????????????? -XX:+UseNUMA
>>> ??????????????????? -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>>> ??????????????????? <composite_application>
>>> ??????????????????? Before Patch: gc.log
>>> ??????????????????? eden space 22511616K(22GB), 12% used
>>> ?????????????????????????? lgrp 0 space 2813952K, 100% used
>>> ?????????????????????????? lgrp 1 space 2813952K, 0% used
>>> ?????????????????????????? lgrp 2 space 2813952K, 0% used
>>> ?????????????????????????? lgrp 3 space 2813952K, 0% used
>>> ?????????????????????????? lgrp 4 space 2813952K, 0% used
>>> ?????????????????????????? lgrp 5 space 2813952K, 0% used
>>> ?????????????????????????? lgrp 6 space 2813952K, 0% used
>>> ?????????????????????????? lgrp 7 space 2813952K, 0% used
>>> ??????????????????? After Patch : gc.log
>>> ??????????????????? eden space 46718976K(45GB), 99% used(NUMA disabled)
>>>
>>> ??????????????????? Case 2 : Multiple NUMA node bind
>>> ??????????????????? numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g
>>> ??????????????????? -Xmx50g -Xmn45g
>>> ??????????????????? -XX:+UseNUMA
>>> ??????????????????? -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>>> ??????????????????? <composite_application>
>>> ??????????????????? Before Patch :gc.log
>>> ??????????????????? eden space 46718976K, 6% used
>>> ?????????????????????????? lgrp 0 space 5838848K, 14% used
>>> ?????????????????????????? lgrp 1 space 5838848K, 0% used
>>> ?????????????????????????? lgrp 2 space 5838848K, 0% used
>>> ?????????????????????????? lgrp 3 space 5838848K, 0% used
>>> ?????????????????????????? lgrp 4 space 5838848K, 0% used
>>> ?????????????????????????? lgrp 5 space 5838848K, 0% used
>>> ?????????????????????????? lgrp 6 space 5838848K, 0% used
>>> ?????????????????????????? lgrp 7 space 5847040K, 35% used
>>> ??????????????????? After Patch : gc.log
>>> ??????????????????? eden space 46718976K(45GB), 99% used
>>> ??????????????????????????? lgrp 0 space 23359488K(23.5GB), 100% used
>>> ??????????????????????????? lgrp 7 space 23359488K(23.5GB), 99% used
>>>
>>>
>>> ??????????????????? Note: The proposed solution is only for numactl
>>> ??????????????????? membind option.The fix
>>> ??????????????????? is not for --cpunodebind and localalloc which is a
>>> ??????????????????? separate bug bug
>>> ??????????????????? https://bugs.openjdk.java.net/browse/JDK-8205051
>>> ??????????????????? <https://bugs.openjdk.java.net/browse/JDK-8205051>
>>> ??????????????????? and fix is in progress
>>> ??????????????????? on this.
>>>
>>> ??????????????????? Thanks,
>>> ??????????????????? Swati Sharma
>>> ??????????????????? Software Engineer -2 at AMD
>>>
>>>
>>>
>>>
>>>
>>
> 

From david.holmes at oracle.com  Tue Jul 10 23:22:42 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Jul 2018 09:22:42 +1000
Subject: RFR: 8205677: [8u] casts and type change for 8u to enable later
 Windows compilers
In-Reply-To: <5ee0a35d-38b3-5092-283a-08eeade4d47e@oracle.com>
References: <10a72c45-c34a-599a-b771-08d5a7083c62@oracle.com>
 <0150c644-5b70-84ff-0ee7-3874e4318e6a@oracle.com>
 <1e4b6a41-e782-05c4-429a-12229d2acf3a@oracle.com>
 <5ee0a35d-38b3-5092-283a-08eeade4d47e@oracle.com>
Message-ID: <fc1e0c84-b8e9-5067-fb4f-4544f86d4644@oracle.com>

On 10/07/2018 7:58 PM, Kevin Walls wrote:
> Thanks David --
> 
> #5: My initial webrev changing only the return type of 
> OopMapCache::memory_size() isn't going to work everywhere, the VS2017 
> compiler doesn't accept a size_t into a printf %l format, so we would 
> still want a cast to make that line work.

Well we should never be using %l either.

> But it is odd that the fprintf line uses UINTX_FORMAT_W for the two 
> items which are the result of "size_t / size_t", but then uses %l rather 
> than INTX_FORMAT_W for the result of "long / size_t".
> 
> INTX_FORMAT_W does work, but as it's a size, and shouldn't really be 
> signed anyway, making OopMapCache::memory_usage()? return size_t and 
> changing the fprintf format to UINTX_FORMAT_W to match the others makes 
> things consistent.
> 
> http://cr.openjdk.java.net/~kevinw/8205677/webrev.02/

That looks good to me. Use of size_t makes more sense to me.

Thanks,
David

> Thanks!
> Kevin
> 
> 
> 
> 
> On 09/07/2018 05:08, David Holmes wrote:
>> Hi Kevin,
>>
>> All seems fine. One comment below.
>>
>> On 6/07/2018 10:27 PM, Kevin Walls wrote:
>>> Hi,
>>>
>>> I'd like to update my review request:
>>>
>>> Item #3, was solved by 8150426 so no change required.
>>>
>>> Item #5, changing the return type of the method is not necessary. The 
>>> error was in src/share/vm/runtime/memprofiler.cpp and can be solved 
>>> with a cast on the offending line.? The result of a long divided by a 
>>> size_t can be cast to a long, and that minimal change is accepted in 
>>> all the builds:
>>>
>>> -????????? OopMapCache::memory_usage() / K);
>>> +????????? (long) (OopMapCache::memory_usage() / K));
>>
>> I actually thing the correct thing to do is change the return type. We 
>> should generally never use a raw C long in hotspot due to its varying 
>> size depending on platform (ILP32, LP64, LLP64). But that goes beyond 
>> addressing a compiler warning.
>>
>> Thanks,
>> David
>>
>>> Additionally, I've uncovered one more required cast, so item #6 is 
>>> src/share/vm/classfile/classFileParser.cpp changing an (int) cast to 
>>> a (u2).
>>>
>>> New webrev at http://cr.openjdk.java.net/~kevinw/8205677/webrev.01/
>>>
>>> Progress report: with these changes, 8206454 which I just put out for 
>>> review, and one other change re: vnsprintf, the open jdk8u builds 
>>> with VS2017.
>>>
>>> Many thanks!
>>> Kevin
>>>
>>>
>>>
>>>
>>>
>>> On 05/07/2018 09:46, Kevin Walls wrote:
>>>> Hi,
>>>>
>>>> I'd like to get a review of:
>>>>
>>>> 8205677: [8u] casts and type change for 8u to enable later Windows 
>>>> compilers
>>>> https://bugs.openjdk.java.net/browse/JDK-8205677
>>>>
>>>> This is a collection of new small changes aiming to permit 8u to 
>>>> build with later Windows compilers (and also with the current VS2010).
>>>>
>>>> The changes are:
>>>>
>>>> 8u webrev: http://cr.openjdk.java.net/~kevinw/8205677/webrev.00/
>>>>
>>>> Notes:
>>>>
>>>> 1
>>>> hotspot\src\share\vm\classfile\altHashing.cpp(227): warning C4838: 
>>>> conversion from 'unsigned int' to 'const jint' requires a narrowing 
>>>> conversion
>>>>
>>>> (jint) casts are present in the later JDK 
>>>> test/hotspot/gtest/classfile/test_AltHashing.cpp and look like they 
>>>> were in JDK9 from the start.
>>>>
>>>> 2
>>>> hotspot\src\share\vm\gc_implementation\parallelScavenge\gcTaskManager.cpp(1038): 
>>>> warning C4312: 'type cast': conversion from 'unsigned int' to 
>>>> 'Monitor *' of greater size
>>>>
>>>> -? _monitor = (Monitor*) 0xDEAD000F;
>>>> +? _monitor = (Monitor*) (uintptr_t) 0xDEAD000F;
>>>>
>>>> 3
>>>> ..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): error C2440: 
>>>> '=': cannot convert from 'jlong' to 'jlong *'
>>>> ..\hotspot\src\share\vm\oops/typeArrayOop.hpp(132): note: Conversion 
>>>> from integral type to pointer type requires reinterpret_cast, 
>>>> C-style cast or function-style cast
>>>>
>>>> -??? *long_at_addr(which) = (long)contents;
>>>> +??? *long_at_addr(which) = (jlong)contents;
>>>>
>>>>
>>>> 4
>>>> ...\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepGeneration.cpp(6833): 
>>>> warning C4334: '<<': result of 32-bit shift implicitly converted to 
>>>> 64 bits (was 64-bit shift intended?)
>>>>
>>>> Like in 8197864 where we cast a 1 to an intptr_t before the shift.
>>>>
>>>> ?? assert(mr.end() == (HeapWord*)round_to((intptr_t)mr.end(),
>>>> -??????????????????????? (1 << (_shifter+LogHeapWordSize))),
>>>> +??????????????????????? ((intptr_t) 1 << (_shifter+LogHeapWordSize))),
>>>>
>>>>
>>>> 5
>>>> hotspot\src\share\vm\runtime\memprofiler.cpp(129): warning C4477: 
>>>> 'fprintf' : format string '%6ld' requires an argument of type 
>>>> 'long', but variadic argument 3 has type '::size_t'
>>>>
>>>> OopMapCache::memory_size() is only used in one place, and only when 
>>>> NOTPRODUCT.? Here in 8u, we can make it return a size_t and compile 
>>>> without error.
>>>>
>>>> In jdk10 onwards, after 8186042, this line in memprofiler.cpp 
>>>> hard-codes a 0L instead of OopMapCache::memory_size(), as the 
>>>> tracking of _total_memory_size was removed, but the print was kept 
>>>> to the same format.? I don't think we would remove that statistic in 
>>>> an update
>>>>
>>>>
>>>> Thanks
>>>> Kevin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
> 

From Derek.White at cavium.com  Tue Jul 10 23:55:25 2018
From: Derek.White at cavium.com (White, Derek)
Date: Tue, 10 Jul 2018 23:55:25 +0000
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
 <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
 <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>
Message-ID: <BL0PR07MB3890CD2AA56F084140125F75845B0@BL0PR07MB3890.namprd07.prod.outlook.com>

Hi David,

[Gustavo and others, please correct me if I'm wrong].

I think as far as impact goes, this may waste up to (N-1)/N of the young generation in some cases, where N is number of nodes. For example, on 2-socket Epyc, this could waste 7/8ths of the young gen. This has non-trivial impact on GC behavior ??

This occurs when there's a mismatch between memory binding and JVM arguments (or rather can be avoided by carefully setting JVM arguments), and I could see this happening easily when using containers.

- Derek

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of David Holmes
> Sent: Tuesday, July 10, 2018 5:39 PM
> To: Gustavo Romero <gromero at linux.vnet.ibm.com>; Swati Sharma
> <swatibits14 at gmail.com>; Alan.Bateman at oracle.com
> Cc: Prasad.Vishwanath at amd.com; hotspot-dev at openjdk.java.net;
> Prakash.Raghavendra at amd.com
> Subject: Re: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving
> vs membind
> 
> External Email
> 
> Hi Gustavo,
> 
> On 11/07/2018 6:14 AM, Gustavo Romero wrote:
> > Hi Swati,
> >
> > As David pointed out, it's necessary to determine if that bug
> > qualifies as P3 in order to get it into JDK 11 RDP1.
> >
> > AFAICS, that bug was never triaged explicitly and got its current
> > priority (P4) from the default.
> 
> Actually no, the P4 was from the (Oracle internal) ILW prioritization scheme.
> 
> For this to be a P3 it needs to be shown either that the impact is quite
> significant (IIUC it's only a mild performance issue based on the bug report);
> or that the likelihood of this being encountered is very high (again it seems
> not that likely based on the info in the bug report).
> 
> HTH.
> 
> David
> -----
> 
> 
> >
> > Once it's defined the correct integration version, I can sponsor that
> > change for you. I think there won't be any updates for JDK 11
> > (contrary to what happened for JDK 10), but I think we can understand
> > how distros are handling it and so find out if there is a possibility
> > to get the change into the distros once it's pushed to JDK 12.
> >
> >
> > David, Alan,
> >
> > I could not find a documentation on how to formally triage a bug. For
> > instance, on [1] I see Alan used some markers as "ILW =" and "MLH = "
> > but I don't know if these markers are only for Oracle internal
> > control. Do you know how could I triage that bug? I understand its
> > risk of integration is small but even tho I think it's necessary to
> > bring up additional information on that to combine in a final bug
> > priority.
> >
> > Thanks.
> >
> >
> > Best regards,
> > Gustavo
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8206953
> >
> > On 07/03/2018 03:06 AM, David Holmes wrote:
> >> Looks fine.
> >>
> >> Thanks,
> >> David
> >>
> >> On 3/07/2018 3:08 PM, Swati Sharma wrote:
> >>> Hi David,
> >>>
> >>> I have added NULL check for _numa_bitmask_isbitset in
> >>> isbound_to_single_node() method.
> >>>
> >>> Hosted:http://cr.openjdk.java.net/~gromero/8189922/v2/
> >>> <http://cr.openjdk.java.net/~gromero/8189922/v2/>
> >>>
> >>> Swati
> >>>
> >>> On Mon, Jul 2, 2018 at 5:54 AM, David Holmes
> >>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
> >>>
> >>>     Hi Swati,
> >>>
> >>>     I took a look at this though I'm not familiar with the functional
> >>>     operation of the NUMA API's - I'm relying on Gustavo and Derek to
> >>>     spot any actual usage errors there.
> >>>
> >>>     In isbound_to_single_node() there is no NULL check for
> >>>     _numa_bitmask_isbitset (which seems to be the normal pattern for
> >>>     using all of these function pointers).
> >>>
> >>>     Otherwise this seems fine.
> >>>
> >>>     Thanks,
> >>>     David
> >>>
> >>>
> >>>     On 30/06/2018 2:46 AM, Swati Sharma wrote:
> >>>
> >>>            Hi,
> >>>
> >>>         Could I get a review for this change that affects the JVM when
> >>>         there are
> >>>         pinned memory nodes please?
> >>>
> >>>         It's already reviewed and tested on PPC64 and on AARCH64 by
> >>>         Gustavo and
> >>>         Derek, however both are not Reviewers so I need additional
> >>>         reviews for that
> >>>         change.
> >>>
> >>>
> >>>         Thanks in advance.
> >>>
> >>>         Swati
> >>>
> >>>         On Tue, Jun 19, 2018 at 5:58 PM, Swati Sharma
> >>>         <swatibits14 at gmail.com <mailto:swatibits14 at gmail.com>> wrote:
> >>>
> >>>             Hi All,
> >>>
> >>>             Here is the numa information of the system :
> >>>             swati at java-diesel1:~$ numactl -H
> >>>             available: 8 nodes (0-7)
> >>>             node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
> >>>             node 0 size: 64386 MB
> >>>             node 0 free: 64134 MB
> >>>             node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
> >>>             node 1 size: 64509 MB
> >>>             node 1 free: 64232 MB
> >>>             node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
> >>>             node 2 size: 64509 MB
> >>>             node 2 free: 64215 MB
> >>>             node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
> >>>             node 3 size: 64509 MB
> >>>             node 3 free: 64157 MB
> >>>             node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101
> >>> 102 103
> >>>             node 4 size: 64509 MB
> >>>             node 4 free: 64336 MB
> >>>             node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109
> >>>             110 111
> >>>             node 5 size: 64509 MB
> >>>             node 5 free: 64352 MB
> >>>             node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117
> >>>             118 119
> >>>             node 6 size: 64509 MB
> >>>             node 6 free: 64359 MB
> >>>             node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125
> >>>             126 127
> >>>             node 7 size: 64508 MB
> >>>             node 7 free: 64350 MB
> >>>             node distances:
> >>>             node   0   1   2   3   4   5   6   7
> >>>                 0:  10  16  16  16  32  32  32  32
> >>>                 1:  16  10  16  16  32  32  32  32
> >>>                 2:  16  16  10  16  32  32  32  32
> >>>                 3:  16  16  16  10  32  32  32  32
> >>>                 4:  32  32  32  32  10  16  16  16
> >>>                 5:  32  32  32  32  16  10  16  16
> >>>                 6:  32  32  32  32  16  16  10  16
> >>>                 7:  32  32  32  32  16  16  16  10
> >>>
> >>>             Thanks,
> >>>             Swati
> >>>
> >>>             On Tue, Jun 19, 2018 at 12:00 AM, Gustavo Romero <
> >>>             gromero at linux.vnet.ibm.com
> >>>             <mailto:gromero at linux.vnet.ibm.com>> wrote:
> >>>
> >>>                 Hi Swati,
> >>>
> >>>                 On 06/16/2018 02:52 PM, Swati Sharma wrote:
> >>>
> >>>                     Hi All,
> >>>
> >>>                     This is my first patch,I would appreciate if anyone
> >>>                     can review the fix:
> >>>
> >>>                     Bug :
> >>>                     https://bugs.openjdk.java.net/browse/JDK-8189922
> >>>                     <https://bugs.openjdk.java.net/browse/JDK-8189922> <
> >>>                     https://bugs.openjdk.java.net/browse/JDK-8189922
> >>>                     <https://bugs.openjdk.java.net/browse/JDK-8189922>>
> >>>                     Webrev
> >>>                     :http://cr.openjdk.java.net/~gromero/8189922/v1
> >>>                     <http://cr.openjdk.java.net/~gromero/8189922/v1>
> >>>
> >>>                     The bug is about JVM flag UseNUMA which bypasses the
> >>>                     user specified
> >>>                     numactl --membind option and divides the whole heap
> >>>                     in lgrps according to
> >>>                     available numa nodes.
> >>>
> >>>                     The proposed solution is to disable UseNUMA if bound
> >>>                     to single numa
> >>>                     node. In case more than one numa node binding,
> >>>                     create the lgrps according
> >>>                     to bound nodes.If there is no binding, then JVM will
> >>>                     divide the whole heap
> >>>                     based on the number of NUMA nodes available on the
> >>>                     system.
> >>>
> >>>                     I appreciate Gustavo's help for fixing the thread
> >>>                     allocation based on
> >>>                     numa distance for membind which was a dangling issue
> >>>                     associated with main
> >>>                     patch.
> >>>
> >>>
> >>>                 Thanks. I have no further comments on it. LGTM.
> >>>
> >>>
> >>>                 Best regards,
> >>>                 Gustavo
> >>>
> >>>                 PS: Please, provide numactl -H information when
> >>>                 possible. It helps to
> >>>                 grasp
> >>>                 promptly the actual NUMA topology in question :)
> >>>
> >>>                 Tested the fix by running specjbb2015 composite workload
> >>>                 on 8 NUMA node
> >>>
> >>>                     system.
> >>>                     Case 1 : Single NUMA node bind
> >>>                     numactl --cpunodebind=0 --membind=0 java -Xmx24g
> >>>                     -Xms24g -Xmn22g
> >>>                     -XX:+UseNUMA
> >>>                     -Xlog:gc*=debug:file=gc.log:time,uptimemillis
> >>>                     <composite_application>
> >>>                     Before Patch: gc.log
> >>>                     eden space 22511616K(22GB), 12% used
> >>>                            lgrp 0 space 2813952K, 100% used
> >>>                            lgrp 1 space 2813952K, 0% used
> >>>                            lgrp 2 space 2813952K, 0% used
> >>>                            lgrp 3 space 2813952K, 0% used
> >>>                            lgrp 4 space 2813952K, 0% used
> >>>                            lgrp 5 space 2813952K, 0% used
> >>>                            lgrp 6 space 2813952K, 0% used
> >>>                            lgrp 7 space 2813952K, 0% used
> >>>                     After Patch : gc.log
> >>>                     eden space 46718976K(45GB), 99% used(NUMA
> >>> disabled)
> >>>
> >>>                     Case 2 : Multiple NUMA node bind
> >>>                     numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g
> >>>                     -Xmx50g -Xmn45g
> >>>                     -XX:+UseNUMA
> >>>                     -Xlog:gc*=debug:file=gc.log:time,uptimemillis
> >>>                     <composite_application>
> >>>                     Before Patch :gc.log
> >>>                     eden space 46718976K, 6% used
> >>>                            lgrp 0 space 5838848K, 14% used
> >>>                            lgrp 1 space 5838848K, 0% used
> >>>                            lgrp 2 space 5838848K, 0% used
> >>>                            lgrp 3 space 5838848K, 0% used
> >>>                            lgrp 4 space 5838848K, 0% used
> >>>                            lgrp 5 space 5838848K, 0% used
> >>>                            lgrp 6 space 5838848K, 0% used
> >>>                            lgrp 7 space 5847040K, 35% used
> >>>                     After Patch : gc.log
> >>>                     eden space 46718976K(45GB), 99% used
> >>>                             lgrp 0 space 23359488K(23.5GB), 100% used
> >>>                             lgrp 7 space 23359488K(23.5GB), 99% used
> >>>
> >>>
> >>>                     Note: The proposed solution is only for numactl
> >>>                     membind option.The fix
> >>>                     is not for --cpunodebind and localalloc which is a
> >>>                     separate bug bug
> >>>                     https://bugs.openjdk.java.net/browse/JDK-8205051
> >>>                     <https://bugs.openjdk.java.net/browse/JDK-8205051>
> >>>                     and fix is in progress
> >>>                     on this.
> >>>
> >>>                     Thanks,
> >>>                     Swati Sharma
> >>>                     Software Engineer -2 at AMD
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >

From kim.barrett at oracle.com  Wed Jul 11 05:52:31 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Jul 2018 01:52:31 -0400
Subject: [8u] [RFR] Request for Review of Backport of JDK-8179887: Build
 failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)'
 is deprecated
In-Reply-To: <572ccd74-0a5c-571a-06ca-922ab16b8201@oracle.com>
References: <CABi63P5dzhVOzxmLehRDLigj5ZPbNSMvSLvMZyX1iSzyMqs+Cg@mail.gmail.com>
 <CABi63P6+B0+5gGgbcHuPv+M0+xztF7uDrKSOf3mgqGnPtcEe2g@mail.gmail.com>
 <CABi63P6x4jhwqguWu6bRMg0H1oT0JPavnPUPvfT2CNy_tgk39w@mail.gmail.com>
 <0cea696a-de84-bf33-c05b-145b4b18b84a@oracle.com>
 <CABi63P6+uZUaD8YBR8WwbfgpYNvRiEuXM11b2uZswkKfQDh7XA@mail.gmail.com>
 <b22bce18-3bca-15bb-b0da-c034db11b468@oracle.com>
 <CABi63P6jKZZ51G06x9GbPb+9GfrUmCH3xwRnhGnB0XkdieGWcQ@mail.gmail.com>
 <CAEgw74BwRtRER_d7_ymdaRGTsbgp90mYPkO3mfa0aDhXHVBUHQ@mail.gmail.com>
 <53b265f2-902f-8754-d50b-92693fd8ce27@oracle.com>
 <CABi63P4bMb7VgjosOBtTA-H8sV-PxzP+tsC4kcyArAZacixWwg@mail.gmail.com>
 <CAEgw74DLFrnSVsvZx=b7gMX7vK1yfKaG=pJAMj0BL6LK7u9MQA@mail.gmail.com>
 <572ccd74-0a5c-571a-06ca-922ab16b8201@oracle.com>
Message-ID: <7BDA14DB-1475-45D4-9DB1-4A54D28E288F@oracle.com>

> On Jul 9, 2018, at 10:21 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 10/07/2018 2:59 AM, B. Blaser wrote:
>> So, we can disable the warning for 8 but the process iterator will
>> still remain broken in 11 & 12.
>> What should we do?
> 
> The immediate issue in 8u is a build failure due to the warning. Fixing the warning, via compiler directives, addresses that. The other open bugs can deal with the problem of trying to switch to readdir.

I?ve sent out an RFR for a fix for 8202353 + 8202835, for jdk12.

The proposed fix for 8202835 is similar to B. Blaser?s proposal from here:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032445.html
but filled out to cover all relevant platforms, and with the no longer needed
argument for os::readdir removed.

We can decide how much of that to backport.  One option is to backport the fix for 8202835, (or
perhaps only the linux part), modified to use ::readdir directly, rather than using os::readdir
(which doesn't really add much in what is already platform-specific code).



From kim.barrett at oracle.com  Wed Jul 11 06:00:49 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Jul 2018 02:00:49 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
Message-ID: <24096447-7CB4-4960-B8CB-5CBE5B79D2F6@oracle.com>

> On Jul 10, 2018, at 4:18 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202353
> https://bugs.openjdk.java.net/browse/JDK-8202835
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
> 
> Testing:
> mach5 tier1-5.
> tier5 is where TestSystemProcess.java is run.
> There are a number of jfr tests in tier3-4 that use process iterators on
> relevant platforms.
> There are tests related to PerfCounters scattered through tier1-3.

Oops, most of the jfr tests, including the one being reinstated, seem to be in tier6
(specifically, hs-tier6-rt).  I?ve run them locally (linux), and have an in-progress mach5
job.   Unrelated failures for JDK-8205878, because the fix for that hasn?t made it from
the jdk11 repo to the jdk repo yet.


From bsrbnd at gmail.com  Wed Jul 11 11:43:55 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 11 Jul 2018 13:43:55 +0200
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <24096447-7CB4-4960-B8CB-5CBE5B79D2F6@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <24096447-7CB4-4960-B8CB-5CBE5B79D2F6@oracle.com>
Message-ID: <CAEgw74BtSW6iyKR4yMza-wXAww_Kg-bXJqVAC6Z9aoJNCzej=A@mail.gmail.com>

On 11 July 2018 at 08:00, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Jul 10, 2018, at 4:18 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8202353
>> https://bugs.openjdk.java.net/browse/JDK-8202835
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
>>
>> Testing:
>> mach5 tier1-5.
>> tier5 is where TestSystemProcess.java is run.
>> There are a number of jfr tests in tier3-4 that use process iterators on
>> relevant platforms.
>> There are tests related to PerfCounters scattered through tier1-3.
>
> Oops, most of the jfr tests, including the one being reinstated, seem to be in tier6
> (specifically, hs-tier6-rt).  I?ve run them locally (linux), and have an in-progress mach5
> job.   Unrelated failures for JDK-8205878, because the fix for that hasn?t made it from
> the jdk11 repo to the jdk repo yet.

Thanks Kim, Linux part looks good to me (if tier1-6 are OK).

Cheers,
Bernard

From shade at redhat.com  Wed Jul 11 13:31:55 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 11 Jul 2018 15:31:55 +0200
Subject: 8207006: serviceability/sa/TestUniverse.java#id0 crashes with
 EpsilonGC and AOT
Message-ID: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>

(This is cross-cutting compiler and GC, so posting at hotspot-dev@)

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8207006

All uses of ci_card_table_address() outside of CardTableBarrierSet itself check
is_a(BarrierSet::CardTableBarrierSet) before reaching for card table address. Epsilon does not have
a card table, so unguarded check would assert in fastdebug, and crash in release.

Trivial fix:
  http://cr.openjdk.java.net/~shade/8207006/webrev.01/

I would like to push this to jdk/jdk11 but I am puzzled to how do that. Do I need to seek another
approval for jdk/jdk11? Do I push to both jdk/jdk and jdk/jdk11? Or just to jdk/jdk11, and it gets
forward-ported automatically?

Testing: tier1_compiler (which seems to include AOT tests), HelloWorld AOT+Epsilon, jdk-submit (running)

Thanks,
-Aleksey


From shade at redhat.com  Wed Jul 11 13:32:36 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 11 Jul 2018 15:32:36 +0200
Subject: RFR (XS) 8207006: serviceability/sa/TestUniverse.java#id0 crashes
 with EpsilonGC and AOT
In-Reply-To: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>
References: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>
Message-ID: <6eabee02-4c4a-4a4f-915c-dfbaedacfdaf@redhat.com>

(Also missed "RFR" in subject, grr)

-Aleksey

On 07/11/2018 03:31 PM, Aleksey Shipilev wrote:
> (This is cross-cutting compiler and GC, so posting at hotspot-dev@)
> 
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8207006
> 
> All uses of ci_card_table_address() outside of CardTableBarrierSet itself check
> is_a(BarrierSet::CardTableBarrierSet) before reaching for card table address. Epsilon does not have
> a card table, so unguarded check would assert in fastdebug, and crash in release.
> 
> Trivial fix:
>   http://cr.openjdk.java.net/~shade/8207006/webrev.01/
> 
> I would like to push this to jdk/jdk11 but I am puzzled to how do that. Do I need to seek another
> approval for jdk/jdk11? Do I push to both jdk/jdk and jdk/jdk11? Or just to jdk/jdk11, and it gets
> forward-ported automatically?
> 
> Testing: tier1_compiler (which seems to include AOT tests), HelloWorld AOT+Epsilon, jdk-submit (running)
> 
> Thanks,
> -Aleksey
> 



From aph at redhat.com  Wed Jul 11 13:54:26 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Jul 2018 14:54:26 +0100
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to
 link to source code
In-Reply-To: <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
 <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
Message-ID: <bbabb38a-514d-e5c1-effa-7df0301ee470@redhat.com>

On 07/06/2018 10:33 PM, Ioi Lam wrote:
> I'll leave it to other CPU port maintainers.

OK, will do.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From boris.ulasevich at bell-sw.com  Wed Jul 11 15:42:26 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Wed, 11 Jul 2018 18:42:26 +0300
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instruction
In-Reply-To: <6f3111d3-b8e7-6784-54d1-7ab384d6bcb0@redhat.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
 <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>
 <b3d89836-26fc-fb99-a7cd-2e0a7e4d342e@bell-sw.com>
 <bcd327d0-4093-f3ba-c6be-ccbb1a9a7db8@bell-sw.com>
 <6f3111d3-b8e7-6784-54d1-7ab384d6bcb0@redhat.com>
Message-ID: <463da831-77e8-4204-0791-b97024cc2f2e@bell-sw.com>

Please review the following patch:
http://cr.openjdk.java.net/~bulasevich/8206895/webrev.02
https://bugs.openjdk.java.net/browse/JDK-8206895

cmp instruction overloading introduced to force user to specify 
immediate value type implicitly. The only allowed type is unsigned char. 
For immediate values outside of byte range subs macro should be called 
directly.

cmp calls all over the codes was fixed accordingly to the following plan:
   cmp(reg, imm8)  -> cmp(reg, (u1)imm8)
   cmp(reg, imm12) -> subs(zr, reg, imm12)
   cmp(reg, imm64) -> subs(scratch, reg, imm64)

The change was tested with jtreg tests.

thanks,
Boris

On 09.07.2018 18:54, Andrew Haley wrote:
> On 07/09/2018 04:33 PM, Boris Ulasevich wrote:
>> sorry. updated review link:
>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.01
>>
>> On 09.07.2018 18:32, Boris Ulasevich wrote:
>>> I am not sure how to mark instruction deprecated.
> 
> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-May/005840.html
> 
>   Why don't just remove
>>> it and update all the usage points? Here is the updated review:
>>>
>>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.01
>>>
>>> Boris
>>>
>>> On 09.07.2018 17:50, Andrew Haley wrote:
>>>> On 07/09/2018 03:31 PM, Boris Ulasevich wrote:
>>>>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.00
>>>>> https://bugs.openjdk.java.net/browse/JDK-8206895
>>>>>
>>>>> Byte form of cmp instruction was added. For bigger constants we are
>>>>> supposed to state _imm12 postfix implicitly or use cmp(reg,reg,imm)
>>>>> macro.
>>>>
>>>> I don't think that making cmp an alias for subs helps anyone:
>>>>
>>>> +? inline void cmp(Register Rd, Register Rn, unsigned imm32)? {
>>>> subs(Rd, Rn, imm32); }
>>>>
>>>> I think the best suggestion was to make the 8-bit cmp the only form
>>>> allowed, mark the larger cmp as deprecated, and force the user to use
>>>> subs.? That would be easier to read than cmp_imm12().
>>>>
> 
> 

From aph at redhat.com  Wed Jul 11 15:44:05 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Jul 2018 16:44:05 +0100
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to
 link to source code
In-Reply-To: <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
 <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
Message-ID: <26f937ba-df59-5cfb-f227-915c00d48d63@redhat.com>

On 07/06/2018 10:33 PM, Ioi Lam wrote:
> Since there's interest for this patch, I've finished it for the x86 port:
> 
> https://bugs.openjdk.java.net/browse/JDK-8204267
> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/

This is good.  It's so good that I wish I'd havd it years ago.
Approved.

I've also tried enabling it for the stub code, and it's equally good.
The change to the StubGenerator is very minor.

My rough changes to enable AArch64 are here:

http://cr.openjdk.java.net/~aph/8204267%2baarch64.patch

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From aph at redhat.com  Wed Jul 11 15:48:04 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Jul 2018 16:48:04 +0100
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instruction
In-Reply-To: <463da831-77e8-4204-0791-b97024cc2f2e@bell-sw.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
 <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>
 <b3d89836-26fc-fb99-a7cd-2e0a7e4d342e@bell-sw.com>
 <bcd327d0-4093-f3ba-c6be-ccbb1a9a7db8@bell-sw.com>
 <6f3111d3-b8e7-6784-54d1-7ab384d6bcb0@redhat.com>
 <463da831-77e8-4204-0791-b97024cc2f2e@bell-sw.com>
Message-ID: <01839833-398b-682a-954e-07f80b6c2129@redhat.com>

On 07/11/2018 04:42 PM, Boris Ulasevich wrote:
> Please review the following patch:
> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.02
> https://bugs.openjdk.java.net/browse/JDK-8206895
> 
> cmp instruction overloading introduced to force user to specify 
> immediate value type implicitly. The only allowed type is unsigned char. 

But how does this solve the problem?  Won't the C++ compiler silently
truncate cmp(reg, int) to a uint8 ?

> For immediate values outside of byte range subs macro should be called 
> directly.
> 
> cmp calls all over the codes was fixed accordingly to the following plan:
>    cmp(reg, imm8)  -> cmp(reg, (u1)imm8)
>    cmp(reg, imm12) -> subs(zr, reg, imm12)
>    cmp(reg, imm64) -> subs(scratch, reg, imm64)
> 
> The change was tested with jtreg tests.

This hunk looks wrong:

@@ -1129,7 +1129,7 @@

   if (super_check_offset.is_register()) {
     br(Assembler::EQ, *L_success);
-    cmp(super_check_offset.as_register(), sc_offset);
+    subs(zr, super_check_offset.as_register(), sc_offset);

cmp with register is still allowed.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From vladimir.kozlov at oracle.com  Wed Jul 11 16:02:17 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 11 Jul 2018 09:02:17 -0700
Subject: RFR (XS) 8207006: serviceability/sa/TestUniverse.java#id0 crashes
 with EpsilonGC and AOT
In-Reply-To: <6eabee02-4c4a-4a4f-915c-dfbaedacfdaf@redhat.com>
References: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>
 <6eabee02-4c4a-4a4f-915c-dfbaedacfdaf@redhat.com>
Message-ID: <37120768-f695-ded6-91f8-9005caaca339@oracle.com>

We really need to fix GC checking when loading AOT library instead of just checking for G1. I will file a bug.

Based on discussion in bug report changes looks good.

Aleksey, until July 26 you can push any P1-P3 bugs you think should be fixed into JDK 11:
http://openjdk.java.net/projects/jdk/11/

Just push into jdk/jdk11 after testing.

Thanks,
Vladimir

On 7/11/18 6:32 AM, Aleksey Shipilev wrote:
> (Also missed "RFR" in subject, grr)
> 
> -Aleksey
> 
> On 07/11/2018 03:31 PM, Aleksey Shipilev wrote:
>> (This is cross-cutting compiler and GC, so posting at hotspot-dev@)
>>
>> Bug:
>>    https://bugs.openjdk.java.net/browse/JDK-8207006
>>
>> All uses of ci_card_table_address() outside of CardTableBarrierSet itself check
>> is_a(BarrierSet::CardTableBarrierSet) before reaching for card table address. Epsilon does not have
>> a card table, so unguarded check would assert in fastdebug, and crash in release.
>>
>> Trivial fix:
>>    http://cr.openjdk.java.net/~shade/8207006/webrev.01/
>>
>> I would like to push this to jdk/jdk11 but I am puzzled to how do that. Do I need to seek another
>> approval for jdk/jdk11? Do I push to both jdk/jdk and jdk/jdk11? Or just to jdk/jdk11, and it gets
>> forward-ported automatically?
>>
>> Testing: tier1_compiler (which seems to include AOT tests), HelloWorld AOT+Epsilon, jdk-submit (running)
>>
>> Thanks,
>> -Aleksey
>>
> 
> 

From boris.ulasevich at bell-sw.com  Wed Jul 11 16:08:56 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Wed, 11 Jul 2018 19:08:56 +0300
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instruction
In-Reply-To: <01839833-398b-682a-954e-07f80b6c2129@redhat.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
 <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>
 <b3d89836-26fc-fb99-a7cd-2e0a7e4d342e@bell-sw.com>
 <bcd327d0-4093-f3ba-c6be-ccbb1a9a7db8@bell-sw.com>
 <6f3111d3-b8e7-6784-54d1-7ab384d6bcb0@redhat.com>
 <463da831-77e8-4204-0791-b97024cc2f2e@bell-sw.com>
 <01839833-398b-682a-954e-07f80b6c2129@redhat.com>
Message-ID: <d7898c37-8515-e8d6-b181-9f398c5e1250@bell-sw.com>


On 11.07.2018 18:48, Andrew Haley wrote:
> On 07/11/2018 04:42 PM, Boris Ulasevich wrote:
>> Please review the following patch:
>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.02
>> https://bugs.openjdk.java.net/browse/JDK-8206895
>>
>> cmp instruction overloading introduced to force user to specify
>> immediate value type implicitly. The only allowed type is unsigned char.
> 
> But how does this solve the problem?  Won't the C++ compiler silently
> truncate cmp(reg, int) to a uint8 ?

With overloaded cmp function compiler complains on any cmp(reg, imm) 
usage. The only way to use cmp is to implicitly specify parameter type. 
Once user specified unsigned char type (other types are not allowed), it 
is user responsibility to ensure the value is correct:

cmp(reg, 8);    // gcc: call of overloaded cmp is ambiguous
cmp(reg, 7722); // gcc: call of overloaded cmp is ambiguous
cmp(reg, (u1)8);    // ok
cmp(reg, (u1)7722); // user error

>> For immediate values outside of byte range subs macro should be called
>> directly.
>>
>> cmp calls all over the codes was fixed accordingly to the following plan:
>>     cmp(reg, imm8)  -> cmp(reg, (u1)imm8)
>>     cmp(reg, imm12) -> subs(zr, reg, imm12)
>>     cmp(reg, imm64) -> subs(scratch, reg, imm64)
>>
>> The change was tested with jtreg tests.
> 
> This hunk looks wrong:
> 
> @@ -1129,7 +1129,7 @@
> 
>     if (super_check_offset.is_register()) {
>       br(Assembler::EQ, *L_success);
> -    cmp(super_check_offset.as_register(), sc_offset);
> +    subs(zr, super_check_offset.as_register(), sc_offset);
> 
> cmp with register is still allowed.
  Yes, cmp(reg,reg) is Ok. But sc_offset is immediate value:
int sc_offset = in_bytes(Klass::secondary_super_cache_offset());

From kim.barrett at oracle.com  Wed Jul 11 16:09:34 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Jul 2018 12:09:34 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <CAEgw74BtSW6iyKR4yMza-wXAww_Kg-bXJqVAC6Z9aoJNCzej=A@mail.gmail.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <24096447-7CB4-4960-B8CB-5CBE5B79D2F6@oracle.com>
 <CAEgw74BtSW6iyKR4yMza-wXAww_Kg-bXJqVAC6Z9aoJNCzej=A@mail.gmail.com>
Message-ID: <D10A18A8-89D5-408F-A233-394195EFA65D@oracle.com>

> On Jul 11, 2018, at 7:43 AM, B. Blaser <bsrbnd at gmail.com> wrote:
> 
> On 11 July 2018 at 08:00, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> On Jul 10, 2018, at 4:18 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8202353
>>> https://bugs.openjdk.java.net/browse/JDK-8202835
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
>>> 
>>> Testing:
>>> mach5 tier1-5.
>>> tier5 is where TestSystemProcess.java is run.
>>> There are a number of jfr tests in tier3-4 that use process iterators on
>>> relevant platforms.
>>> There are tests related to PerfCounters scattered through tier1-3.
>> 
>> Oops, most of the jfr tests, including the one being reinstated, seem to be in tier6
>> (specifically, hs-tier6-rt).  I?ve run them locally (linux), and have an in-progress mach5
>> job.   Unrelated failures for JDK-8205878, because the fix for that hasn?t made it from
>> the jdk11 repo to the jdk repo yet.
> 
> Thanks Kim, Linux part looks good to me (if tier1-6 are OK).
> 
> Cheers,
> Bernard

Thanks.  No unexpected problems in testing.

I also received verification from the SAP folks that AIX changes build.
(Note that the AIX port doesn?t yet support jfr.)



From cthalinger at twitter.com  Wed Jul 11 16:10:03 2018
From: cthalinger at twitter.com (Christian Thalinger)
Date: Wed, 11 Jul 2018 12:10:03 -0400
Subject: RFR (XS) 8207006: serviceability/sa/TestUniverse.java#id0 crashes
 with EpsilonGC and AOT
In-Reply-To: <37120768-f695-ded6-91f8-9005caaca339@oracle.com>
References: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>
 <6eabee02-4c4a-4a4f-915c-dfbaedacfdaf@redhat.com>
 <37120768-f695-ded6-91f8-9005caaca339@oracle.com>
Message-ID: <AB96B1D3-137C-4538-B9A6-C8EA6570C8F6@twitter.com>



> On Jul 11, 2018, at 12:02 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> We really need to fix GC checking when loading AOT library instead of just checking for G1. I will file a bug.

Yes, that?s the only correct way.

> 
> Based on discussion in bug report changes looks good.
> 
> Aleksey, until July 26 you can push any P1-P3 bugs you think should be fixed into JDK 11:
> http://openjdk.java.net/projects/jdk/11/
> 
> Just push into jdk/jdk11 after testing.
> 
> Thanks,
> Vladimir
> 
> On 7/11/18 6:32 AM, Aleksey Shipilev wrote:
>> (Also missed "RFR" in subject, grr)
>> -Aleksey
>> On 07/11/2018 03:31 PM, Aleksey Shipilev wrote:
>>> (This is cross-cutting compiler and GC, so posting at hotspot-dev@)
>>> 
>>> Bug:
>>>   https://bugs.openjdk.java.net/browse/JDK-8207006
>>> 
>>> All uses of ci_card_table_address() outside of CardTableBarrierSet itself check
>>> is_a(BarrierSet::CardTableBarrierSet) before reaching for card table address. Epsilon does not have
>>> a card table, so unguarded check would assert in fastdebug, and crash in release.
>>> 
>>> Trivial fix:
>>>   http://cr.openjdk.java.net/~shade/8207006/webrev.01/
>>> 
>>> I would like to push this to jdk/jdk11 but I am puzzled to how do that. Do I need to seek another
>>> approval for jdk/jdk11? Do I push to both jdk/jdk and jdk/jdk11? Or just to jdk/jdk11, and it gets
>>> forward-ported automatically?
>>> 
>>> Testing: tier1_compiler (which seems to include AOT tests), HelloWorld AOT+Epsilon, jdk-submit (running)
>>> 
>>> Thanks,
>>> -Aleksey
>>> 


From aph at redhat.com  Wed Jul 11 16:22:31 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Jul 2018 17:22:31 +0100
Subject: [12] RFR 8206895: aarch64: rework error-prone cmp instruction
In-Reply-To: <d7898c37-8515-e8d6-b181-9f398c5e1250@bell-sw.com>
References: <d981ea1c-de83-4ce5-a20c-441d273e12cd@bell-sw.com>
 <5f3e5c09-abe9-391f-e803-ec2cdc35498d@redhat.com>
 <8bcd8b94-9cb2-7c99-2fbd-a675d91db9dc@bell-sw.com>
 <f339f16a-85cc-8afd-256e-d1896d3085b3@redhat.com>
 <b3d89836-26fc-fb99-a7cd-2e0a7e4d342e@bell-sw.com>
 <bcd327d0-4093-f3ba-c6be-ccbb1a9a7db8@bell-sw.com>
 <6f3111d3-b8e7-6784-54d1-7ab384d6bcb0@redhat.com>
 <463da831-77e8-4204-0791-b97024cc2f2e@bell-sw.com>
 <01839833-398b-682a-954e-07f80b6c2129@redhat.com>
 <d7898c37-8515-e8d6-b181-9f398c5e1250@bell-sw.com>
Message-ID: <733e86c0-535e-81a1-c2c0-3feaff15b9e9@redhat.com>

On 07/11/2018 05:08 PM, Boris Ulasevich wrote:
> 
> On 11.07.2018 18:48, Andrew Haley wrote:
>> On 07/11/2018 04:42 PM, Boris Ulasevich wrote:
>>> Please review the following patch:
>>> http://cr.openjdk.java.net/~bulasevich/8206895/webrev.02
>>> https://bugs.openjdk.java.net/browse/JDK-8206895
>>>
>>> cmp instruction overloading introduced to force user to specify
>>> immediate value type implicitly. The only allowed type is unsigned char.
>>
>> But how does this solve the problem?  Won't the C++ compiler silently
>> truncate cmp(reg, int) to a uint8 ?
> 
> With overloaded cmp function compiler complains on any cmp(reg, imm) 
> usage. The only way to use cmp is to implicitly specify parameter type. 
> Once user specified unsigned char type (other types are not allowed), it 
> is user responsibility to ensure the value is correct:
> 
> cmp(reg, 8);    // gcc: call of overloaded cmp is ambiguous
> cmp(reg, 7722); // gcc: call of overloaded cmp is ambiguous
> cmp(reg, (u1)8);    // ok
> cmp(reg, (u1)7722); // user error

That's fine, then.

>>> For immediate values outside of byte range subs macro should be called
>>> directly.
>>>
>>> cmp calls all over the codes was fixed accordingly to the following plan:
>>>     cmp(reg, imm8)  -> cmp(reg, (u1)imm8)
>>>     cmp(reg, imm12) -> subs(zr, reg, imm12)
>>>     cmp(reg, imm64) -> subs(scratch, reg, imm64)
>>>
>>> The change was tested with jtreg tests.
>>
>> This hunk looks wrong:
>>
>> @@ -1129,7 +1129,7 @@
>>
>>     if (super_check_offset.is_register()) {
>>       br(Assembler::EQ, *L_success);
>> -    cmp(super_check_offset.as_register(), sc_offset);
>> +    subs(zr, super_check_offset.as_register(), sc_offset);
>>
>> cmp with register is still allowed.
>   Yes, cmp(reg,reg) is Ok. But sc_offset is immediate value:
> int sc_offset = in_bytes(Klass::secondary_super_cache_offset());

OK, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From shade at redhat.com  Wed Jul 11 16:40:01 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 11 Jul 2018 18:40:01 +0200
Subject: RFR (XS) 8207006: serviceability/sa/TestUniverse.java#id0 crashes
 with EpsilonGC and AOT
In-Reply-To: <37120768-f695-ded6-91f8-9005caaca339@oracle.com>
References: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>
 <6eabee02-4c4a-4a4f-915c-dfbaedacfdaf@redhat.com>
 <37120768-f695-ded6-91f8-9005caaca339@oracle.com>
Message-ID: <bc7fd479-192c-ed01-6997-cf715881b4a3@redhat.com>

On 07/11/2018 06:02 PM, Vladimir Kozlov wrote:
> We really need to fix GC checking when loading AOT library instead of just checking for G1. I will
> file a bug.

Yes, please.

> Based on discussion in bug report changes looks good.
> 
> Aleksey, until July 26 you can push any P1-P3 bugs you think should be fixed into JDK 11:
> http://openjdk.java.net/projects/jdk/11/
> 
> Just push into jdk/jdk11 after testing.

Will push to jdk/jdk11 tomorrow. jdk/submit11 job is running just in case.

-Aleksey



From Prakash.Raghavendra at amd.com  Wed Jul 11 04:46:40 2018
From: Prakash.Raghavendra at amd.com (Raghavendra, Prakash)
Date: Wed, 11 Jul 2018 04:46:40 +0000
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <BL0PR07MB3890CD2AA56F084140125F75845B0@BL0PR07MB3890.namprd07.prod.outlook.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
 <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
 <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>
 <BL0PR07MB3890CD2AA56F084140125F75845B0@BL0PR07MB3890.namprd07.prod.outlook.com>
Message-ID: <DM5PR12MB1177DCF7A508FA7978B417A0F65A0@DM5PR12MB1177.namprd12.prod.outlook.com>

Hi All:

Apart from the impact on EPYC (with large memory), we have also have identified a few fixes on top of this, which is waiting for this to go. The one which is very essential is the case when GC is triggered prematurely when one of the lgrps is full, the fix is to see if we can try and allocate on another closest (in terms of latencies) lgrps, instead. 

Thanks
Regards
Prakash

-----Original Message-----
From: White, Derek [mailto:Derek.White at cavium.com] 
Sent: Wednesday, July 11, 2018 5:25 AM
To: David Holmes <david.holmes at oracle.com>; Gustavo Romero <gromero at linux.vnet.ibm.com>; Swati Sharma <swatibits14 at gmail.com>; Alan.Bateman at oracle.com
Cc: Vishwanath, Prasad <Prasad.Vishwanath at amd.com>; hotspot-dev at openjdk.java.net; Raghavendra, Prakash <Prakash.Raghavendra at amd.com>
Subject: RE: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs membind

Hi David,

[Gustavo and others, please correct me if I'm wrong].

I think as far as impact goes, this may waste up to (N-1)/N of the young generation in some cases, where N is number of nodes. For example, on 2-socket Epyc, this could waste 7/8ths of the young gen. This has non-trivial impact on GC behavior ??

This occurs when there's a mismatch between memory binding and JVM arguments (or rather can be avoided by carefully setting JVM arguments), and I could see this happening easily when using containers.

- Derek

> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On 
> Behalf Of David Holmes
> Sent: Tuesday, July 10, 2018 5:39 PM
> To: Gustavo Romero <gromero at linux.vnet.ibm.com>; Swati Sharma 
> <swatibits14 at gmail.com>; Alan.Bateman at oracle.com
> Cc: Prasad.Vishwanath at amd.com; hotspot-dev at openjdk.java.net; 
> Prakash.Raghavendra at amd.com
> Subject: Re: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory 
> interleaving vs membind
> 
> External Email
> 
> Hi Gustavo,
> 
> On 11/07/2018 6:14 AM, Gustavo Romero wrote:
> > Hi Swati,
> >
> > As David pointed out, it's necessary to determine if that bug 
> > qualifies as P3 in order to get it into JDK 11 RDP1.
> >
> > AFAICS, that bug was never triaged explicitly and got its current 
> > priority (P4) from the default.
> 
> Actually no, the P4 was from the (Oracle internal) ILW prioritization scheme.
> 
> For this to be a P3 it needs to be shown either that the impact is 
> quite significant (IIUC it's only a mild performance issue based on 
> the bug report); or that the likelihood of this being encountered is 
> very high (again it seems not that likely based on the info in the bug report).
> 
> HTH.
> 
> David
> -----
> 
> 
> >
> > Once it's defined the correct integration version, I can sponsor 
> > that change for you. I think there won't be any updates for JDK 11 
> > (contrary to what happened for JDK 10), but I think we can 
> > understand how distros are handling it and so find out if there is a 
> > possibility to get the change into the distros once it's pushed to JDK 12.
> >
> >
> > David, Alan,
> >
> > I could not find a documentation on how to formally triage a bug. 
> > For instance, on [1] I see Alan used some markers as "ILW =" and "MLH = "
> > but I don't know if these markers are only for Oracle internal 
> > control. Do you know how could I triage that bug? I understand its 
> > risk of integration is small but even tho I think it's necessary to 
> > bring up additional information on that to combine in a final bug 
> > priority.
> >
> > Thanks.
> >
> >
> > Best regards,
> > Gustavo
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8206953
> >
> > On 07/03/2018 03:06 AM, David Holmes wrote:
> >> Looks fine.
> >>
> >> Thanks,
> >> David
> >>
> >> On 3/07/2018 3:08 PM, Swati Sharma wrote:
> >>> Hi David,
> >>>
> >>> I have added NULL check for _numa_bitmask_isbitset in
> >>> isbound_to_single_node() method.
> >>>
> >>> Hosted:http://cr.openjdk.java.net/~gromero/8189922/v2/
> >>> <http://cr.openjdk.java.net/~gromero/8189922/v2/>
> >>>
> >>> Swati
> >>>
> >>> On Mon, Jul 2, 2018 at 5:54 AM, David Holmes 
> >>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
> >>>
> >>>     Hi Swati,
> >>>
> >>>     I took a look at this though I'm not familiar with the functional
> >>>     operation of the NUMA API's - I'm relying on Gustavo and Derek to
> >>>     spot any actual usage errors there.
> >>>
> >>>     In isbound_to_single_node() there is no NULL check for
> >>>     _numa_bitmask_isbitset (which seems to be the normal pattern for
> >>>     using all of these function pointers).
> >>>
> >>>     Otherwise this seems fine.
> >>>
> >>>     Thanks,
> >>>     David
> >>>
> >>>
> >>>     On 30/06/2018 2:46 AM, Swati Sharma wrote:
> >>>
> >>>            Hi,
> >>>
> >>>         Could I get a review for this change that affects the JVM when
> >>>         there are
> >>>         pinned memory nodes please?
> >>>
> >>>         It's already reviewed and tested on PPC64 and on AARCH64 by
> >>>         Gustavo and
> >>>         Derek, however both are not Reviewers so I need additional
> >>>         reviews for that
> >>>         change.
> >>>
> >>>
> >>>         Thanks in advance.
> >>>
> >>>         Swati
> >>>
> >>>         On Tue, Jun 19, 2018 at 5:58 PM, Swati Sharma
> >>>         <swatibits14 at gmail.com <mailto:swatibits14 at gmail.com>> wrote:
> >>>
> >>>             Hi All,
> >>>
> >>>             Here is the numa information of the system :
> >>>             swati at java-diesel1:~$ numactl -H
> >>>             available: 8 nodes (0-7)
> >>>             node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
> >>>             node 0 size: 64386 MB
> >>>             node 0 free: 64134 MB
> >>>             node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
> >>>             node 1 size: 64509 MB
> >>>             node 1 free: 64232 MB
> >>>             node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
> >>>             node 2 size: 64509 MB
> >>>             node 2 free: 64215 MB
> >>>             node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
> >>>             node 3 size: 64509 MB
> >>>             node 3 free: 64157 MB
> >>>             node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 
> >>> 101
> >>> 102 103
> >>>             node 4 size: 64509 MB
> >>>             node 4 free: 64336 MB
> >>>             node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109
> >>>             110 111
> >>>             node 5 size: 64509 MB
> >>>             node 5 free: 64352 MB
> >>>             node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117
> >>>             118 119
> >>>             node 6 size: 64509 MB
> >>>             node 6 free: 64359 MB
> >>>             node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125
> >>>             126 127
> >>>             node 7 size: 64508 MB
> >>>             node 7 free: 64350 MB
> >>>             node distances:
> >>>             node   0   1   2   3   4   5   6   7
> >>>                 0:  10  16  16  16  32  32  32  32
> >>>                 1:  16  10  16  16  32  32  32  32
> >>>                 2:  16  16  10  16  32  32  32  32
> >>>                 3:  16  16  16  10  32  32  32  32
> >>>                 4:  32  32  32  32  10  16  16  16
> >>>                 5:  32  32  32  32  16  10  16  16
> >>>                 6:  32  32  32  32  16  16  10  16
> >>>                 7:  32  32  32  32  16  16  16  10
> >>>
> >>>             Thanks,
> >>>             Swati
> >>>
> >>>             On Tue, Jun 19, 2018 at 12:00 AM, Gustavo Romero <
> >>>             gromero at linux.vnet.ibm.com
> >>>             <mailto:gromero at linux.vnet.ibm.com>> wrote:
> >>>
> >>>                 Hi Swati,
> >>>
> >>>                 On 06/16/2018 02:52 PM, Swati Sharma wrote:
> >>>
> >>>                     Hi All,
> >>>
> >>>                     This is my first patch,I would appreciate if anyone
> >>>                     can review the fix:
> >>>
> >>>                     Bug :
> >>>                     https://bugs.openjdk.java.net/browse/JDK-8189922
> >>>                     <https://bugs.openjdk.java.net/browse/JDK-8189922> <
> >>>                     https://bugs.openjdk.java.net/browse/JDK-8189922
> >>>                     <https://bugs.openjdk.java.net/browse/JDK-8189922>>
> >>>                     Webrev
> >>>                     :http://cr.openjdk.java.net/~gromero/8189922/v1
> >>>                     
> >>> <http://cr.openjdk.java.net/~gromero/8189922/v1>
> >>>
> >>>                     The bug is about JVM flag UseNUMA which bypasses the
> >>>                     user specified
> >>>                     numactl --membind option and divides the whole heap
> >>>                     in lgrps according to
> >>>                     available numa nodes.
> >>>
> >>>                     The proposed solution is to disable UseNUMA if bound
> >>>                     to single numa
> >>>                     node. In case more than one numa node binding,
> >>>                     create the lgrps according
> >>>                     to bound nodes.If there is no binding, then JVM will
> >>>                     divide the whole heap
> >>>                     based on the number of NUMA nodes available on the
> >>>                     system.
> >>>
> >>>                     I appreciate Gustavo's help for fixing the thread
> >>>                     allocation based on
> >>>                     numa distance for membind which was a dangling issue
> >>>                     associated with main
> >>>                     patch.
> >>>
> >>>
> >>>                 Thanks. I have no further comments on it. LGTM.
> >>>
> >>>
> >>>                 Best regards,
> >>>                 Gustavo
> >>>
> >>>                 PS: Please, provide numactl -H information when
> >>>                 possible. It helps to
> >>>                 grasp
> >>>                 promptly the actual NUMA topology in question :)
> >>>
> >>>                 Tested the fix by running specjbb2015 composite workload
> >>>                 on 8 NUMA node
> >>>
> >>>                     system.
> >>>                     Case 1 : Single NUMA node bind
> >>>                     numactl --cpunodebind=0 --membind=0 java -Xmx24g
> >>>                     -Xms24g -Xmn22g
> >>>                     -XX:+UseNUMA
> >>>                     -Xlog:gc*=debug:file=gc.log:time,uptimemillis
> >>>                     <composite_application>
> >>>                     Before Patch: gc.log
> >>>                     eden space 22511616K(22GB), 12% used
> >>>                            lgrp 0 space 2813952K, 100% used
> >>>                            lgrp 1 space 2813952K, 0% used
> >>>                            lgrp 2 space 2813952K, 0% used
> >>>                            lgrp 3 space 2813952K, 0% used
> >>>                            lgrp 4 space 2813952K, 0% used
> >>>                            lgrp 5 space 2813952K, 0% used
> >>>                            lgrp 6 space 2813952K, 0% used
> >>>                            lgrp 7 space 2813952K, 0% used
> >>>                     After Patch : gc.log
> >>>                     eden space 46718976K(45GB), 99% used(NUMA
> >>> disabled)
> >>>
> >>>                     Case 2 : Multiple NUMA node bind
> >>>                     numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g
> >>>                     -Xmx50g -Xmn45g
> >>>                     -XX:+UseNUMA
> >>>                     -Xlog:gc*=debug:file=gc.log:time,uptimemillis
> >>>                     <composite_application>
> >>>                     Before Patch :gc.log
> >>>                     eden space 46718976K, 6% used
> >>>                            lgrp 0 space 5838848K, 14% used
> >>>                            lgrp 1 space 5838848K, 0% used
> >>>                            lgrp 2 space 5838848K, 0% used
> >>>                            lgrp 3 space 5838848K, 0% used
> >>>                            lgrp 4 space 5838848K, 0% used
> >>>                            lgrp 5 space 5838848K, 0% used
> >>>                            lgrp 6 space 5838848K, 0% used
> >>>                            lgrp 7 space 5847040K, 35% used
> >>>                     After Patch : gc.log
> >>>                     eden space 46718976K(45GB), 99% used
> >>>                             lgrp 0 space 23359488K(23.5GB), 100% used
> >>>                             lgrp 7 space 23359488K(23.5GB), 99% 
> >>> used
> >>>
> >>>
> >>>                     Note: The proposed solution is only for numactl
> >>>                     membind option.The fix
> >>>                     is not for --cpunodebind and localalloc which is a
> >>>                     separate bug bug
> >>>                     https://bugs.openjdk.java.net/browse/JDK-8205051
> >>>                     <https://bugs.openjdk.java.net/browse/JDK-8205051>
> >>>                     and fix is in progress
> >>>                     on this.
> >>>
> >>>                     Thanks,
> >>>                     Swati Sharma
> >>>                     Software Engineer -2 at AMD
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >

From coleen.phillimore at oracle.com  Wed Jul 11 17:44:05 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 11 Jul 2018 13:44:05 -0400
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to
 link to source code
In-Reply-To: <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
 <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
Message-ID: <995aa43b-6789-58bf-429d-4653f6f19768@oracle.com>


http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/src/hotspot/share/compiler/disassembler.cpp.udiff.html

+ Link *link = new (ResourceObj::C_HEAP, mtInternal) Link(file, line);


Can you use mtCode here?? Why not make Link inherit from 
CHeapObj<mtCode> then just say new?

+ if (_cached_src_lines != NULL) {
+ for (int i=0; i<_cached_src_lines->length(); i++) {
+ os::free((void*)_cached_src_lines->at(i));
+ }
+ _cached_src_lines->clear();
+ } else {
+ _cached_src_lines = new (ResourceObj::C_HEAP, 
mtInternal)GrowableArray<const char*>(0, true);
+ }


Growable Array has a delete operator that will clear_and_deallocate all 
the elements and the array itself (which I don't think this does).?? But 
it looks like you're reusing _cached_src_lines for later iterations.? 
It's an odd usage.? But you can't resource allocate this?

302 if (_cached_src == NULL || strcmp(_cached_src, file) != 0) {


The indentation is wrong, and this would be a nice place for a comment 
at line 301.

http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/src/hotspot/share/compiler/disassembler.hpp.udiff.html

I wonder if checking PrintInterpreter for each macro assembler line will 
slow down generating the interpreter for the normal case. Maybe there is 
an EnableIf<PrintInterpreter> sort of template trick to make it evaporate?

PrintInterpreter is an option in product mode.

http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt

   0x00007f72c498d527: callq  0x00007f72c498d531             ;;  126:   __ call_VM(noreg,


Should this say what it's calling?

   0x00007f72c498d572: callq  0x00007f72e3df9ea0 = InterpreterRuntime::slow_signature_handler(JavaThread*, Method*, long*, long*)


But this says what it's calling but I don't think this is part of your 
change (or is it?)

That's all the comments I have. I wish you did this many years ago also!
Thanks,
Coleen

On 7/6/18 5:33 PM, Ioi Lam wrote:
> Hi,
>
>
> Since there's interest for this patch, I've finished it for the x86 port:
>
> https://bugs.openjdk.java.net/browse/JDK-8204267
> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/ 
>
>
> You can see a sample at
>
> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt 
>
>
> Incorporating this to other CPU ports should be pretty straight 
> forward. You just
> need to do something like:
>
> -#define __ _masm->
> +#define __ Disassembler::hook<MacroAssembler>(__FILE__, __LINE__, 
> _masm)->
>
> I'll leave it to other CPU port maintainers.
>
> I am testing with hs_tier{1,2}.
>
> Thanks
>
> - Ioi
>
>
> On 6/4/18 12:12 AM, Ioi Lam wrote:
>> Hi Folks,
>>
>> I've found it very hard to understand the assembler code printed by 
>> -XX:+PrintInterpreter. Since the C++ source code that generates the 
>> interpreter is fairly well documented, it might be a good idea to 
>> print out the source code along with the assembler code.
>>
>> I've done a quick proof-of-concept by hacking the "__" macro that's 
>> used throughout the CPU-dependent sources.
>>
>> Please let me know if you think this is worth doing. If so, I will 
>> try to finish it up and post a real RFR.
>>
>> Thanks
>> - Ioi
>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8204267
>> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00 
>>
>> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00/hs_interp.S 
>>
>>
>> Here are some examples (if the mailer screws up the long lines, 
>> please click the above link):
>>
>> ifeq? 153 ifeq? [0x00007f830cc93da0, 0x00007f830cc941c0] 1056 bytes
>>
>> mov??? (%rsp),%eax
>> add??? $0x8,%rsp
>> test?? %eax,%eax?????????? ;; 2353:?? __ testl(rax, rax);
>> jne??? 0x00007f830cc94177? ;; 2354:?? __ jcc(j_not(cc), not_taken);
>> mov??? -0x18(%rbp),%rcx??? ;; 2120:?? __ get_method(rcx); // rcx 
>> holds method
>> mov??? -0x28(%rbp),%rax??? ;; 2121:?? __ profile_taken_branch(rax, 
>> rbx); // rax holds updated MDP, rbx
>> test?? %rax,%rax
>> je???? 0x00007f830cc93dd8
>> mov??? 0x8(%rax),%rbx
>> add??? $0x1,%rbx
>> sbb??? $0x0,%rbx
>> mov??? %rbx,0x8(%rax)
>> add??? 0x10(%rax),%rax
>> mov??? %rax,-0x28(%rbp)
>> movswl 0x1(%r13),%edx????? ;; 2133:???? __ load_signed_short(rdx, 
>> at_bcp(1));
>> bswap? %edx??????????????? ;; 2135:?? __ bswapl(rdx);
>> sar??? $0x10,%edx????????? ;; 2138:???? __ sarl(rdx, 16);
>> movslq %edx,%rdx?????????? ;; 2140:?? LP64_ONLY(__ movl2ptr(rdx, rdx));
>> add??? %rdx,%r13?????????? ;; 2164:?? __ addptr(rbcp, rdx);
>> test?? %edx,%edx?????????? ;; 2179:???? __ testl(rdx, 
>> rdx);???????????? // check if forward or backward branch
>> jns??? 0x00007f830cc93eec? ;; 2180:???? __ jcc(Assembler::positive, 
>> dispatch); // count only if backward branch
>> mov??? 0x18(%rcx),%rax???? ;; 2184:???? __ movptr(rax, Address(rcx, 
>> Method::method_counters_offset()));
>> test?? %rax,%rax?????????? ;; 2185:???? __ testptr(rax, rax);
>> jne??? 0x00007f830cc93ead? ;; 2186:???? __ jcc(Assembler::notZero, 
>> has_counters);
>> push?? %rdx??????????????? ;; 2187:???? __ push(rdx);
>> push?? %rcx??????????????? ;; 2188:???? __ push(rcx);
>> callq? 0x00007f830cc93e09? ;; 2189:???? __ call_VM(noreg, 
>> CAST_FROM_FN_PTR(address, InterpreterRuntime::build_method_counters),
>>
>


From coleen.phillimore at oracle.com  Wed Jul 11 18:31:52 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 11 Jul 2018 14:31:52 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
Message-ID: <172e2fb9-3c25-b89c-1598-49eb85a4ff0e@oracle.com>


This looks very nice but one question:

http://cr.openjdk.java.net/~kbarrett/8202353/open.00/src/hotspot/os/linux/os_linux.cpp.udiff.html

+ while (result && (ptr = readdir(dir)) != NULL) {


What deallocates the dirent* memory?

thanks,
Coleen

On 7/10/18 4:18 PM, Kim Barrett wrote:
> Please review this change to the various os::readdir implementations
> for POSIX platforms to no longer use readdir_r, but instead use
> readdir.  readdir_r has been deprecated by glibc and at least some BSD
> variants, and seems to have been a mistake from the get-go.  See the
> readdir_r Portability Note in recent versions of the glibc
> documentation, e.g.
> https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html.
>
> Because we're no longer using readdir_r, the second argument for
> os::readdir is now unused by any platform's implementation.  So we've
> removed that argument, as well as the associated helper function
> os::readdir_buf_size().  All callers have been updated to no longer
> allocate and pass along the buffer for the second argument.
>
> As part of this, merged all the (now identical) non-Windows
> implementations of os::opendir, os::readdir, and os::closedir into
> os_posix.cpp.  This means the os wrappers are no longer inlined, but
> these aren't performance critical.
>
> This also eliminated some "approximations" of the proper size for the
> dirent argument that weren't correct (c.f. the deprecation rationale).
> These places should have been using readdir_buf_size(), which would
> have forced some of them to use C heap instead of stack allocation.
>
> Eliminating the 2nd argument for os::readdir required fixing some uses
> in jfr.  Some implementations of
> SystemProcessInterface::SystemProcesses::ProcessIterator assumed the
> second argument would always contain the same information as the
> result, when the result is non-NULL.  But that was not part of the
> os::readdir contract, and was never true for the Windows port (though
> the Windows port uses a different mechanism for getting process info).
> With JDK-8179887 it is no longer true for the Linux port either, which
> broke some things in jfr; see JDK-8202835.  That bug is being fixed as
> part of changing jfr for the new os::readdir signature, and the
> relevant test is being reinstated.
>
> Also updated various unqualified calls to opendir/closedir that were
> actually calling the dirent.h functions directly to instead use the os
> wrappers, for consistency.
>
> Note that this is undoing the readdir-related parts of JDK-4647546.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202353
> https://bugs.openjdk.java.net/browse/JDK-8202835
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
>
> Testing:
> mach5 tier1-5.
> tier5 is where TestSystemProcess.java is run.
> There are a number of jfr tests in tier3-4 that use process iterators on
> relevant platforms.
> There are tests related to PerfCounters scattered through tier1-3.
>


From kim.barrett at oracle.com  Wed Jul 11 19:06:56 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Jul 2018 15:06:56 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <172e2fb9-3c25-b89c-1598-49eb85a4ff0e@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <172e2fb9-3c25-b89c-1598-49eb85a4ff0e@oracle.com>
Message-ID: <6DD2A01C-B90E-45C4-BADF-1290BBEB02E6@oracle.com>

> On Jul 11, 2018, at 2:31 PM, coleen.phillimore at oracle.com wrote:
> 
> 
> This looks very nice but one question:
> 
> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/src/hotspot/os/linux/os_linux.cpp.udiff.html
> 
> + while (result && (ptr = readdir(dir)) != NULL) {
> 
> 
> What deallocates the dirent* memory?

That memory belongs to the DIR* dir, and is reclaimed by the closdir(dir) at the end of the function.


From ioi.lam at oracle.com  Wed Jul 11 21:03:22 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 11 Jul 2018 14:03:22 -0700
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to
 link to source code
In-Reply-To: <26f937ba-df59-5cfb-f227-915c00d48d63@redhat.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
 <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
 <26f937ba-df59-5cfb-f227-915c00d48d63@redhat.com>
Message-ID: <82a98f5a-4962-47d8-fb88-3b609d50f2a1@oracle.com>

Thanks Andrew for the review. For the aarch64 code, maybe you can push 
it as a separate bug ID, so you can do more testing first?

Thanks

- Ioi


On 7/11/18 8:44 AM, Andrew Haley wrote:
> On 07/06/2018 10:33 PM, Ioi Lam wrote:
>> Since there's interest for this patch, I've finished it for the x86 port:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8204267
>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/
> This is good.  It's so good that I wish I'd havd it years ago.
> Approved.
>
> I've also tried enabling it for the stub code, and it's equally good.
> The change to the StubGenerator is very minor.
>
> My rough changes to enable AArch64 are here:
>
> http://cr.openjdk.java.net/~aph/8204267%2baarch64.patch
>


From ioi.lam at oracle.com  Wed Jul 11 22:46:58 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 11 Jul 2018 15:46:58 -0700
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to
 link to source code
In-Reply-To: <995aa43b-6789-58bf-429d-4653f6f19768@oracle.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
 <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
 <995aa43b-6789-58bf-429d-4653f6f19768@oracle.com>
Message-ID: <5fd4286d-91d3-e728-aaaa-021fc2c350c0@oracle.com>

Hi Coleen,


Thanks for the review. I have updated the patch according to your 
comments. Here's the diff from the last webrev:

http://ioilinux.us.oracle.com/webrev/jdk12.open/8204267-print-interpreter-comments.v002.delta/


On 7/11/18 10:44 AM, coleen.phillimore at oracle.com wrote:
>
> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/src/hotspot/share/compiler/disassembler.cpp.udiff.html 
>
>
> + Link *link = new (ResourceObj::C_HEAP, mtInternal) Link(file, line);
>
>
> Can you use mtCode here?? Why not make Link inherit from 
> CHeapObj<mtCode> then just say new?
>
Fixed.

> + if (_cached_src_lines != NULL) {
> + for (int i=0; i<_cached_src_lines->length(); i++) {
> + os::free((void*)_cached_src_lines->at(i));
> + }
> + _cached_src_lines->clear();
> + } else {
> + _cached_src_lines = new (ResourceObj::C_HEAP, 
> mtInternal)GrowableArray<const char*>(0, true);
> + }
>
>
> Growable Array has a delete operator that will clear_and_deallocate 
> all the elements and the array itself (which I don't think this does).

We have this function:

template<class E> void GrowableArray<E>::clear_and_deallocate() {
 ??? assert(on_C_heap(),
 ?????????? "clear_and_deallocate should only be called when on C heap");
 ??? clear();
 ??? if (_data != NULL) {
 ????? for (int i = 0; i < _max; i++) _data[i].~E();
 ????? free_C_heap(_data);
 ????? _data = NULL;
 ??? }
}

My <E> type is currently <const char*>. To take advantage of 
clear_and_deallocate I have to wrap the const char* into something like this

struct {
 ?? const char* _line;
 ?? LineInfo(const char* l) : _line(l) {}
 ?? ~LineInfo() {os::free(_line);}
} LineInfo;

but this adds a tone of boiler plate code and still won't work, because 
GrowableArray<E>::grow will call ~E(), which messes things up.

So I'll just keep the existing code and won't bother.

> ? But it looks like you're reusing _cached_src_lines for later 
> iterations.? It's an odd usage.? But you can't resource allocate this?
>

I am worried that we may have be under nested ResourceMarks, and the 
allocated _cached_src_lines may be freed unexpectedly.

> 302 if (_cached_src == NULL || strcmp(_cached_src, file) != 0) {
>
>
> The indentation is wrong, and this would be a nice place for a comment 
> at line 301.
>
I fixed indent and added this comment

 ??????? // _cached_src_lines is a single cache of the lines of a source 
file, and we refill this cache
 ??????? // every time we need to print a line from a different source 
file. It's not the fastest,
 ??????? // but seems bearable.


> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/src/hotspot/share/compiler/disassembler.hpp.udiff.html 
>
>
> I wonder if checking PrintInterpreter for each macro assembler line 
> will slow down generating the interpreter for the normal case. Maybe 
> there is an EnableIf<PrintInterpreter> sort of template trick to make 
> it evaporate?
>
> PrintInterpreter is an option in product mode.
>
I am hoping that __ is slow enough, so doing an extra load-and-test 
won't slow down it too much. I benchmarked "java -Xint -version" and the 
slow down is 0.11% after 1000 runs, so I guess it's acceptable.

If people start complaining, we can do this later ....

 ? template<class T> inline static T* hook(const char* file, int line, 
T* masm) {
#ifdef ASSERT
 ??? if (PrintInterpreter) {
 ????? _hook(file, line, masm);
 ??? }
#endif
 ??? return masm;
 ? }

> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt 
>
>
> ? 0x00007f72c498d527: callq? 0x00007f72c498d531???????????? ;; 126:?? 
> __ call_VM(noreg,
>
>
> Should this say what it's calling?
>
> ? 0x00007f72c498d572: callq? 0x00007f72e3df9ea0 = 
> InterpreterRuntime::slow_signature_handler(JavaThread*, Method*, 
> long*, long*)
>
>
> But this says what it's calling but I don't think this is part of your 
> change (or is it?)
>
Yes. When you see a call_VM, you have to scan down and see what it's 
actually calling. It's no ideal, but I don't know how to improve it 
without writing a lot of code ... which I want to avoid.

Thanks
- Ioi

> That's all the comments I have. I wish you did this many years ago also!
> Thanks,
> Coleen
>
> On 7/6/18 5:33 PM, Ioi Lam wrote:
>> Hi,
>>
>>
>> Since there's interest for this patch, I've finished it for the x86 
>> port:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8204267
>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/ 
>>
>>
>> You can see a sample at
>>
>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt 
>>
>>
>> Incorporating this to other CPU ports should be pretty straight 
>> forward. You just
>> need to do something like:
>>
>> -#define __ _masm->
>> +#define __ Disassembler::hook<MacroAssembler>(__FILE__, __LINE__, 
>> _masm)->
>>
>> I'll leave it to other CPU port maintainers.
>>
>> I am testing with hs_tier{1,2}.
>>
>> Thanks
>>
>> - Ioi
>>
>>
>> On 6/4/18 12:12 AM, Ioi Lam wrote:
>>> Hi Folks,
>>>
>>> I've found it very hard to understand the assembler code printed by 
>>> -XX:+PrintInterpreter. Since the C++ source code that generates the 
>>> interpreter is fairly well documented, it might be a good idea to 
>>> print out the source code along with the assembler code.
>>>
>>> I've done a quick proof-of-concept by hacking the "__" macro that's 
>>> used throughout the CPU-dependent sources.
>>>
>>> Please let me know if you think this is worth doing. If so, I will 
>>> try to finish it up and post a real RFR.
>>>
>>> Thanks
>>> - Ioi
>>>
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8204267
>>> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00 
>>>
>>> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00/hs_interp.S 
>>>
>>>
>>> Here are some examples (if the mailer screws up the long lines, 
>>> please click the above link):
>>>
>>> ifeq? 153 ifeq? [0x00007f830cc93da0, 0x00007f830cc941c0] 1056 bytes
>>>
>>> mov??? (%rsp),%eax
>>> add??? $0x8,%rsp
>>> test?? %eax,%eax?????????? ;; 2353:?? __ testl(rax, rax);
>>> jne??? 0x00007f830cc94177? ;; 2354:?? __ jcc(j_not(cc), not_taken);
>>> mov??? -0x18(%rbp),%rcx??? ;; 2120:?? __ get_method(rcx); // rcx 
>>> holds method
>>> mov??? -0x28(%rbp),%rax??? ;; 2121:?? __ profile_taken_branch(rax, 
>>> rbx); // rax holds updated MDP, rbx
>>> test?? %rax,%rax
>>> je???? 0x00007f830cc93dd8
>>> mov??? 0x8(%rax),%rbx
>>> add??? $0x1,%rbx
>>> sbb??? $0x0,%rbx
>>> mov??? %rbx,0x8(%rax)
>>> add??? 0x10(%rax),%rax
>>> mov??? %rax,-0x28(%rbp)
>>> movswl 0x1(%r13),%edx????? ;; 2133:???? __ load_signed_short(rdx, 
>>> at_bcp(1));
>>> bswap? %edx??????????????? ;; 2135:?? __ bswapl(rdx);
>>> sar??? $0x10,%edx????????? ;; 2138:???? __ sarl(rdx, 16);
>>> movslq %edx,%rdx?????????? ;; 2140:?? LP64_ONLY(__ movl2ptr(rdx, rdx));
>>> add??? %rdx,%r13?????????? ;; 2164:?? __ addptr(rbcp, rdx);
>>> test?? %edx,%edx?????????? ;; 2179:???? __ testl(rdx, 
>>> rdx);???????????? // check if forward or backward branch
>>> jns??? 0x00007f830cc93eec? ;; 2180:???? __ jcc(Assembler::positive, 
>>> dispatch); // count only if backward branch
>>> mov??? 0x18(%rcx),%rax???? ;; 2184:???? __ movptr(rax, Address(rcx, 
>>> Method::method_counters_offset()));
>>> test?? %rax,%rax?????????? ;; 2185:???? __ testptr(rax, rax);
>>> jne??? 0x00007f830cc93ead? ;; 2186:???? __ jcc(Assembler::notZero, 
>>> has_counters);
>>> push?? %rdx??????????????? ;; 2187:???? __ push(rdx);
>>> push?? %rcx??????????????? ;; 2188:???? __ push(rcx);
>>> callq? 0x00007f830cc93e09? ;; 2189:???? __ call_VM(noreg, 
>>> CAST_FROM_FN_PTR(address, InterpreterRuntime::build_method_counters),
>>>
>>
>


From ioi.lam at oracle.com  Wed Jul 11 22:48:10 2018
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 11 Jul 2018 15:48:10 -0700
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to
 link to source code
In-Reply-To: <5fd4286d-91d3-e728-aaaa-021fc2c350c0@oracle.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
 <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
 <995aa43b-6789-58bf-429d-4653f6f19768@oracle.com>
 <5fd4286d-91d3-e728-aaaa-021fc2c350c0@oracle.com>
Message-ID: <d3cade53-0d15-1089-7f30-0b05ebbdb6bb@oracle.com>



On 7/11/18 3:46 PM, Ioi Lam wrote:
> Hi Coleen,
>
>
> Thanks for the review. I have updated the patch according to your 
> comments. Here's the diff from the last webrev:
>
>

Sorry the correct URL is

http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v002.delta/

>
> On 7/11/18 10:44 AM, coleen.phillimore at oracle.com wrote:
>>
>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/src/hotspot/share/compiler/disassembler.cpp.udiff.html 
>>
>>
>> + Link *link = new (ResourceObj::C_HEAP, mtInternal) Link(file, line);
>>
>>
>> Can you use mtCode here?? Why not make Link inherit from 
>> CHeapObj<mtCode> then just say new?
>>
> Fixed.
>
>> + if (_cached_src_lines != NULL) {
>> + for (int i=0; i<_cached_src_lines->length(); i++) {
>> + os::free((void*)_cached_src_lines->at(i));
>> + }
>> + _cached_src_lines->clear();
>> + } else {
>> + _cached_src_lines = new (ResourceObj::C_HEAP, 
>> mtInternal)GrowableArray<const char*>(0, true);
>> + }
>>
>>
>> Growable Array has a delete operator that will clear_and_deallocate 
>> all the elements and the array itself (which I don't think this does).
>
> We have this function:
>
> template<class E> void GrowableArray<E>::clear_and_deallocate() {
> ??? assert(on_C_heap(),
> ?????????? "clear_and_deallocate should only be called when on C heap");
> ??? clear();
> ??? if (_data != NULL) {
> ????? for (int i = 0; i < _max; i++) _data[i].~E();
> ????? free_C_heap(_data);
> ????? _data = NULL;
> ??? }
> }
>
> My <E> type is currently <const char*>. To take advantage of 
> clear_and_deallocate I have to wrap the const char* into something 
> like this
>
> struct {
> ?? const char* _line;
> ?? LineInfo(const char* l) : _line(l) {}
> ?? ~LineInfo() {os::free(_line);}
> } LineInfo;
>
> but this adds a tone of boiler plate code and still won't work, 
> because GrowableArray<E>::grow will call ~E(), which messes things up.
>
> So I'll just keep the existing code and won't bother.
>
>> ? But it looks like you're reusing _cached_src_lines for later 
>> iterations.? It's an odd usage.? But you can't resource allocate this?
>>
>
> I am worried that we may have be under nested ResourceMarks, and the 
> allocated _cached_src_lines may be freed unexpectedly.
>
>> 302 if (_cached_src == NULL || strcmp(_cached_src, file) != 0) {
>>
>>
>> The indentation is wrong, and this would be a nice place for a 
>> comment at line 301.
>>
> I fixed indent and added this comment
>
> ??????? // _cached_src_lines is a single cache of the lines of a 
> source file, and we refill this cache
> ??????? // every time we need to print a line from a different source 
> file. It's not the fastest,
> ??????? // but seems bearable.
>
>
>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/src/hotspot/share/compiler/disassembler.hpp.udiff.html 
>>
>>
>> I wonder if checking PrintInterpreter for each macro assembler line 
>> will slow down generating the interpreter for the normal case. Maybe 
>> there is an EnableIf<PrintInterpreter> sort of template trick to make 
>> it evaporate?
>>
>> PrintInterpreter is an option in product mode.
>>
> I am hoping that __ is slow enough, so doing an extra load-and-test 
> won't slow down it too much. I benchmarked "java -Xint -version" and 
> the slow down is 0.11% after 1000 runs, so I guess it's acceptable.
>
> If people start complaining, we can do this later ....
>
> ? template<class T> inline static T* hook(const char* file, int line, 
> T* masm) {
> #ifdef ASSERT
> ??? if (PrintInterpreter) {
> ????? _hook(file, line, masm);
> ??? }
> #endif
> ??? return masm;
> ? }
>
>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt 
>>
>>
>> ? 0x00007f72c498d527: callq? 0x00007f72c498d531???????????? ;; 126:?? 
>> __ call_VM(noreg,
>>
>>
>> Should this say what it's calling?
>>
>> ? 0x00007f72c498d572: callq? 0x00007f72e3df9ea0 = 
>> InterpreterRuntime::slow_signature_handler(JavaThread*, Method*, 
>> long*, long*)
>>
>>
>> But this says what it's calling but I don't think this is part of 
>> your change (or is it?)
>>
> Yes. When you see a call_VM, you have to scan down and see what it's 
> actually calling. It's no ideal, but I don't know how to improve it 
> without writing a lot of code ... which I want to avoid.
>
> Thanks
> - Ioi
>
>> That's all the comments I have. I wish you did this many years ago also!
>> Thanks,
>> Coleen
>>
>> On 7/6/18 5:33 PM, Ioi Lam wrote:
>>> Hi,
>>>
>>>
>>> Since there's interest for this patch, I've finished it for the x86 
>>> port:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8204267
>>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/ 
>>>
>>>
>>> You can see a sample at
>>>
>>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt 
>>>
>>>
>>> Incorporating this to other CPU ports should be pretty straight 
>>> forward. You just
>>> need to do something like:
>>>
>>> -#define __ _masm->
>>> +#define __ Disassembler::hook<MacroAssembler>(__FILE__, __LINE__, 
>>> _masm)->
>>>
>>> I'll leave it to other CPU port maintainers.
>>>
>>> I am testing with hs_tier{1,2}.
>>>
>>> Thanks
>>>
>>> - Ioi
>>>
>>>
>>> On 6/4/18 12:12 AM, Ioi Lam wrote:
>>>> Hi Folks,
>>>>
>>>> I've found it very hard to understand the assembler code printed by 
>>>> -XX:+PrintInterpreter. Since the C++ source code that generates the 
>>>> interpreter is fairly well documented, it might be a good idea to 
>>>> print out the source code along with the assembler code.
>>>>
>>>> I've done a quick proof-of-concept by hacking the "__" macro that's 
>>>> used throughout the CPU-dependent sources.
>>>>
>>>> Please let me know if you think this is worth doing. If so, I will 
>>>> try to finish it up and post a real RFR.
>>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8204267
>>>> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00 
>>>>
>>>> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00/hs_interp.S 
>>>>
>>>>
>>>> Here are some examples (if the mailer screws up the long lines, 
>>>> please click the above link):
>>>>
>>>> ifeq? 153 ifeq? [0x00007f830cc93da0, 0x00007f830cc941c0] 1056 bytes
>>>>
>>>> mov??? (%rsp),%eax
>>>> add??? $0x8,%rsp
>>>> test?? %eax,%eax?????????? ;; 2353:?? __ testl(rax, rax);
>>>> jne??? 0x00007f830cc94177? ;; 2354:?? __ jcc(j_not(cc), not_taken);
>>>> mov??? -0x18(%rbp),%rcx??? ;; 2120:?? __ get_method(rcx); // rcx 
>>>> holds method
>>>> mov??? -0x28(%rbp),%rax??? ;; 2121:?? __ profile_taken_branch(rax, 
>>>> rbx); // rax holds updated MDP, rbx
>>>> test?? %rax,%rax
>>>> je???? 0x00007f830cc93dd8
>>>> mov??? 0x8(%rax),%rbx
>>>> add??? $0x1,%rbx
>>>> sbb??? $0x0,%rbx
>>>> mov??? %rbx,0x8(%rax)
>>>> add??? 0x10(%rax),%rax
>>>> mov??? %rax,-0x28(%rbp)
>>>> movswl 0x1(%r13),%edx????? ;; 2133:???? __ load_signed_short(rdx, 
>>>> at_bcp(1));
>>>> bswap? %edx??????????????? ;; 2135:?? __ bswapl(rdx);
>>>> sar??? $0x10,%edx????????? ;; 2138:???? __ sarl(rdx, 16);
>>>> movslq %edx,%rdx?????????? ;; 2140:?? LP64_ONLY(__ movl2ptr(rdx, 
>>>> rdx));
>>>> add??? %rdx,%r13?????????? ;; 2164:?? __ addptr(rbcp, rdx);
>>>> test?? %edx,%edx?????????? ;; 2179:???? __ testl(rdx, 
>>>> rdx);???????????? // check if forward or backward branch
>>>> jns??? 0x00007f830cc93eec? ;; 2180:???? __ jcc(Assembler::positive, 
>>>> dispatch); // count only if backward branch
>>>> mov??? 0x18(%rcx),%rax???? ;; 2184:???? __ movptr(rax, Address(rcx, 
>>>> Method::method_counters_offset()));
>>>> test?? %rax,%rax?????????? ;; 2185:???? __ testptr(rax, rax);
>>>> jne??? 0x00007f830cc93ead? ;; 2186:???? __ jcc(Assembler::notZero, 
>>>> has_counters);
>>>> push?? %rdx??????????????? ;; 2187:???? __ push(rdx);
>>>> push?? %rcx??????????????? ;; 2188:???? __ push(rcx);
>>>> callq? 0x00007f830cc93e09? ;; 2189:???? __ call_VM(noreg, 
>>>> CAST_FROM_FN_PTR(address, InterpreterRuntime::build_method_counters),
>>>>
>>>
>>
>


From mikael.vidstedt at oracle.com  Wed Jul 11 22:52:26 2018
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 11 Jul 2018 15:52:26 -0700
Subject: RFR(S): 8207011: Remove uses of the register storage class specifier
Message-ID: <CAC20F9A-4A9B-4C19-A73F-75AD725F24EB@oracle.com>


Please review the below change which removes *most* uses of the register keyword/storage class specifier.

Bug: https://bugs.openjdk.java.net/browse/JDK-8207011 <https://bugs.openjdk.java.net/browse/JDK-8207011>
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/>

* Background (from the bug)

The C/C++ register keyword/storage class specifier may have made a difference many moons ago, but the C++11 standard deprecated it, and starting with C++17 it is a reserved keyword. Some compilers emit deprecation warnings even when targeting earlier C++ standards such as C++14.


* Commentary

The one case where the register keyword remains is when compiling (effectively) inline assembly with gcc, patterns like:

address os::current_stack_pointer() {
?
#else // gcc
  register void *esp __asm__ (SPELL_REG_SP);
  return (address) esp;
#endif
}

Removing the register keyword here breaks the code, and gcc does *not* complain about using it for these patterns, so I chose to leave it there. An alternative to that would be to always use the ?clang? style mov instruction. I know there is another thread[1] discussing how to move forward with the current_stack_pointer on clang 4.0. I?ll keep my eyes on that to make sure we don?t collide (and cc:ing Martin for good luck).

Would appreciate some help from the respective porting folks to verify the aix/ppc/s390 changes.

Cheers,
Mikael

[1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html>


From david.holmes at oracle.com  Wed Jul 11 23:39:22 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Jul 2018 09:39:22 +1000
Subject: 8207006: serviceability/sa/TestUniverse.java#id0 crashes with
 EpsilonGC and AOT
In-Reply-To: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>
References: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>
Message-ID: <9c0d4f5b-7039-646e-723c-13086aacf57c@oracle.com>

Hi Aleksey,

On 11/07/2018 11:31 PM, Aleksey Shipilev wrote:
> (This is cross-cutting compiler and GC, so posting at hotspot-dev@)
> 
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8207006
> 
> All uses of ci_card_table_address() outside of CardTableBarrierSet itself check
> is_a(BarrierSet::CardTableBarrierSet) before reaching for card table address. Epsilon does not have
> a card table, so unguarded check would assert in fastdebug, and crash in release.
> 
> Trivial fix:
>    http://cr.openjdk.java.net/~shade/8207006/webrev.01/

Can't comment on the actual fix.

> I would like to push this to jdk/jdk11 but I am puzzled to how do that. Do I need to seek another
> approval for jdk/jdk11? Do I push to both jdk/jdk and jdk/jdk11? Or just to jdk/jdk11, and it gets
> forward-ported automatically?

As we are in RDP1 and this is a P3 issue then it can get pushed to JDK 
11 (and 12 of course). No approvals are needed for RDP1.

If you push to jdk/jdk11 it will automatically be forward-ported to 
jdk/jdk, but it may take up to a week. You can also directly 
forward-port yourself (hg import the jdk11 changeset) if you need it in 
mainline more promptly.

> Testing: tier1_compiler (which seems to include AOT tests), HelloWorld AOT+Epsilon, jdk-submit (running)

I think probably needs additional AOT testing in a later tier. But 
someone from compiler team can help with that.

David
-----

> Thanks,
> -Aleksey
> 

From coleen.phillimore at oracle.com  Wed Jul 11 23:52:45 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 11 Jul 2018 19:52:45 -0400
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to
 link to source code
In-Reply-To: <d3cade53-0d15-1089-7f30-0b05ebbdb6bb@oracle.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
 <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
 <995aa43b-6789-58bf-429d-4653f6f19768@oracle.com>
 <5fd4286d-91d3-e728-aaaa-021fc2c350c0@oracle.com>
 <d3cade53-0d15-1089-7f30-0b05ebbdb6bb@oracle.com>
Message-ID: <c85340bd-4339-8b97-8371-aa54f651c500@oracle.com>


The diff doesn't show blank line changes, but I believe you that you 
fixed the indentation.


On 7/11/18 6:48 PM, Ioi Lam wrote:
>
>
> On 7/11/18 3:46 PM, Ioi Lam wrote:
>> Hi Coleen,
>>
>>
>> Thanks for the review. I have updated the patch according to your 
>> comments. Here's the diff from the last webrev:
>>
>>
>
> Sorry the correct URL is
>
> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v002.delta/ 
>
>
>>
>> On 7/11/18 10:44 AM, coleen.phillimore at oracle.com wrote:
>>>
>>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/src/hotspot/share/compiler/disassembler.cpp.udiff.html 
>>>
>>>
>>> + Link *link = new (ResourceObj::C_HEAP, mtInternal) Link(file, line);
>>>
>>>
>>> Can you use mtCode here?? Why not make Link inherit from 
>>> CHeapObj<mtCode> then just say new?
>>>
>> Fixed.
>>
>>> + if (_cached_src_lines != NULL) {
>>> + for (int i=0; i<_cached_src_lines->length(); i++) {
>>> + os::free((void*)_cached_src_lines->at(i));
>>> + }
>>> + _cached_src_lines->clear();
>>> + } else {
>>> + _cached_src_lines = new (ResourceObj::C_HEAP, 
>>> mtInternal)GrowableArray<const char*>(0, true);
>>> + }
>>>
>>>
>>> Growable Array has a delete operator that will clear_and_deallocate 
>>> all the elements and the array itself (which I don't think this does).
>>
>> We have this function:
>>
>> template<class E> void GrowableArray<E>::clear_and_deallocate() {
>> ??? assert(on_C_heap(),
>> ?????????? "clear_and_deallocate should only be called when on C heap");
>> ??? clear();
>> ??? if (_data != NULL) {
>> ????? for (int i = 0; i < _max; i++) _data[i].~E();
>> ????? free_C_heap(_data);
>> ????? _data = NULL;
>> ??? }
>> }
>>
>> My <E> type is currently <const char*>. To take advantage of 
>> clear_and_deallocate I have to wrap the const char* into something 
>> like this
>>
>> struct {
>> ?? const char* _line;
>> ?? LineInfo(const char* l) : _line(l) {}
>> ?? ~LineInfo() {os::free(_line);}
>> } LineInfo;
>>
>> but this adds a tone of boiler plate code and still won't work, 
>> because GrowableArray<E>::grow will call ~E(), which messes things up.
>>
>> So I'll just keep the existing code and won't bother.
>>
>>> ? But it looks like you're reusing _cached_src_lines for later 
>>> iterations.? It's an odd usage. But you can't resource allocate this?
>>>
>>
>> I am worried that we may have be under nested ResourceMarks, and the 
>> allocated _cached_src_lines may be freed unexpectedly.
>>
>>> 302 if (_cached_src == NULL || strcmp(_cached_src, file) != 0) {
>>>
>>>
>>> The indentation is wrong, and this would be a nice place for a 
>>> comment at line 301.
>>>
>> I fixed indent and added this comment
>>
>> ??????? // _cached_src_lines is a single cache of the lines of a 
>> source file, and we refill this cache
>> ??????? // every time we need to print a line from a different source 
>> file. It's not the fastest,
>> ??????? // but seems bearable.
>>
>>
>>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/src/hotspot/share/compiler/disassembler.hpp.udiff.html 
>>>
>>>
>>> I wonder if checking PrintInterpreter for each macro assembler line 
>>> will slow down generating the interpreter for the normal case. Maybe 
>>> there is an EnableIf<PrintInterpreter> sort of template trick to 
>>> make it evaporate?
>>>
>>> PrintInterpreter is an option in product mode.
>>>
>> I am hoping that __ is slow enough, so doing an extra load-and-test 
>> won't slow down it too much. I benchmarked "java -Xint -version" and 
>> the slow down is 0.11% after 1000 runs, so I guess it's acceptable.
>>
>> If people start complaining, we can do this later ....
>>
>> ? template<class T> inline static T* hook(const char* file, int line, 
>> T* masm) {
>> #ifdef ASSERT
>> ??? if (PrintInterpreter) {
>> ????? _hook(file, line, masm);
>> ??? }
>> #endif
>> ??? return masm;
>> ? }

You might want this on in product mode too though.?? If we see a 
slowdown, we can come up with a template trick later then.? I'm fine 
with this as is.? Looks good.

thanks!
Coleen
>>
>>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt 
>>>
>>>
>>> ? 0x00007f72c498d527: callq? 0x00007f72c498d531???????????? ;; 
>>> 126:?? __ call_VM(noreg,
>>>
>>>
>>> Should this say what it's calling?
>>>
>>> ? 0x00007f72c498d572: callq? 0x00007f72e3df9ea0 = 
>>> InterpreterRuntime::slow_signature_handler(JavaThread*, Method*, 
>>> long*, long*)
>>>
>>>
>>> But this says what it's calling but I don't think this is part of 
>>> your change (or is it?)
>>>
>> Yes. When you see a call_VM, you have to scan down and see what it's 
>> actually calling. It's no ideal, but I don't know how to improve it 
>> without writing a lot of code ... which I want to avoid.
>>
>> Thanks
>> - Ioi
>>
>>> That's all the comments I have. I wish you did this many years ago 
>>> also!
>>> Thanks,
>>> Coleen
>>>
>>> On 7/6/18 5:33 PM, Ioi Lam wrote:
>>>> Hi,
>>>>
>>>>
>>>> Since there's interest for this patch, I've finished it for the x86 
>>>> port:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8204267
>>>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/ 
>>>>
>>>>
>>>> You can see a sample at
>>>>
>>>> http://cr.openjdk.java.net/~iklam/jdk12/8204267-print-interpreter-comments.v001/sample.txt 
>>>>
>>>>
>>>> Incorporating this to other CPU ports should be pretty straight 
>>>> forward. You just
>>>> need to do something like:
>>>>
>>>> -#define __ _masm->
>>>> +#define __ Disassembler::hook<MacroAssembler>(__FILE__, __LINE__, 
>>>> _masm)->
>>>>
>>>> I'll leave it to other CPU port maintainers.
>>>>
>>>> I am testing with hs_tier{1,2}.
>>>>
>>>> Thanks
>>>>
>>>> - Ioi
>>>>
>>>>
>>>> On 6/4/18 12:12 AM, Ioi Lam wrote:
>>>>> Hi Folks,
>>>>>
>>>>> I've found it very hard to understand the assembler code printed 
>>>>> by -XX:+PrintInterpreter. Since the C++ source code that generates 
>>>>> the interpreter is fairly well documented, it might be a good idea 
>>>>> to print out the source code along with the assembler code.
>>>>>
>>>>> I've done a quick proof-of-concept by hacking the "__" macro 
>>>>> that's used throughout the CPU-dependent sources.
>>>>>
>>>>> Please let me know if you think this is worth doing. If so, I will 
>>>>> try to finish it up and post a real RFR.
>>>>>
>>>>> Thanks
>>>>> - Ioi
>>>>>
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8204267
>>>>> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00 
>>>>>
>>>>> http://cr.openjdk.java.net/~iklam/misc/8204267-print-interpreter-comments.v00/hs_interp.S 
>>>>>
>>>>>
>>>>> Here are some examples (if the mailer screws up the long lines, 
>>>>> please click the above link):
>>>>>
>>>>> ifeq? 153 ifeq? [0x00007f830cc93da0, 0x00007f830cc941c0] 1056 bytes
>>>>>
>>>>> mov??? (%rsp),%eax
>>>>> add??? $0x8,%rsp
>>>>> test?? %eax,%eax?????????? ;; 2353:?? __ testl(rax, rax);
>>>>> jne??? 0x00007f830cc94177? ;; 2354:?? __ jcc(j_not(cc), not_taken);
>>>>> mov??? -0x18(%rbp),%rcx??? ;; 2120:?? __ get_method(rcx); // rcx 
>>>>> holds method
>>>>> mov??? -0x28(%rbp),%rax??? ;; 2121:?? __ profile_taken_branch(rax, 
>>>>> rbx); // rax holds updated MDP, rbx
>>>>> test?? %rax,%rax
>>>>> je???? 0x00007f830cc93dd8
>>>>> mov??? 0x8(%rax),%rbx
>>>>> add??? $0x1,%rbx
>>>>> sbb??? $0x0,%rbx
>>>>> mov??? %rbx,0x8(%rax)
>>>>> add??? 0x10(%rax),%rax
>>>>> mov??? %rax,-0x28(%rbp)
>>>>> movswl 0x1(%r13),%edx????? ;; 2133:???? __ load_signed_short(rdx, 
>>>>> at_bcp(1));
>>>>> bswap? %edx??????????????? ;; 2135:?? __ bswapl(rdx);
>>>>> sar??? $0x10,%edx????????? ;; 2138:???? __ sarl(rdx, 16);
>>>>> movslq %edx,%rdx?????????? ;; 2140:?? LP64_ONLY(__ movl2ptr(rdx, 
>>>>> rdx));
>>>>> add??? %rdx,%r13?????????? ;; 2164:?? __ addptr(rbcp, rdx);
>>>>> test?? %edx,%edx?????????? ;; 2179:???? __ testl(rdx, 
>>>>> rdx);???????????? // check if forward or backward branch
>>>>> jns??? 0x00007f830cc93eec? ;; 2180:???? __ 
>>>>> jcc(Assembler::positive, dispatch); // count only if backward branch
>>>>> mov??? 0x18(%rcx),%rax???? ;; 2184:???? __ movptr(rax, 
>>>>> Address(rcx, Method::method_counters_offset()));
>>>>> test?? %rax,%rax?????????? ;; 2185:???? __ testptr(rax, rax);
>>>>> jne??? 0x00007f830cc93ead? ;; 2186:???? __ jcc(Assembler::notZero, 
>>>>> has_counters);
>>>>> push?? %rdx??????????????? ;; 2187:???? __ push(rdx);
>>>>> push?? %rcx??????????????? ;; 2188:???? __ push(rcx);
>>>>> callq? 0x00007f830cc93e09? ;; 2189:???? __ call_VM(noreg, 
>>>>> CAST_FROM_FN_PTR(address, InterpreterRuntime::build_method_counters),
>>>>>
>>>>
>>>
>>
>


From kim.barrett at oracle.com  Thu Jul 12 04:03:42 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 12 Jul 2018 00:03:42 -0400
Subject: RFR(S): 8207011: Remove uses of the register storage class
 specifier
In-Reply-To: <CAC20F9A-4A9B-4C19-A73F-75AD725F24EB@oracle.com>
References: <CAC20F9A-4A9B-4C19-A73F-75AD725F24EB@oracle.com>
Message-ID: <35BB03F7-3FCB-4DC9-82A1-F1DFD4FDCD2F@oracle.com>

> On Jul 11, 2018, at 6:52 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
> 
> 
> Please review the below change which removes *most* uses of the register keyword/storage class specifier.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8207011 <https://bugs.openjdk.java.net/browse/JDK-8207011>
> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/>
> 
> * Background (from the bug)
> 
> The C/C++ register keyword/storage class specifier may have made a difference many moons ago, but the C++11 standard deprecated it, and starting with C++17 it is a reserved keyword. Some compilers emit deprecation warnings even when targeting earlier C++ standards such as C++14.
> 
> 
> * Commentary
> 
> The one case where the register keyword remains is when compiling (effectively) inline assembly with gcc, patterns like:
> 
> address os::current_stack_pointer() {
> ?
> #else // gcc
>  register void *esp __asm__ (SPELL_REG_SP);
>  return (address) esp;
> #endif
> }
> 
> Removing the register keyword here breaks the code, and gcc does *not* complain about using it for these patterns, so I chose to leave it there. An alternative to that would be to always use the ?clang? style mov instruction. I know there is another thread[1] discussing how to move forward with the current_stack_pointer on clang 4.0. I?ll keep my eyes on that to make sure we don?t collide (and cc:ing Martin for good luck).
> 
> Would appreciate some help from the respective porting folks to verify the aix/ppc/s390 changes.
> 
> Cheers,
> Mikael
> 
> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html>

Looks good.


From shade at redhat.com  Thu Jul 12 07:54:34 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 12 Jul 2018 09:54:34 +0200
Subject: 8207006: serviceability/sa/TestUniverse.java#id0 crashes with
 EpsilonGC and AOT
In-Reply-To: <9c0d4f5b-7039-646e-723c-13086aacf57c@oracle.com>
References: <87b71910-f759-cc07-dc5b-7036886750a7@redhat.com>
 <9c0d4f5b-7039-646e-723c-13086aacf57c@oracle.com>
Message-ID: <8e6c9e51-7c48-d635-4e75-58fc02329b64@redhat.com>

On 07/12/2018 01:39 AM, David Holmes wrote:
>> I would like to push this to jdk/jdk11 but I am puzzled to how do that. Do I need to seek another
>> approval for jdk/jdk11? Do I push to both jdk/jdk and jdk/jdk11? Or just to jdk/jdk11, and it gets
>> forward-ported automatically?
> 
> As we are in RDP1 and this is a P3 issue then it can get pushed to JDK 11 (and 12 of course). No
> approvals are needed for RDP1.
> 
> If you push to jdk/jdk11 it will automatically be forward-ported to jdk/jdk, but it may take up to a
> week. You can also directly forward-port yourself (hg import the jdk11 changeset) if you need it in
> mainline more promptly.

Thanks! Pushed to jdk/jdk11. There is no rush, I'll wait for jdk/jdk11 -> jdk/jdk sync.

-Aleksey


From boris.ulasevich at bell-sw.com  Thu Jul 12 09:12:36 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Thu, 12 Jul 2018 12:12:36 +0300
Subject: [11] RFR (XS) 8207047: Multiple VM variants build fail
Message-ID: <c77ea2d7-2612-7b0f-8dc2-6f981a8e709c@bell-sw.com>

Hi all,

Please review a simple patch:
http://cr.openjdk.java.net/~bulasevich/8207047/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8207047

Collision happens on JFR gensrc tool when make system runs several VM 
configuration's gensrc concurrently. Let us move JFR gensrc tools files 
from shared output to the JVM_VARIANT output folder.

thanks,
Boris

From sgehwolf at redhat.com  Thu Jul 12 09:32:23 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 12 Jul 2018 11:32:23 +0200
Subject: [11] RFR (XS) 8207047: Multiple VM variants build fail
In-Reply-To: <c77ea2d7-2612-7b0f-8dc2-6f981a8e709c@bell-sw.com>
References: <c77ea2d7-2612-7b0f-8dc2-6f981a8e709c@bell-sw.com>
Message-ID: <8ea633f50e9b91c773464b91a7ee5ec9f1775d64.camel@redhat.com>

Adding build-dev as this is a build change.

On Thu, 2018-07-12 at 12:12 +0300, Boris Ulasevich wrote:
> Hi all,
> 
> Please review a simple patch:
> http://cr.openjdk.java.net/~bulasevich/8207047/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8207047
> 
> Collision happens on JFR gensrc tool when make system runs several VM 
> configuration's gensrc concurrently. Let us move JFR gensrc tools files 
> from shared output to the JVM_VARIANT output folder.
> 
> thanks,
> Boris

From aph at redhat.com  Thu Jul 12 09:48:28 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Jul 2018 10:48:28 +0100
Subject: RFR(S) 8204267 - Generate comments in -XX:+PrintInterpreter to
 link to source code
In-Reply-To: <82a98f5a-4962-47d8-fb88-3b609d50f2a1@oracle.com>
References: <07d64693-9e7b-8795-5c7a-f226b6c35610@oracle.com>
 <76dd972d-33f0-200a-12af-0d0e4742c025@oracle.com>
 <26f937ba-df59-5cfb-f227-915c00d48d63@redhat.com>
 <82a98f5a-4962-47d8-fb88-3b609d50f2a1@oracle.com>
Message-ID: <a242280d-e77c-ef01-3413-7ca48c0e6e2b@redhat.com>

On 07/11/2018 10:03 PM, Ioi Lam wrote:
> Thanks Andrew for the review. For the aarch64 code, maybe you can push 
> it as a separate bug ID, so you can do more testing first?

Oh, sure, I never intended you to push them.  I just wanted them somewhere
safe.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From zgu at redhat.com  Thu Jul 12 13:19:31 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 12 Jul 2018 09:19:31 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
Message-ID: <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>

Hi,

Epsilon just became the first GC to support object pinning!
(https://bugs.openjdk.java.net/browse/JDK-8207056)

I added test cases for Epsilon to exercise this patch.

Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.03/index.html

Test:

   gc/epsilon on Linux 64 (fastdebug + release)

Thanks,

-Zhengyu


On 07/05/2018 02:37 PM, Roman Kennke wrote:
> I am not an expert in this particular code, but know assembly well. The
> implementation looks good to me.
> 
> What happens when JNI critical functions are encountered on other
> platforms? Will it fail gracefully or fall back to something else? Would
> (for example) Shenandoah have to turn off JNI criticals on such
> platforms until support gets implemented?
> 
> Also, as you mentioned, it baked quite a lot in Shenandoah already, and
> passes our tests that stress this code.
> 
> Thank you!
> Roman
> 
>> Ping!!!! anyone? please!
>>
>> - Zhengyu
>>
>> On 05/02/2018 05:12 PM, Per Liden wrote:
>>> Hi,
>>>
>>> On 05/02/2018 09:41 PM, Zhengyu Gu wrote:
>>>> Hi,
>>>>
>>>> Can I have reviews for this RFR?
>>>>
>>>> This patch completes object pinning for JNI critical section,
>>>> provides critical native support.
>>>>
>>>> The approach is quite straightforward:
>>>>
>>>> During generating native wrapper for critical native method, it
>>>> generates runtime call to pin every array argument, before unpacks them.
>>>>
>>>> For pinned objects, it also needs to save them for unpinning after
>>>> JNI function call completes.
>>>>
>>>> If argument is passed on stack, it saves pinned object at the
>>>> original slot (as pin_object() may move the object). For register
>>>> based arguments, it reuses oop handle area (where GCLocker based
>>>> implementation saves register based arguments for safepoints).
>>>>
>>>> Currently, only Shenandoah uses object pinning for JNI critical
>>>> section, this patch has been baked quite some time there. However, I
>>>> am new to Runtime Stub code, I would appreciate your comments and
>>>> suggestions.
>>>>
>>>> I rebased patch to jdk/jdk repo.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.02/
>>>
>>> Just want to say that I would really like to see this patch go in. As
>>> mentioned, it completes the object pinning story and it's useful for
>>> other GCs too (at least ZGC and possibly G1). However, I also agree
>>> with Aleksey that some one who really knows this code needs to review
>>> this. Unfortunately that's not me. Anyone?
>>>
>>> cheers,
>>> Per
>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>> On 04/06/2018 10:35 PM, Zhengyu Gu wrote:
>>>>> Offline discussion with Aleksey, he suggested that
>>>>> pin/unpin_critical_native_array methods can be made more generic as
>>>>> pin/unpin_object.
>>>>>
>>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.01/
>>>>>
>>>>> Test:
>>>>>  ?? Reran all tests, submit-hs tests still clean.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>> On 04/06/2018 08:55 AM, Aleksey Shipilev wrote:
>>>>>> On 04/04/2018 07:47 PM, Zhengyu Gu wrote:
>>>>>>> Please review this patch that adds JNI critical native support to
>>>>>>> object pinning.
>>>>>>>
>>>>>>> Shenandoah does not block GC while JNI critical session is in
>>>>>>> progress. This patch allows it to pin
>>>>>>> all incoming array objects before critical native call, and unpin
>>>>>>> them after call completes.
>>>>>>>
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199868
>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.00/
>>>>>>
>>>>>> Looks good to me, but somebody more savvy with runtime stub
>>>>>> generation should take a closer look.
>>>>>>
>>>>>> *) Should probably be "Why we are here?"
>>>>>>
>>>>>> 2867?? assert(Universe::heap()->supports_object_pinning(), "Why we
>>>>>> here?");
>>>>>>
>>>>>> 2876?? assert(Universe::heap()->supports_object_pinning(), "Why we
>>>>>> here?");
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> -Aleksey
>>>>>>
> 
> 

From erik.joelsson at oracle.com  Thu Jul 12 14:09:44 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 12 Jul 2018 07:09:44 -0700
Subject: [11] RFR (XS) 8207047: Multiple VM variants build fail
In-Reply-To: <8ea633f50e9b91c773464b91a7ee5ec9f1775d64.camel@redhat.com>
References: <c77ea2d7-2612-7b0f-8dc2-6f981a8e709c@bell-sw.com>
 <8ea633f50e9b91c773464b91a7ee5ec9f1775d64.camel@redhat.com>
Message-ID: <5d361d36-fe74-9455-e393-083a9a3ae328@oracle.com>

Looks good.

I thought I had fixed this, but now realize it was part of a change that 
is currently on hold and I never got around to extracting this 
particular fix as a separate fix.

Thanks for fixing it!

/Erik


On 2018-07-12 02:32, Severin Gehwolf wrote:
> Adding build-dev as this is a build change.
>
> On Thu, 2018-07-12 at 12:12 +0300, Boris Ulasevich wrote:
>> Hi all,
>>
>> Please review a simple patch:
>> http://cr.openjdk.java.net/~bulasevich/8207047/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8207047
>>
>> Collision happens on JFR gensrc tool when make system runs several VM
>> configuration's gensrc concurrently. Let us move JFR gensrc tools files
>> from shared output to the JVM_VARIANT output folder.
>>
>> thanks,
>> Boris


From goetz.lindenmaier at sap.com  Thu Jul 12 15:03:39 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 12 Jul 2018 15:03:39 +0000
Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
 include module and class loader information
In-Reply-To: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
References: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
Message-ID: <a26721cf429949dd947350c07695e9cc@sap.com>

Hi Lois, 

I had a look at your change. It's a much better format bearing the 
same information. Thus looks good to me.

I would appreciate if you change printing the messages in linkResolver.cpp and
klassVtable.cpp to use stringStream, similar to linkResolver.cpp:1020
and other places (I should have changed that in first place when
I extended these messages before).

systemDictionary.cpp
  I think it's convention to have a space after the comma:
  existing_klass->class_in_module_of_loader(false,true));
 This is in several places.

Best regards,
  Goetz.



> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Lois Foltan
> Sent: Mittwoch, 27. Juni 2018 15:20
> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
> include module and class loader information
> 
> Please review this change to migrate existing loader constraint
> LinkageErrors to the new error message format proposal.? The actual
> wording of the loader constraint messages has not changed.? Module and
> class loader information have been moved into the error message's REASON
> section.? This change also removes the method
> java_lang_ClassLoader::describe_external() in favor of
> Klass::class_in_module_of_loader().
> 
> open webrev at
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611/webrev/
> bug link https://bugs.openjdk.java.net/browse/JDK-8205611
> 
> JDK-8166633 outlines a new proposal where error messages follow a format
> of ERRROR: PROBLEM (REASON) where the PROBLEM is aggressively simple
> (and definitely avoids arbitrary-length loader names) so the REASON
> bears all the cost of explaining the PROBLEM with more specifics.? See
> the proposal in more detail at
> https://bugs.openjdk.java.net/browse/JDK-8166633. The new utility method
> Klass::class_in_module_of_loader() implements the proposed format.
> 
> Some example text:
> 
> (JDK 11) 'DuplicateLE_Test_Loader_IF' @<id> (instance of
> PreemptingClassLoader, child of 'app'
> jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate
> interface definition for test.J.
> to
> (JDK 12) loader 'DuplicateLE_Test_Loader_IF' @6eeee674 attempted
> duplicate interface definition for test.J. (test.J is in unnamed module
> of loader 'DuplicateLE_Test_Loader_IF' @6eeee674, parent loader 'app')
> 
> 
> (JDK 11) loader constraint violation: loader PreemptingClassLoader @<id>
> (instance of PreemptingClassLoader, child of 'app'
> jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load class
> test.D_ambgs. A different class with the same name was previously loaded
> by 'app' (instance of jdk.internal.loader.ClassLoaders$AppClassLoader).
> to
> (JDK 12) loader constraint violation: loader PreemptingClassLoader
> @5bc79a1c wants to load class test.D_ambgs. A different class with the
> same name was previously loaded by 'app'. (test.D_ambgs is in unnamed
> module of loader 'app')
> 
> 
> (JDK 11) loader constraint violation for class test.Task: when selecting
> overriding method test.Task.m()Ltest/Foo; the class loader
> PreemptingClassLoader @<id> (instance of PreemptingClassLoader, child of
> 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) of the selected
> method's type test.Task, and the class loader 'app' (instance of
> jdk.internal.loader.ClassLoaders$AppClassLoader) for its super type
> test.J have different Class objects for the type test.Foo used in the
> signature
> to
> (JDK 12) loader constraint violation for class test.Task: when selecting
> overriding method test.Task.m()Ltest/Foo; the class loader
> PreemptingClassLoader @7884e077 of the selected method's type test.Task,
> and the class loader 'app' for its super type test.J have different
> Class objects for the type test.Foo used in the signature (test.Task is
> in unnamed module of loader PreemptingClassLoader @7884e077, parent
> loader 'app'; test.J is in unnamed module of loader 'app')
> 
> 
> Testing: hs-tier(1-3), jdk-tier(1-3) complete
>  ?????????????? hs-tier(4,5) in progress
>  ?????????????? JCK vm, lang in progress
> 
> Thanks,
> Lois

From martinrb at google.com  Thu Jul 12 18:42:03 2018
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 12 Jul 2018 11:42:03 -0700
Subject: RFR(S): 8207011: Remove uses of the register storage class
 specifier
In-Reply-To: <CAC20F9A-4A9B-4C19-A73F-75AD725F24EB@oracle.com>
References: <CAC20F9A-4A9B-4C19-A73F-75AD725F24EB@oracle.com>
Message-ID: <CA+kOe08T4=-Nts0aLNs-TMLekKojHnep_DuHM-W099GgjSv=5A@mail.gmail.com>

On Wed, Jul 11, 2018 at 3:52 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com
> wrote:

>
> Removing the register keyword here breaks the code, and gcc does *not*
> complain about using it for these patterns, so I chose to leave it there.
> An alternative to that would be to always use the ?clang? style mov
> instruction. I know there is another thread[1] discussing how to move
> forward with the current_stack_pointer on clang 4.0. I?ll keep my eyes on
> that to make sure we don?t collide (and cc:ing Martin for good luck).
>

As I wrote elsewhere, I'd like to get rid of the super-brittle stack
pointer assembly entirely, but especially for stack alignment checking.

From lois.foltan at oracle.com  Thu Jul 12 19:10:24 2018
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 12 Jul 2018 15:10:24 -0400
Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
 include module and class loader information
In-Reply-To: <a26721cf429949dd947350c07695e9cc@sap.com>
References: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
 <a26721cf429949dd947350c07695e9cc@sap.com>
Message-ID: <762ca092-81c2-2557-7710-9e3cde2c005a@oracle.com>

On 7/12/2018 11:03 AM, Lindenmaier, Goetz wrote:

> Hi Lois,
>
> I had a look at your change. It's a much better format bearing the
> same information. Thus looks good to me.
>
> I would appreciate if you change printing the messages in linkResolver.cpp and
> klassVtable.cpp to use stringStream, similar to linkResolver.cpp:1020
> and other places (I should have changed that in first place when
> I extended these messages before).
>
> systemDictionary.cpp
>    I think it's convention to have a space after the comma:
>    existing_klass->class_in_module_of_loader(false,true));
>   This is in several places.

Thanks Goetz!? All you comments have been addressed.? See new webrev at

http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611.1/webrev/

Lois
>
> Best regards,
>    Goetz.
>
>
>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of Lois Foltan
>> Sent: Mittwoch, 27. Juni 2018 15:20
>> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
>> Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
>> include module and class loader information
>>
>> Please review this change to migrate existing loader constraint
>> LinkageErrors to the new error message format proposal.? The actual
>> wording of the loader constraint messages has not changed.? Module and
>> class loader information have been moved into the error message's REASON
>> section.? This change also removes the method
>> java_lang_ClassLoader::describe_external() in favor of
>> Klass::class_in_module_of_loader().
>>
>> open webrev at
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611/webrev/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8205611
>>
>> JDK-8166633 outlines a new proposal where error messages follow a format
>> of ERRROR: PROBLEM (REASON) where the PROBLEM is aggressively simple
>> (and definitely avoids arbitrary-length loader names) so the REASON
>> bears all the cost of explaining the PROBLEM with more specifics.? See
>> the proposal in more detail at
>> https://bugs.openjdk.java.net/browse/JDK-8166633. The new utility method
>> Klass::class_in_module_of_loader() implements the proposed format.
>>
>> Some example text:
>>
>> (JDK 11) 'DuplicateLE_Test_Loader_IF' @<id> (instance of
>> PreemptingClassLoader, child of 'app'
>> jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate
>> interface definition for test.J.
>> to
>> (JDK 12) loader 'DuplicateLE_Test_Loader_IF' @6eeee674 attempted
>> duplicate interface definition for test.J. (test.J is in unnamed module
>> of loader 'DuplicateLE_Test_Loader_IF' @6eeee674, parent loader 'app')
>>
>>
>> (JDK 11) loader constraint violation: loader PreemptingClassLoader @<id>
>> (instance of PreemptingClassLoader, child of 'app'
>> jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load class
>> test.D_ambgs. A different class with the same name was previously loaded
>> by 'app' (instance of jdk.internal.loader.ClassLoaders$AppClassLoader).
>> to
>> (JDK 12) loader constraint violation: loader PreemptingClassLoader
>> @5bc79a1c wants to load class test.D_ambgs. A different class with the
>> same name was previously loaded by 'app'. (test.D_ambgs is in unnamed
>> module of loader 'app')
>>
>>
>> (JDK 11) loader constraint violation for class test.Task: when selecting
>> overriding method test.Task.m()Ltest/Foo; the class loader
>> PreemptingClassLoader @<id> (instance of PreemptingClassLoader, child of
>> 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) of the selected
>> method's type test.Task, and the class loader 'app' (instance of
>> jdk.internal.loader.ClassLoaders$AppClassLoader) for its super type
>> test.J have different Class objects for the type test.Foo used in the
>> signature
>> to
>> (JDK 12) loader constraint violation for class test.Task: when selecting
>> overriding method test.Task.m()Ltest/Foo; the class loader
>> PreemptingClassLoader @7884e077 of the selected method's type test.Task,
>> and the class loader 'app' for its super type test.J have different
>> Class objects for the type test.Foo used in the signature (test.Task is
>> in unnamed module of loader PreemptingClassLoader @7884e077, parent
>> loader 'app'; test.J is in unnamed module of loader 'app')
>>
>>
>> Testing: hs-tier(1-3), jdk-tier(1-3) complete
>>   ?????????????? hs-tier(4,5) in progress
>>   ?????????????? JCK vm, lang in progress
>>
>> Thanks,
>> Lois


From coleen.phillimore at oracle.com  Thu Jul 12 20:35:11 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 12 Jul 2018 16:35:11 -0400
Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
 include module and class loader information
In-Reply-To: <762ca092-81c2-2557-7710-9e3cde2c005a@oracle.com>
References: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
 <a26721cf429949dd947350c07695e9cc@sap.com>
 <762ca092-81c2-2557-7710-9e3cde2c005a@oracle.com>
Message-ID: <da4ab3d9-32a5-3dc2-7364-84800c95d33e@oracle.com>


This change looks really good!? The new error format in linkResolver and 
klassVtable is nice.
Thank you all for the work to agree on a format!
Coleen


On 7/12/18 3:10 PM, Lois Foltan wrote:
> On 7/12/2018 11:03 AM, Lindenmaier, Goetz wrote:
>
>> Hi Lois,
>>
>> I had a look at your change. It's a much better format bearing the
>> same information. Thus looks good to me.
>>
>> I would appreciate if you change printing the messages in 
>> linkResolver.cpp and
>> klassVtable.cpp to use stringStream, similar to linkResolver.cpp:1020
>> and other places (I should have changed that in first place when
>> I extended these messages before).
>>
>> systemDictionary.cpp
>> ?? I think it's convention to have a space after the comma:
>> ?? existing_klass->class_in_module_of_loader(false,true));
>> ? This is in several places.
>
> Thanks Goetz!? All you comments have been addressed.? See new webrev at
>
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611.1/webrev/
>
> Lois
>>
>> Best regards,
>> ?? Goetz.
>>
>>
>>
>>> -----Original Message-----
>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>>> Behalf Of Lois Foltan
>>> Sent: Mittwoch, 27. Juni 2018 15:20
>>> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
>>> Subject: [12] RFR (M) JDK-8205611: Improve the wording of 
>>> LinkageErrors to
>>> include module and class loader information
>>>
>>> Please review this change to migrate existing loader constraint
>>> LinkageErrors to the new error message format proposal.? The actual
>>> wording of the loader constraint messages has not changed. Module and
>>> class loader information have been moved into the error message's 
>>> REASON
>>> section.? This change also removes the method
>>> java_lang_ClassLoader::describe_external() in favor of
>>> Klass::class_in_module_of_loader().
>>>
>>> open webrev at
>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611/webrev/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8205611
>>>
>>> JDK-8166633 outlines a new proposal where error messages follow a 
>>> format
>>> of ERRROR: PROBLEM (REASON) where the PROBLEM is aggressively simple
>>> (and definitely avoids arbitrary-length loader names) so the REASON
>>> bears all the cost of explaining the PROBLEM with more specifics.? See
>>> the proposal in more detail at
>>> https://bugs.openjdk.java.net/browse/JDK-8166633. The new utility 
>>> method
>>> Klass::class_in_module_of_loader() implements the proposed format.
>>>
>>> Some example text:
>>>
>>> (JDK 11) 'DuplicateLE_Test_Loader_IF' @<id> (instance of
>>> PreemptingClassLoader, child of 'app'
>>> jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate
>>> interface definition for test.J.
>>> to
>>> (JDK 12) loader 'DuplicateLE_Test_Loader_IF' @6eeee674 attempted
>>> duplicate interface definition for test.J. (test.J is in unnamed module
>>> of loader 'DuplicateLE_Test_Loader_IF' @6eeee674, parent loader 'app')
>>>
>>>
>>> (JDK 11) loader constraint violation: loader PreemptingClassLoader 
>>> @<id>
>>> (instance of PreemptingClassLoader, child of 'app'
>>> jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load class
>>> test.D_ambgs. A different class with the same name was previously 
>>> loaded
>>> by 'app' (instance of jdk.internal.loader.ClassLoaders$AppClassLoader).
>>> to
>>> (JDK 12) loader constraint violation: loader PreemptingClassLoader
>>> @5bc79a1c wants to load class test.D_ambgs. A different class with the
>>> same name was previously loaded by 'app'. (test.D_ambgs is in unnamed
>>> module of loader 'app')
>>>
>>>
>>> (JDK 11) loader constraint violation for class test.Task: when 
>>> selecting
>>> overriding method test.Task.m()Ltest/Foo; the class loader
>>> PreemptingClassLoader @<id> (instance of PreemptingClassLoader, 
>>> child of
>>> 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) of the selected
>>> method's type test.Task, and the class loader 'app' (instance of
>>> jdk.internal.loader.ClassLoaders$AppClassLoader) for its super type
>>> test.J have different Class objects for the type test.Foo used in the
>>> signature
>>> to
>>> (JDK 12) loader constraint violation for class test.Task: when 
>>> selecting
>>> overriding method test.Task.m()Ltest/Foo; the class loader
>>> PreemptingClassLoader @7884e077 of the selected method's type 
>>> test.Task,
>>> and the class loader 'app' for its super type test.J have different
>>> Class objects for the type test.Foo used in the signature (test.Task is
>>> in unnamed module of loader PreemptingClassLoader @7884e077, parent
>>> loader 'app'; test.J is in unnamed module of loader 'app')
>>>
>>>
>>> Testing: hs-tier(1-3), jdk-tier(1-3) complete
>>> ? ?????????????? hs-tier(4,5) in progress
>>> ? ?????????????? JCK vm, lang in progress
>>>
>>> Thanks,
>>> Lois
>


From vladimir.kozlov at oracle.com  Thu Jul 12 22:45:02 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 12 Jul 2018 15:45:02 -0700
Subject: RFR(S): 8207011: Remove uses of the register storage class
 specifier
In-Reply-To: <CAC20F9A-4A9B-4C19-A73F-75AD725F24EB@oracle.com>
References: <CAC20F9A-4A9B-4C19-A73F-75AD725F24EB@oracle.com>
Message-ID: <546aaa08-8e39-bcd9-eb75-6a95f86eebd1@oracle.com>

Seems good to me.

Only 'register' keyword was removed except one place in os_linux_x86.cpp where intptr_t* esp; was 
replaced with void* esp; to be consistent as I understand.

Thanks,
Vladimir

On 7/11/18 3:52 PM, Mikael Vidstedt wrote:
> 
> Please review the below change which removes *most* uses of the register keyword/storage class specifier.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8207011 <https://bugs.openjdk.java.net/browse/JDK-8207011>
> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/>
> 
> * Background (from the bug)
> 
> The C/C++ register keyword/storage class specifier may have made a difference many moons ago, but the C++11 standard deprecated it, and starting with C++17 it is a reserved keyword. Some compilers emit deprecation warnings even when targeting earlier C++ standards such as C++14.
> 
> 
> * Commentary
> 
> The one case where the register keyword remains is when compiling (effectively) inline assembly with gcc, patterns like:
> 
> address os::current_stack_pointer() {
> ?
> #else // gcc
>    register void *esp __asm__ (SPELL_REG_SP);
>    return (address) esp;
> #endif
> }
> 
> Removing the register keyword here breaks the code, and gcc does *not* complain about using it for these patterns, so I chose to leave it there. An alternative to that would be to always use the ?clang? style mov instruction. I know there is another thread[1] discussing how to move forward with the current_stack_pointer on clang 4.0. I?ll keep my eyes on that to make sure we don?t collide (and cc:ing Martin for good luck).
> 
> Would appreciate some help from the respective porting folks to verify the aix/ppc/s390 changes.
> 
> Cheers,
> Mikael
> 
> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html>
> 

From mikael.vidstedt at oracle.com  Thu Jul 12 23:22:50 2018
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 12 Jul 2018 16:22:50 -0700
Subject: RFR(S): 8207011: Remove uses of the register storage class
 specifier
In-Reply-To: <546aaa08-8e39-bcd9-eb75-6a95f86eebd1@oracle.com>
References: <CAC20F9A-4A9B-4C19-A73F-75AD725F24EB@oracle.com>
 <546aaa08-8e39-bcd9-eb75-6a95f86eebd1@oracle.com>
Message-ID: <22784849-0C27-4FAE-B783-A8AD5CA4E46E@oracle.com>


That is correct.

Kim, Vladimir - thanks for the reviews!

Martin, fyi: I?ll run some final testing on this and if all goes well I?ll likely push later today.

Cheers,
Mikael

> On Jul 12, 2018, at 3:45 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Seems good to me.
> 
> Only 'register' keyword was removed except one place in os_linux_x86.cpp where intptr_t* esp; was replaced with void* esp; to be consistent as I understand.
> 
> Thanks,
> Vladimir
> 
> On 7/11/18 3:52 PM, Mikael Vidstedt wrote:
>> Please review the below change which removes *most* uses of the register keyword/storage class specifier.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8207011 <https://bugs.openjdk.java.net/browse/JDK-8207011>
>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8207011/webrev.01/open/webrev/>
>> * Background (from the bug)
>> The C/C++ register keyword/storage class specifier may have made a difference many moons ago, but the C++11 standard deprecated it, and starting with C++17 it is a reserved keyword. Some compilers emit deprecation warnings even when targeting earlier C++ standards such as C++14.
>> * Commentary
>> The one case where the register keyword remains is when compiling (effectively) inline assembly with gcc, patterns like:
>> address os::current_stack_pointer() {
>> ?
>> #else // gcc
>>   register void *esp __asm__ (SPELL_REG_SP);
>>   return (address) esp;
>> #endif
>> }
>> Removing the register keyword here breaks the code, and gcc does *not* complain about using it for these patterns, so I chose to leave it there. An alternative to that would be to always use the ?clang? style mov instruction. I know there is another thread[1] discussing how to move forward with the current_stack_pointer on clang 4.0. I?ll keep my eyes on that to make sure we don?t collide (and cc:ing Martin for good luck).
>> Would appreciate some help from the respective porting folks to verify the aix/ppc/s390 changes.
>> Cheers,
>> Mikael
>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-July/029099.html>


From coleen.phillimore at oracle.com  Thu Jul 12 23:48:54 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 12 Jul 2018 19:48:54 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <6DD2A01C-B90E-45C4-BADF-1290BBEB02E6@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <172e2fb9-3c25-b89c-1598-49eb85a4ff0e@oracle.com>
 <6DD2A01C-B90E-45C4-BADF-1290BBEB02E6@oracle.com>
Message-ID: <36ba4814-cb3d-3c99-4595-28a4d8f641f1@oracle.com>



On 7/11/18 3:06 PM, Kim Barrett wrote:
>> On Jul 11, 2018, at 2:31 PM, coleen.phillimore at oracle.com wrote:
>>
>>
>> This looks very nice but one question:
>>
>> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/src/hotspot/os/linux/os_linux.cpp.udiff.html
>>
>> + while (result && (ptr = readdir(dir)) != NULL) {
>>
>>
>> What deallocates the dirent* memory?
> That memory belongs to the DIR* dir, and is reclaimed by the closdir(dir) at the end of the function.
>
Great.? Looks good to me.
thanks,
Coleen

From kim.barrett at oracle.com  Fri Jul 13 04:11:52 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 13 Jul 2018 00:11:52 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <36ba4814-cb3d-3c99-4595-28a4d8f641f1@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <172e2fb9-3c25-b89c-1598-49eb85a4ff0e@oracle.com>
 <6DD2A01C-B90E-45C4-BADF-1290BBEB02E6@oracle.com>
 <36ba4814-cb3d-3c99-4595-28a4d8f641f1@oracle.com>
Message-ID: <51E15C82-22C0-47DB-A0EB-5DE81A7DBBC6@oracle.com>

> On Jul 12, 2018, at 7:48 PM, coleen.phillimore at oracle.com wrote:
> 
> 
> 
> On 7/11/18 3:06 PM, Kim Barrett wrote:
>>> On Jul 11, 2018, at 2:31 PM, coleen.phillimore at oracle.com wrote:
>>> 
>>> 
>>> This looks very nice but one question:
>>> 
>>> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/src/hotspot/os/linux/os_linux.cpp.udiff.html
>>> 
>>> + while (result && (ptr = readdir(dir)) != NULL) {
>>> 
>>> 
>>> What deallocates the dirent* memory?
>> That memory belongs to the DIR* dir, and is reclaimed by the closdir(dir) at the end of the function.
>> 
> Great.  Looks good to me.
> thanks,
> Coleen

Thanks.


From goetz.lindenmaier at sap.com  Fri Jul 13 05:43:04 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 13 Jul 2018 05:43:04 +0000
Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
 include module and class loader information
In-Reply-To: <762ca092-81c2-2557-7710-9e3cde2c005a@oracle.com>
References: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
 <a26721cf429949dd947350c07695e9cc@sap.com>
 <762ca092-81c2-2557-7710-9e3cde2c005a@oracle.com>
Message-ID: <b0ce34b760b74a5ca5f711e22d3d80fa@sap.com>

Hi Lois, 

Looks good, thanks for all the changes!

Best regards,
  Goetz.

> -----Original Message-----
> From: Lois Foltan <lois.foltan at oracle.com>
> Sent: Thursday, July 12, 2018 9:10 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
> developers <hotspot-dev at openjdk.java.net>
> Subject: Re: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors
> to include module and class loader information
> 
> On 7/12/2018 11:03 AM, Lindenmaier, Goetz wrote:
> 
> > Hi Lois,
> >
> > I had a look at your change. It's a much better format bearing the
> > same information. Thus looks good to me.
> >
> > I would appreciate if you change printing the messages in linkResolver.cpp
> and
> > klassVtable.cpp to use stringStream, similar to linkResolver.cpp:1020
> > and other places (I should have changed that in first place when
> > I extended these messages before).
> >
> > systemDictionary.cpp
> >    I think it's convention to have a space after the comma:
> >    existing_klass->class_in_module_of_loader(false,true));
> >   This is in several places.
> 
> Thanks Goetz!? All you comments have been addressed.? See new webrev at
> 
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611.1/webrev/
> 
> Lois
> >
> > Best regards,
> >    Goetz.
> >
> >
> >
> >> -----Original Message-----
> >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> >> Behalf Of Lois Foltan
> >> Sent: Mittwoch, 27. Juni 2018 15:20
> >> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> >> Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors
> to
> >> include module and class loader information
> >>
> >> Please review this change to migrate existing loader constraint
> >> LinkageErrors to the new error message format proposal.? The actual
> >> wording of the loader constraint messages has not changed.? Module and
> >> class loader information have been moved into the error message's
> REASON
> >> section.? This change also removes the method
> >> java_lang_ClassLoader::describe_external() in favor of
> >> Klass::class_in_module_of_loader().
> >>
> >> open webrev at
> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611/webrev/
> >> bug link https://bugs.openjdk.java.net/browse/JDK-8205611
> >>
> >> JDK-8166633 outlines a new proposal where error messages follow a
> format
> >> of ERRROR: PROBLEM (REASON) where the PROBLEM is aggressively
> simple
> >> (and definitely avoids arbitrary-length loader names) so the REASON
> >> bears all the cost of explaining the PROBLEM with more specifics.? See
> >> the proposal in more detail at
> >> https://bugs.openjdk.java.net/browse/JDK-8166633. The new utility
> method
> >> Klass::class_in_module_of_loader() implements the proposed format.
> >>
> >> Some example text:
> >>
> >> (JDK 11) 'DuplicateLE_Test_Loader_IF' @<id> (instance of
> >> PreemptingClassLoader, child of 'app'
> >> jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate
> >> interface definition for test.J.
> >> to
> >> (JDK 12) loader 'DuplicateLE_Test_Loader_IF' @6eeee674 attempted
> >> duplicate interface definition for test.J. (test.J is in unnamed module
> >> of loader 'DuplicateLE_Test_Loader_IF' @6eeee674, parent loader 'app')
> >>
> >>
> >> (JDK 11) loader constraint violation: loader PreemptingClassLoader @<id>
> >> (instance of PreemptingClassLoader, child of 'app'
> >> jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load class
> >> test.D_ambgs. A different class with the same name was previously
> loaded
> >> by 'app' (instance of jdk.internal.loader.ClassLoaders$AppClassLoader).
> >> to
> >> (JDK 12) loader constraint violation: loader PreemptingClassLoader
> >> @5bc79a1c wants to load class test.D_ambgs. A different class with the
> >> same name was previously loaded by 'app'. (test.D_ambgs is in unnamed
> >> module of loader 'app')
> >>
> >>
> >> (JDK 11) loader constraint violation for class test.Task: when selecting
> >> overriding method test.Task.m()Ltest/Foo; the class loader
> >> PreemptingClassLoader @<id> (instance of PreemptingClassLoader, child
> of
> >> 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) of the selected
> >> method's type test.Task, and the class loader 'app' (instance of
> >> jdk.internal.loader.ClassLoaders$AppClassLoader) for its super type
> >> test.J have different Class objects for the type test.Foo used in the
> >> signature
> >> to
> >> (JDK 12) loader constraint violation for class test.Task: when selecting
> >> overriding method test.Task.m()Ltest/Foo; the class loader
> >> PreemptingClassLoader @7884e077 of the selected method's type
> test.Task,
> >> and the class loader 'app' for its super type test.J have different
> >> Class objects for the type test.Foo used in the signature (test.Task is
> >> in unnamed module of loader PreemptingClassLoader @7884e077, parent
> >> loader 'app'; test.J is in unnamed module of loader 'app')
> >>
> >>
> >> Testing: hs-tier(1-3), jdk-tier(1-3) complete
> >>   ?????????????? hs-tier(4,5) in progress
> >>   ?????????????? JCK vm, lang in progress
> >>
> >> Thanks,
> >> Lois


From boris.ulasevich at bell-sw.com  Fri Jul 13 10:36:46 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Fri, 13 Jul 2018 13:36:46 +0300
Subject: [11] RFR (XS) 8207047: Multiple VM variants build fail
In-Reply-To: <5d361d36-fe74-9455-e393-083a9a3ae328@oracle.com>
References: <c77ea2d7-2612-7b0f-8dc2-6f981a8e709c@bell-sw.com>
 <8ea633f50e9b91c773464b91a7ee5ec9f1775d64.camel@redhat.com>
 <5d361d36-fe74-9455-e393-083a9a3ae328@oracle.com>
Message-ID: <9b72dbcb-74e7-1556-fbd2-0732065f35b2@bell-sw.com>

Ok. Thank you.
Erik, can I ask you to sponsor the fix please?

regards,
Boris

On 12.07.2018 17:09, Erik Joelsson wrote:
> Looks good.
> 
> I thought I had fixed this, but now realize it was part of a change that 
> is currently on hold and I never got around to extracting this 
> particular fix as a separate fix.
> 
> Thanks for fixing it!
> 
> /Erik
> 
> 
> On 2018-07-12 02:32, Severin Gehwolf wrote:
>> Adding build-dev as this is a build change.
>>
>> On Thu, 2018-07-12 at 12:12 +0300, Boris Ulasevich wrote:
>>> Hi all,
>>>
>>> Please review a simple patch:
>>> http://cr.openjdk.java.net/~bulasevich/8207047/webrev.00
>>> https://bugs.openjdk.java.net/browse/JDK-8207047
>>>
>>> Collision happens on JFR gensrc tool when make system runs several VM
>>> configuration's gensrc concurrently. Let us move JFR gensrc tools files
>>> from shared output to the JVM_VARIANT output folder.
>>>
>>> thanks,
>>> Boris
> 

From erik.joelsson at oracle.com  Fri Jul 13 13:57:57 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 13 Jul 2018 06:57:57 -0700
Subject: [11] RFR (XS) 8207047: Multiple VM variants build fail
In-Reply-To: <9b72dbcb-74e7-1556-fbd2-0732065f35b2@bell-sw.com>
References: <c77ea2d7-2612-7b0f-8dc2-6f981a8e709c@bell-sw.com>
 <8ea633f50e9b91c773464b91a7ee5ec9f1775d64.camel@redhat.com>
 <5d361d36-fe74-9455-e393-083a9a3ae328@oracle.com>
 <9b72dbcb-74e7-1556-fbd2-0732065f35b2@bell-sw.com>
Message-ID: <bbdfaf16-7336-b15a-6db2-6518d03ff816@oracle.com>

Sure, will do.

/Erik


On 2018-07-13 03:36, Boris Ulasevich wrote:
> Ok. Thank you.
> Erik, can I ask you to sponsor the fix please?
>
> regards,
> Boris
>
> On 12.07.2018 17:09, Erik Joelsson wrote:
>> Looks good.
>>
>> I thought I had fixed this, but now realize it was part of a change 
>> that is currently on hold and I never got around to extracting this 
>> particular fix as a separate fix.
>>
>> Thanks for fixing it!
>>
>> /Erik
>>
>>
>> On 2018-07-12 02:32, Severin Gehwolf wrote:
>>> Adding build-dev as this is a build change.
>>>
>>> On Thu, 2018-07-12 at 12:12 +0300, Boris Ulasevich wrote:
>>>> Hi all,
>>>>
>>>> Please review a simple patch:
>>>> http://cr.openjdk.java.net/~bulasevich/8207047/webrev.00
>>>> https://bugs.openjdk.java.net/browse/JDK-8207047
>>>>
>>>> Collision happens on JFR gensrc tool when make system runs several VM
>>>> configuration's gensrc concurrently. Let us move JFR gensrc tools 
>>>> files
>>>> from shared output to the JVM_VARIANT output folder.
>>>>
>>>> thanks,
>>>> Boris
>>


From shade at redhat.com  Fri Jul 13 17:01:47 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 13 Jul 2018 19:01:47 +0200
Subject: [aarch64-port-dev ] [11] RFR (XS): 8207240: AARCH64 C2-only VM
 does not build
In-Reply-To: <79cfb1c0-7120-058b-452d-a6d4cca3c267@bell-sw.com>
References: <79cfb1c0-7120-058b-452d-a6d4cca3c267@bell-sw.com>
Message-ID: <587bf388-43dc-2a99-108b-85e7d8da07b9@redhat.com>

On 07/13/2018 05:28 PM, Aleksei Voitylov wrote:
> Hi,
> 
> please review this low risk fix that re-enables C2-only VM build for AARCH64.
> 
> webrev: http://cr.openjdk.java.net/~dchuyko/aleksei.voitylov/8207240/webrev.00

Looks good to me, it is the same thing other arches have.

> OK for 11?

I think so: JDK-8207240 is P3, so is acceptable in RDP1.

-Aleksey


From lois.foltan at oracle.com  Fri Jul 13 17:09:56 2018
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 13 Jul 2018 13:09:56 -0400
Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
 include module and class loader information
In-Reply-To: <da4ab3d9-32a5-3dc2-7364-84800c95d33e@oracle.com>
References: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
 <a26721cf429949dd947350c07695e9cc@sap.com>
 <762ca092-81c2-2557-7710-9e3cde2c005a@oracle.com>
 <da4ab3d9-32a5-3dc2-7364-84800c95d33e@oracle.com>
Message-ID: <1148f335-8941-6b01-e209-f77fb8b6c013@oracle.com>

Thanks Coleen!
Lois

On 7/12/2018 4:35 PM, coleen.phillimore at oracle.com wrote:
>
> This change looks really good!? The new error format in linkResolver 
> and klassVtable is nice.
> Thank you all for the work to agree on a format!
> Coleen
>
>
> On 7/12/18 3:10 PM, Lois Foltan wrote:
>> On 7/12/2018 11:03 AM, Lindenmaier, Goetz wrote:
>>
>>> Hi Lois,
>>>
>>> I had a look at your change. It's a much better format bearing the
>>> same information. Thus looks good to me.
>>>
>>> I would appreciate if you change printing the messages in 
>>> linkResolver.cpp and
>>> klassVtable.cpp to use stringStream, similar to linkResolver.cpp:1020
>>> and other places (I should have changed that in first place when
>>> I extended these messages before).
>>>
>>> systemDictionary.cpp
>>> ?? I think it's convention to have a space after the comma:
>>> ?? existing_klass->class_in_module_of_loader(false,true));
>>> ? This is in several places.
>>
>> Thanks Goetz!? All you comments have been addressed.? See new webrev at
>>
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611.1/webrev/
>>
>> Lois
>>>
>>> Best regards,
>>> ?? Goetz.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>>>> Behalf Of Lois Foltan
>>>> Sent: Mittwoch, 27. Juni 2018 15:20
>>>> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
>>>> Subject: [12] RFR (M) JDK-8205611: Improve the wording of 
>>>> LinkageErrors to
>>>> include module and class loader information
>>>>
>>>> Please review this change to migrate existing loader constraint
>>>> LinkageErrors to the new error message format proposal.? The actual
>>>> wording of the loader constraint messages has not changed. Module and
>>>> class loader information have been moved into the error message's 
>>>> REASON
>>>> section.? This change also removes the method
>>>> java_lang_ClassLoader::describe_external() in favor of
>>>> Klass::class_in_module_of_loader().
>>>>
>>>> open webrev at
>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611/webrev/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8205611
>>>>
>>>> JDK-8166633 outlines a new proposal where error messages follow a 
>>>> format
>>>> of ERRROR: PROBLEM (REASON) where the PROBLEM is aggressively simple
>>>> (and definitely avoids arbitrary-length loader names) so the REASON
>>>> bears all the cost of explaining the PROBLEM with more specifics.? See
>>>> the proposal in more detail at
>>>> https://bugs.openjdk.java.net/browse/JDK-8166633. The new utility 
>>>> method
>>>> Klass::class_in_module_of_loader() implements the proposed format.
>>>>
>>>> Some example text:
>>>>
>>>> (JDK 11) 'DuplicateLE_Test_Loader_IF' @<id> (instance of
>>>> PreemptingClassLoader, child of 'app'
>>>> jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate
>>>> interface definition for test.J.
>>>> to
>>>> (JDK 12) loader 'DuplicateLE_Test_Loader_IF' @6eeee674 attempted
>>>> duplicate interface definition for test.J. (test.J is in unnamed 
>>>> module
>>>> of loader 'DuplicateLE_Test_Loader_IF' @6eeee674, parent loader 'app')
>>>>
>>>>
>>>> (JDK 11) loader constraint violation: loader PreemptingClassLoader 
>>>> @<id>
>>>> (instance of PreemptingClassLoader, child of 'app'
>>>> jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load class
>>>> test.D_ambgs. A different class with the same name was previously 
>>>> loaded
>>>> by 'app' (instance of 
>>>> jdk.internal.loader.ClassLoaders$AppClassLoader).
>>>> to
>>>> (JDK 12) loader constraint violation: loader PreemptingClassLoader
>>>> @5bc79a1c wants to load class test.D_ambgs. A different class with the
>>>> same name was previously loaded by 'app'. (test.D_ambgs is in unnamed
>>>> module of loader 'app')
>>>>
>>>>
>>>> (JDK 11) loader constraint violation for class test.Task: when 
>>>> selecting
>>>> overriding method test.Task.m()Ltest/Foo; the class loader
>>>> PreemptingClassLoader @<id> (instance of PreemptingClassLoader, 
>>>> child of
>>>> 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) of the selected
>>>> method's type test.Task, and the class loader 'app' (instance of
>>>> jdk.internal.loader.ClassLoaders$AppClassLoader) for its super type
>>>> test.J have different Class objects for the type test.Foo used in the
>>>> signature
>>>> to
>>>> (JDK 12) loader constraint violation for class test.Task: when 
>>>> selecting
>>>> overriding method test.Task.m()Ltest/Foo; the class loader
>>>> PreemptingClassLoader @7884e077 of the selected method's type 
>>>> test.Task,
>>>> and the class loader 'app' for its super type test.J have different
>>>> Class objects for the type test.Foo used in the signature 
>>>> (test.Task is
>>>> in unnamed module of loader PreemptingClassLoader @7884e077, parent
>>>> loader 'app'; test.J is in unnamed module of loader 'app')
>>>>
>>>>
>>>> Testing: hs-tier(1-3), jdk-tier(1-3) complete
>>>> ? ?????????????? hs-tier(4,5) in progress
>>>> ? ?????????????? JCK vm, lang in progress
>>>>
>>>> Thanks,
>>>> Lois
>>
>


From lois.foltan at oracle.com  Fri Jul 13 17:10:30 2018
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 13 Jul 2018 13:10:30 -0400
Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors to
 include module and class loader information
In-Reply-To: <b0ce34b760b74a5ca5f711e22d3d80fa@sap.com>
References: <3e39812a-2f18-8dad-55df-92c7e28aac45@oracle.com>
 <a26721cf429949dd947350c07695e9cc@sap.com>
 <762ca092-81c2-2557-7710-9e3cde2c005a@oracle.com>
 <b0ce34b760b74a5ca5f711e22d3d80fa@sap.com>
Message-ID: <8627d908-1dd4-3bbe-46cc-f26960c2ad4d@oracle.com>

Thanks Goetz for the review!
Lois

On 7/13/2018 1:43 AM, Lindenmaier, Goetz wrote:
> Hi Lois,
>
> Looks good, thanks for all the changes!
>
> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: Lois Foltan <lois.foltan at oracle.com>
>> Sent: Thursday, July 12, 2018 9:10 PM
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
>> developers <hotspot-dev at openjdk.java.net>
>> Subject: Re: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors
>> to include module and class loader information
>>
>> On 7/12/2018 11:03 AM, Lindenmaier, Goetz wrote:
>>
>>> Hi Lois,
>>>
>>> I had a look at your change. It's a much better format bearing the
>>> same information. Thus looks good to me.
>>>
>>> I would appreciate if you change printing the messages in linkResolver.cpp
>> and
>>> klassVtable.cpp to use stringStream, similar to linkResolver.cpp:1020
>>> and other places (I should have changed that in first place when
>>> I extended these messages before).
>>>
>>> systemDictionary.cpp
>>>     I think it's convention to have a space after the comma:
>>>     existing_klass->class_in_module_of_loader(false,true));
>>>    This is in several places.
>> Thanks Goetz!? All you comments have been addressed.? See new webrev at
>>
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611.1/webrev/
>>
>> Lois
>>> Best regards,
>>>     Goetz.
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>>>> Behalf Of Lois Foltan
>>>> Sent: Mittwoch, 27. Juni 2018 15:20
>>>> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
>>>> Subject: [12] RFR (M) JDK-8205611: Improve the wording of LinkageErrors
>> to
>>>> include module and class loader information
>>>>
>>>> Please review this change to migrate existing loader constraint
>>>> LinkageErrors to the new error message format proposal.? The actual
>>>> wording of the loader constraint messages has not changed.? Module and
>>>> class loader information have been moved into the error message's
>> REASON
>>>> section.? This change also removes the method
>>>> java_lang_ClassLoader::describe_external() in favor of
>>>> Klass::class_in_module_of_loader().
>>>>
>>>> open webrev at
>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8205611/webrev/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8205611
>>>>
>>>> JDK-8166633 outlines a new proposal where error messages follow a
>> format
>>>> of ERRROR: PROBLEM (REASON) where the PROBLEM is aggressively
>> simple
>>>> (and definitely avoids arbitrary-length loader names) so the REASON
>>>> bears all the cost of explaining the PROBLEM with more specifics.? See
>>>> the proposal in more detail at
>>>> https://bugs.openjdk.java.net/browse/JDK-8166633. The new utility
>> method
>>>> Klass::class_in_module_of_loader() implements the proposed format.
>>>>
>>>> Some example text:
>>>>
>>>> (JDK 11) 'DuplicateLE_Test_Loader_IF' @<id> (instance of
>>>> PreemptingClassLoader, child of 'app'
>>>> jdk.internal.loader.ClassLoaders$AppClassLoader) attempted duplicate
>>>> interface definition for test.J.
>>>> to
>>>> (JDK 12) loader 'DuplicateLE_Test_Loader_IF' @6eeee674 attempted
>>>> duplicate interface definition for test.J. (test.J is in unnamed module
>>>> of loader 'DuplicateLE_Test_Loader_IF' @6eeee674, parent loader 'app')
>>>>
>>>>
>>>> (JDK 11) loader constraint violation: loader PreemptingClassLoader @<id>
>>>> (instance of PreemptingClassLoader, child of 'app'
>>>> jdk.internal.loader.ClassLoaders$AppClassLoader) wants to load class
>>>> test.D_ambgs. A different class with the same name was previously
>> loaded
>>>> by 'app' (instance of jdk.internal.loader.ClassLoaders$AppClassLoader).
>>>> to
>>>> (JDK 12) loader constraint violation: loader PreemptingClassLoader
>>>> @5bc79a1c wants to load class test.D_ambgs. A different class with the
>>>> same name was previously loaded by 'app'. (test.D_ambgs is in unnamed
>>>> module of loader 'app')
>>>>
>>>>
>>>> (JDK 11) loader constraint violation for class test.Task: when selecting
>>>> overriding method test.Task.m()Ltest/Foo; the class loader
>>>> PreemptingClassLoader @<id> (instance of PreemptingClassLoader, child
>> of
>>>> 'app' jdk.internal.loader.ClassLoaders$AppClassLoader) of the selected
>>>> method's type test.Task, and the class loader 'app' (instance of
>>>> jdk.internal.loader.ClassLoaders$AppClassLoader) for its super type
>>>> test.J have different Class objects for the type test.Foo used in the
>>>> signature
>>>> to
>>>> (JDK 12) loader constraint violation for class test.Task: when selecting
>>>> overriding method test.Task.m()Ltest/Foo; the class loader
>>>> PreemptingClassLoader @7884e077 of the selected method's type
>> test.Task,
>>>> and the class loader 'app' for its super type test.J have different
>>>> Class objects for the type test.Foo used in the signature (test.Task is
>>>> in unnamed module of loader PreemptingClassLoader @7884e077, parent
>>>> loader 'app'; test.J is in unnamed module of loader 'app')
>>>>
>>>>
>>>> Testing: hs-tier(1-3), jdk-tier(1-3) complete
>>>>    ?????????????? hs-tier(4,5) in progress
>>>>    ?????????????? JCK vm, lang in progress
>>>>
>>>> Thanks,
>>>> Lois


From kevin.walls at oracle.com  Fri Jul 13 19:12:22 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 13 Jul 2018 20:12:22 +0100
Subject: [8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function Causes
 C2084 Already Defined Compilation Error
Message-ID: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com>

Hi,

I'd like to request a review of a backport from 11 to 8u:

8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already 
Defined Compilation Error
JBS: https://bugs.openjdk.java.net/browse/JDK-8196882

11 changeset:
http://hg.openjdk.java.net/jdk/hs/rev/eebf559c9e0d

11 review thread:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030252.html
...to...
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030279.html


8u webrev: http://cr.openjdk.java.net/~kevinw/8196882/webrev.00/


 From VS2015, vsnprintf is provided, and is C99 conforming.? This is 
new, and
conflicts with the hotspot-provided definition.? 8196882 introduces 
os::vsnprintf()
so we can choose what we call in there.

We don't necessarily want to change behaviour in jdk8u, so we call 
_vsnprintf()
on Windows to get the old behaviour.

I didn't plan to move everything to a C99 behaviour here for jdk8u as we 
did in jdk11.
We just want to solve the symbol clash, so outputStream::do_vsnprintf() 
does
not need to change as it does in 11.

In jvm.cpp, the change in jdk11 changes jio_vsnprintf behaviour, but we 
wouldn't
normally choose to change the behaviour at this point in 8u.

(But ensuring the buffer is null-terminated looks like a positive change.)

The original has GTests, here in 8u it's a debug-mode test at runtime.? 
I have edited some of the
asserts in check_snprintf_result() as not changing jio_vsnprintf.

I've been building and testing with VS2017 and the current default 
compiler VS2010,
plus the other platforms.

Many thanks!
Kevin


From gnu.andrew at redhat.com  Sun Jul 15 02:11:52 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sun, 15 Jul 2018 03:11:52 +0100
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally
 when no debuginfo is stripped
In-Reply-To: <59dc6ee9d7d77991b72e480c1d62797050425959.camel@redhat.com>
References: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
 <8982397a-6165-3471-e15f-5dc3694027d7@oracle.com>
 <59dc6ee9d7d77991b72e480c1d62797050425959.camel@redhat.com>
Message-ID: <CABi63P5WwDuT9Ww7nTnr=icuCu=HCXAHTNBCBKDEJtpgART_Dg@mail.gmail.com>

On 6 July 2018 at 09:26, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> Hi David,
>
> On Fri, 2018-07-06 at 11:53 +1000, David Holmes wrote:
>> Hi Severin,
>>
>> On 6/07/2018 2:41 AM, Severin Gehwolf wrote:
>> > Hi,
>> >
>> > Please review this 8u-only change. JDK 10+ are not affected.
>> >
>> > For JDK 8 builds which don't perform any debug info stripping no
>> > .gnu_debuglink sections should get generated. The fix is to move the
>> > objcopy --add-gnu-debuglink calls into branches which actually perform
>> > some stripping: all_strip, min_strip. Thoughts?
>>
>> Has anything changed with the tools here? This has been in place since
>> back in 2011 with 7u2 and 8 GA! Why has it only become an issue now?
>
> I'm doubtful anything has changed with the tools. This is one of those
> patches which we seem to have been carrying downstream for a very long
> time. My archeology seems to suggest it started to show up in Fedora 23
> in November 2016. If anything, we'd be to blame to not push this fix
> upstream earlier.

The issue of 'no_strip' not being respected is a lot older than that
and has been
discussed on these lists at length before (e.g. [0] [1] [2]). The
impression I got
back that was that change was not wanted upstream and we should hack around
the defaults with various environment variables.

This fix only seems to make things more confusing. The .gnu_debuglink section
is now only created when STRIP_POLICY is 'all_strip' or 'min_strip', but the
debuginfo file is created for any value of STRIP_POLICY. The result is that
other values of STRIP_POLICY will create a debuginfo file that is not linked
to the original object. That seems like a regression from what happened
previously.

defs.make refers to a 'no_strip' value for STRIP_POLICY, but it is never
checked for elsewhere in the build, as far as I can see. I feel that the clearer
logic in these files would be:

  ifneq ($(STRIP_POLICY),no_strip)
    $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJVM_DEBUGINFO)
    $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJVM_DEBUGINFO) $@
  endif

as I first suggested in 2012 [3] and this is how we fixed it in
IcedTea years ago.

[0] http://mail.openjdk.java.net/pipermail/build-dev/2012-September/006680.html
[1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-March/003186.html
[2] http://mail.openjdk.java.net/pipermail/build-dev/2014-February/012019.html
[3] http://mail.openjdk.java.net/pipermail/build-dev/2012-September/006695.html
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From aph at redhat.com  Mon Jul 16 09:21:34 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Jul 2018 10:21:34 +0100
Subject: [8u] [RFR] Request for Review of Backport of JDK-8197429:
 Increased stack guard causes segfaults on x86-32
In-Reply-To: <CABi63P6YM0upX3aeL28Nby6FJbOhKJqZUQNY2_GP6AO0vQaB5A@mail.gmail.com>
References: <CABi63P6YM0upX3aeL28Nby6FJbOhKJqZUQNY2_GP6AO0vQaB5A@mail.gmail.com>
Message-ID: <c424faca-8580-131b-541f-7216d34798b8@redhat.com>

On 07/09/2018 04:55 PM, Andrew Hughes wrote:
> The code patch is largely the same, with the only
> difference that 8 still uses StackYellowPages
> and StackRedPages rather than the
> JavaThread::stack_red_zone_size() and
> JavaThread::stack_yellow_zone_size() functions.
> 
> The test differs in that the 8u version needs to
> also compile the C code within the test.
> I based this on test/runtime/InitialThreadOverflow.

Looks right to me.  I hope it looks right to the official 8u maintainers
too.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From adam.farley at uk.ibm.com  Mon Jul 16 16:03:31 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Mon, 16 Jul 2018 17:03:31 +0100
Subject: RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for
 Direct Byte Buffers
In-Reply-To: <9c1af95d-2c0f-b96d-76a7-5b40228996de@redhat.com>
References: <OFBC00C772.C902BD9F-ON002582A3.004ACE0A-802582A3.004BA343@notes.na.collabserv.com>
 <CAA-vtUwsM7bzWSQe0H=J6BH4uS9oQbsjZNcMBOBqON+0y0qUJQ@mail.gmail.com>
 <9c1af95d-2c0f-b96d-76a7-5b40228996de@redhat.com>
Message-ID: <OF35DB51E5.930B904A-ON002582C8.0057A794-802582CC.005836DA@notes.na.collabserv.com>

Hi Folks,

> Zhengyu Gu <zgu at redhat.com> wrote on 06/06/2018 01:58:18:

> From: Zhengyu Gu <zgu at redhat.com>
> To: "Thomas St?fe" <thomas.stuefe at gmail.com>, Adam Farley8 
> <adam.farley at uk.ibm.com>
> Cc: "hotspot-dev at openjdk.java.net developers" <hotspot-
> dev at openjdk.java.net>, core-libs-dev <core-libs-dev at openjdk.java.net>
> Date: 06/06/2018 01:58
> Subject: Re: RFR Bug-pending: Enable Hotspot to Track Native Memory 
> Usage for Direct Byte Buffers
> 
> On 06/05/2018 12:10 PM, Thomas St?fe wrote:> On Tue, Jun 5, 2018 at 3:46 

> PM, Adam Farley8 <adam.farley at uk.ibm.com> wrote:
> >> Hi All,
> >>
> >> Native memory allocation for DBBs is tracked in java.nio.Bits, but 
that
> >> only includes what the user thinks they are allocating.
> >>
> > 
> > Which is exactly what I would expect as a user...

A debugger poring over the values in the file may prefer total accuracy in 
at
least one of the variables, so they can find out where all their memory
went in the event of a leak. Even if this variable is not accessible via
a getter method, and is only readable via a system core.

> > 
> 
> I agree with Thomas, there is no point for a user to aware of tracking 
> overhead, and the overhead only incurs when native memory tracking is 
> on. As a matter of fact, it can really confuse user that values can be 
> varied, depending on whether native memory tracking is on.
> 
> Thanks,
> 
> -Zhengyu

I agree that the casual user shouldn't have to worry. This accuracy would 
be
for analysis after the fact, via system cores. The standard variables can 
stay 
as they are. I suggest the addition of a single AtomicLong that shows an
accurate value for the sole purpose of aiding debugging.

> 
> 
> >> When the VM adds extra memory to the allocation amount this extra bit 
is
> >> not represented in the Bits total. A cursory glance
> >> shows, minimum, that we round the requested memory quantity up to the 
heap
> >> word size in the Unsafe.allocateMemory code
> > 
> > which I do not understand either - why do we do this? After all,
> > normal allocations from inside hotspot do not get aligned up in size,
> > and the java doc to Unsafe allocateMemory does not state anything
> > about the size being aligned.
> > 
> > In addition to questioning the align up of the user requested size, I
> > would be in favor of adding a new NMT tag for these, maybe "mtUnsafe"?
> > That would be an easy fix.
> > 
> >> , and
> >> something to do with nmt_header_size in os:malloc() (os.cpp) too.
> > 
> > That is mighty unspecific and also wrong. The align-up mentioned above
> > goes into the size reported by Bits; the nmt header size does not.
> > 

I believe we agree here too. My point is that, for the sake of accuracy,
we *should* have this information in Bits. This is part of the 
debugger-aid 
change that I am suggesting.

> >>
> >> On its own, and in small quantities, align_up(sz, HeapWordSize) isn't 
that
> >> big of an issue. But when you allocate a lot of DBBs,
> >> and coupled with the nmt_header_size business, it makes the Bits 
values
> >> wrong. The more DBB allocations, the more inaccurate those
> >> numbers will be.
> > 
> > To be annoyingly precise, it will never be more wrong than 1:7 on
> > 64bit machines :) - if all memory requested via Unsafe.allocateMemory
> > would be of size 1 byte.

Sounds like the sort of thing I'd do. Once a stress tester, always a 
stress tester. :)

> > 
> >>
> >> To get the "+X", it seems to me that the best option would be to 
introduce
> >> an native method in Bits that fetches "X" directly
> >> from Hotspot, using the same code that Hotspot uses (so we'd have to
> >> abstract-out the Hotspot logic that adds X to the memory
> >> quantity). This way, anyone modifying the Hotspot logic won't risk
> >> rendering the Bits logic wrong again.
> > 
> > I don't follow that.

I was trying to describe one method to enable the VM to tell Bits how much
memory will actually be reserved for a given amount of DBB. E.g.
Bits says it has a DBB 7 bytes in size, and it tells the VM. The VM 
replies
with "OK, if you came to me and asked for 7 bytes, I'd reserve 8.", and 
then
Bits can update that debugging variable I mentioned.

If we abstract out the logic, then Bits and the VM would be using the 
exact 
same code when telling Bits how much memory will *hypothetically* be 
added,
as we do when the VM is determining how much overhead it needs when 
actually 
reserving the memory.

Is that clearer?

> > 
> >>
> >> That's only one way to fix the accuracy problem here though. 
Suggestions
> >> welcome.
> > 
> > You are throwing two effects together:
> > 
> > - As mentioned above, I consider the align-up of the user requested
> > size to be at least questionable. It shows up as user size in NMT
> > which should not be. I also fail to see a compelling reason for it,
> > but maybe someone else can enlighten me.

Well, if we got rid of it then that's one way to make the Bits variables
accurate. :)

> > 
> > - But anything else - NMT headers, overwriter guards, etc added by the
> > VM I consider in the same class as any other overhead incurred e.g. by
> > the CRT or the OS when calling malloc (e.g. malloc allocator bucket
> > size). Basically, rss will go up by more than size requested by
> > malloc. Something maybe worth noting, but IMHO not as part of the
> > numbers returned by java.nio.Bits.

We agree again. No need to confuse things by altering the return values. 
Simply store the accurate information internally as a debugging aid.

> > 
> > Just my 2 cents.

And they are appreciated. Apologies for the delay in my response.

- Adam

> > 
> > Best Regards, Thomas
> > 
> >>
> >> Best Regards
> >>
> >> Adam Farley
> >> Unless stated otherwise above:
> >> IBM United Kingdom Limited - Registered in England and Wales with 
number
> >> 741598.
> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU
> 

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From aleksei.voitylov at bell-sw.com  Fri Jul 13 15:28:24 2018
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Fri, 13 Jul 2018 18:28:24 +0300
Subject: [11] RFR (XS): 8207240: AARCH64 C2-only VM does not build
Message-ID: <79cfb1c0-7120-058b-452d-a6d4cca3c267@bell-sw.com>

Hi,

please review this low risk fix that re-enables C2-only VM build for 
AARCH64.

webrev: 
http://cr.openjdk.java.net/~dchuyko/aleksei.voitylov/8207240/webrev.00
bug: https://bugs.openjdk.java.net/browse/JDK-8207240

Testing: VM built this way passed jtreg hotspot tests in fastdebug mode.

OK for 11?

Thanks,

-Aleksei


From kim.barrett at oracle.com  Tue Jul 17 00:04:31 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 16 Jul 2018 20:04:31 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
Message-ID: <6E1C2079-FBD9-4165-9405-E9F277B72AC4@oracle.com>

> On Jul 10, 2018, at 4:18 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> Please review this change to the various os::readdir implementations
> for POSIX platforms to no longer use readdir_r, but instead use
> readdir.  [?]
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202353
> https://bugs.openjdk.java.net/browse/JDK-8202835
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
> 
> Testing:
> mach5 tier1-5.
> tier5 is where TestSystemProcess.java is run.
> There are a number of jfr tests in tier3-4 that use process iterators on
> relevant platforms.
> There are tests related to PerfCounters scattered through tier1-3.

Still looking for at least one more review.  I have one from Coleen, and a partial from Bernard.


From thomas.schatzl at oracle.com  Tue Jul 17 07:11:42 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 17 Jul 2018 09:11:42 +0200
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <6E1C2079-FBD9-4165-9405-E9F277B72AC4@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <6E1C2079-FBD9-4165-9405-E9F277B72AC4@oracle.com>
Message-ID: <cf44fc76ec65f7b10ee81318cac6fcbf76df4b17.camel@oracle.com>

Hi,

On Mon, 2018-07-16 at 20:04 -0400, Kim Barrett wrote:
> > On Jul 10, 2018, at 4:18 PM, Kim Barrett <kim.barrett at oracle.com>
> > wrote:
> > 
> > Please review this change to the various os::readdir
> > implementations
> > for POSIX platforms to no longer use readdir_r, but instead use
> > readdir.  [?]
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8202353
> > https://bugs.openjdk.java.net/browse/JDK-8202835
> > 
> > Webrev:
> > http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
> > 
> > Testing:
> > mach5 tier1-5.
> > tier5 is where TestSystemProcess.java is run.
> > There are a number of jfr tests in tier3-4 that use process
> > iterators on
> > relevant platforms.
> > There are tests related to PerfCounters scattered through tier1-3.
> 
> Still looking for at least one more review.  I have one from Coleen,
> and a partial from Bernard.
> 

  looks good.

Thomas

From aleksei.voitylov at bell-sw.com  Tue Jul 17 09:07:20 2018
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Tue, 17 Jul 2018 12:07:20 +0300
Subject: [aarch64-port-dev ] [11] RFR (XS): 8207240: AARCH64 C2-only VM
 does not build
In-Reply-To: <587bf388-43dc-2a99-108b-85e7d8da07b9@redhat.com>
References: <79cfb1c0-7120-058b-452d-a6d4cca3c267@bell-sw.com>
 <587bf388-43dc-2a99-108b-85e7d8da07b9@redhat.com>
Message-ID: <5cbada27-2f30-aec8-fb25-4faaa7a92e04@bell-sw.com>

Thank you for review!


On 13/07/2018 20:01, Aleksey Shipilev wrote:
> On 07/13/2018 05:28 PM, Aleksei Voitylov wrote:
>> Hi,
>>
>> please review this low risk fix that re-enables C2-only VM build for AARCH64.
>>
>> webrev: http://cr.openjdk.java.net/~dchuyko/aleksei.voitylov/8207240/webrev.00
> Looks good to me, it is the same thing other arches have.
>
>> OK for 11?
> I think so: JDK-8207240 is P3, so is acceptable in RDP1.
>
> -Aleksey
>


From sgehwolf at redhat.com  Tue Jul 17 13:57:19 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 17 Jul 2018 15:57:19 +0200
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added
 unconditionally when no debuginfo is stripped
In-Reply-To: <CABi63P5WwDuT9Ww7nTnr=icuCu=HCXAHTNBCBKDEJtpgART_Dg@mail.gmail.com>
References: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
 <8982397a-6165-3471-e15f-5dc3694027d7@oracle.com>
 <59dc6ee9d7d77991b72e480c1d62797050425959.camel@redhat.com>
 <CABi63P5WwDuT9Ww7nTnr=icuCu=HCXAHTNBCBKDEJtpgART_Dg@mail.gmail.com>
Message-ID: <09837b38b632b66342f0a07e4e6d4a4c316624ca.camel@redhat.com>

Hi Andrew,

On Sun, 2018-07-15 at 03:11 +0100, Andrew Hughes wrote:
> On 6 July 2018 at 09:26, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > Hi David,
> > 
> > On Fri, 2018-07-06 at 11:53 +1000, David Holmes wrote:
> > > Hi Severin,
> > > 
> > > On 6/07/2018 2:41 AM, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Please review this 8u-only change. JDK 10+ are not affected.
> > > > 
> > > > For JDK 8 builds which don't perform any debug info stripping no
> > > > .gnu_debuglink sections should get generated. The fix is to move the
> > > > objcopy --add-gnu-debuglink calls into branches which actually perform
> > > > some stripping: all_strip, min_strip. Thoughts?
> > > 
> > > Has anything changed with the tools here? This has been in place since
> > > back in 2011 with 7u2 and 8 GA! Why has it only become an issue now?
> > 
> > I'm doubtful anything has changed with the tools. This is one of those
> > patches which we seem to have been carrying downstream for a very long
> > time. My archeology seems to suggest it started to show up in Fedora 23
> > in November 2016. If anything, we'd be to blame to not push this fix
> > upstream earlier.
> 
> The issue of 'no_strip' not being respected is a lot older than that
> and has been
> discussed on these lists at length before (e.g. [0] [1] [2]). The
> impression I got
> back that was that change was not wanted upstream and we should hack around
> the defaults with various environment variables.
> 
> This fix only seems to make things more confusing. The .gnu_debuglink section
> is now only created when STRIP_POLICY is 'all_strip' or 'min_strip', but the
> debuginfo file is created for any value of STRIP_POLICY. The result is that
> other values of STRIP_POLICY will create a debuginfo file that is not linked
> to the original object. That seems like a regression from what happened
> previously.
> 
> defs.make refers to a 'no_strip' value for STRIP_POLICY, but it is never
> checked for elsewhere in the build, as far as I can see. I feel that the clearer
> logic in these files would be:
> 
>   ifneq ($(STRIP_POLICY),no_strip)
>     $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJVM_DEBUGINFO)
>     $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJVM_DEBUGINFO) $@
>   endif

I can fix this with https://bugs.openjdk.java.net/browse/JDK-8207402,
but if JDK-8207234 goes into JDK 8u, unknown values for STRIP_POLICY
should become less likely as users would be able to use --with-native-
debug-symbols=internal for that use-case. That would be in-line with
JDK 9+

Thanks,
Severin

> [0] http://mail.openjdk.java.net/pipermail/build-dev/2012-September/006680.html
> [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-March/003186.html
> [2] http://mail.openjdk.java.net/pipermail/build-dev/2014-February/012019.html
> [3] http://mail.openjdk.java.net/pipermail/build-dev/2012-September/006695.html

From kim.barrett at oracle.com  Tue Jul 17 16:04:13 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Jul 2018 12:04:13 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <cf44fc76ec65f7b10ee81318cac6fcbf76df4b17.camel@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <6E1C2079-FBD9-4165-9405-E9F277B72AC4@oracle.com>
 <cf44fc76ec65f7b10ee81318cac6fcbf76df4b17.camel@oracle.com>
Message-ID: <D72C8C1F-743C-42EF-843F-E13DF3B43592@oracle.com>

> On Jul 17, 2018, at 3:11 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> On Mon, 2018-07-16 at 20:04 -0400, Kim Barrett wrote:
>>> On Jul 10, 2018, at 4:18 PM, Kim Barrett <kim.barrett at oracle.com>
>>> wrote:
>>> 
>>> Please review this change to the various os::readdir
>>> implementations
>>> for POSIX platforms to no longer use readdir_r, but instead use
>>> readdir.  [?]
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8202353
>>> https://bugs.openjdk.java.net/browse/JDK-8202835
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
>>> 
>>> Testing:
>>> mach5 tier1-5.
>>> tier5 is where TestSystemProcess.java is run.
>>> There are a number of jfr tests in tier3-4 that use process
>>> iterators on
>>> relevant platforms.
>>> There are tests related to PerfCounters scattered through tier1-3.
>> 
>> Still looking for at least one more review.  I have one from Coleen,
>> and a partial from Bernard.
>> 
> 
>  looks good.
> 
> Thomas

Thanks, Thomas.


From bsrbnd at gmail.com  Tue Jul 17 16:11:40 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Tue, 17 Jul 2018 18:11:40 +0200
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <6E1C2079-FBD9-4165-9405-E9F277B72AC4@oracle.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <6E1C2079-FBD9-4165-9405-E9F277B72AC4@oracle.com>
Message-ID: <CAEgw74DJ3rbsuNYdvEGPs+Vp0O9NwNJ+m-GkxYfE7uY2sa8JTg@mail.gmail.com>

On 17 July 2018 at 02:04, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Jul 10, 2018, at 4:18 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>> Please review this change to the various os::readdir implementations
>> for POSIX platforms to no longer use readdir_r, but instead use
>> readdir.  [?]
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8202353
>> https://bugs.openjdk.java.net/browse/JDK-8202835
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
>>
>> Testing:
>> mach5 tier1-5.
>> tier5 is where TestSystemProcess.java is run.
>> There are a number of jfr tests in tier3-4 that use process iterators on
>> relevant platforms.
>> There are tests related to PerfCounters scattered through tier1-3.
>
> Still looking for at least one more review.  I have one from Coleen, and a partial from Bernard.

Similar changes on the other systems seem good to me too.

Thanks,
Bernard

From kim.barrett at oracle.com  Tue Jul 17 16:14:51 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Jul 2018 12:14:51 -0400
Subject: RFR: 8202353: os::readdir should use readdir instead of readdir_r
In-Reply-To: <CAEgw74DJ3rbsuNYdvEGPs+Vp0O9NwNJ+m-GkxYfE7uY2sa8JTg@mail.gmail.com>
References: <111F3AC5-C6AB-4BC0-B5E7-F58C8D95559E@oracle.com>
 <6E1C2079-FBD9-4165-9405-E9F277B72AC4@oracle.com>
 <CAEgw74DJ3rbsuNYdvEGPs+Vp0O9NwNJ+m-GkxYfE7uY2sa8JTg@mail.gmail.com>
Message-ID: <E1F0CC6C-6F81-4D03-B631-A9663005489E@oracle.com>

> On Jul 17, 2018, at 12:11 PM, B. Blaser <bsrbnd at gmail.com> wrote:
> 
> On 17 July 2018 at 02:04, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> On Jul 10, 2018, at 4:18 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> 
>>> Please review this change to the various os::readdir implementations
>>> for POSIX platforms to no longer use readdir_r, but instead use
>>> readdir.  [?]
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8202353
>>> https://bugs.openjdk.java.net/browse/JDK-8202835
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8202353/open.00/
>>> 
>>> Testing:
>>> mach5 tier1-5.
>>> tier5 is where TestSystemProcess.java is run.
>>> There are a number of jfr tests in tier3-4 that use process iterators on
>>> relevant platforms.
>>> There are tests related to PerfCounters scattered through tier1-3.
>> 
>> Still looking for at least one more review.  I have one from Coleen, and a partial from Bernard.
> 
> Similar changes on the other systems seem good to me too.
> 
> Thanks,
> Bernard

Thanks.


From boris.ulasevich at bell-sw.com  Wed Jul 18 10:25:51 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Wed, 18 Jul 2018 13:25:51 +0300
Subject: [11] RFR(XS): 8207584: ARM32: ShouldNotReachHere assertion on
 Test8168712 jtreg test
Message-ID: <750346d2-41da-533c-504e-22033bb1f798@bell-sw.com>

Hi all,

Please review a simple and low risk fix for ARM32 port:
https://bugs.openjdk.java.net/browse/JDK-8207584
http://cr.openjdk.java.net/~bulasevich/8207584/webrev.00

Testing: jtreg compiler tests in fastdebug mode.

thanks,
Boris

From shade at redhat.com  Wed Jul 18 10:32:40 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Jul 2018 12:32:40 +0200
Subject: [11] RFR(XS): 8207584: ARM32: ShouldNotReachHere assertion on
 Test8168712 jtreg test
In-Reply-To: <750346d2-41da-533c-504e-22033bb1f798@bell-sw.com>
References: <750346d2-41da-533c-504e-22033bb1f798@bell-sw.com>
Message-ID: <ce8fae5a-bfea-508d-4d81-213a6950d653@redhat.com>

On 07/18/2018 12:25 PM, Boris Ulasevich wrote:
> Hi all,
> 
> Please review a simple and low risk fix for ARM32 port:
> https://bugs.openjdk.java.net/browse/JDK-8207584
> http://cr.openjdk.java.net/~bulasevich/8207584/webrev.00

This looks good. I wonder if you want to put the same in #ifdef AARCH64 block just above, but that
is probably not an issue if that flavor of ARM64 port goes away.

-Aleksey



From boris.ulasevich at bell-sw.com  Wed Jul 18 11:49:08 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Wed, 18 Jul 2018 14:49:08 +0300
Subject: [11] RFR(XS): 8207584: ARM32: ShouldNotReachHere assertion on
 Test8168712 jtreg test
In-Reply-To: <ce8fae5a-bfea-508d-4d81-213a6950d653@redhat.com>
References: <750346d2-41da-533c-504e-22033bb1f798@bell-sw.com>
 <ce8fae5a-bfea-508d-4d81-213a6950d653@redhat.com>
Message-ID: <8cd7c360-ba61-834c-6c03-ae7e519ab5e9@bell-sw.com>

Yes, I think it is better not to change ARM64 part now.
Thank you for review.

Boris

18.07.2018 13:32, Aleksey Shipilev ?????:
> On 07/18/2018 12:25 PM, Boris Ulasevich wrote:
>> Hi all,
>>
>> Please review a simple and low risk fix for ARM32 port:
>> https://bugs.openjdk.java.net/browse/JDK-8207584
>> http://cr.openjdk.java.net/~bulasevich/8207584/webrev.00
> This looks good. I wonder if you want to put the same in #ifdef AARCH64 block just above, but that
> is probably not an issue if that flavor of ARM64 port goes away.
>
> -Aleksey

From dms at samersoff.net  Wed Jul 18 13:08:30 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Wed, 18 Jul 2018 16:08:30 +0300
Subject: [aarch64-port-dev ] [11] RFR (XS): 8207240: AARCH64 C2-only VM
 does not build
In-Reply-To: <79cfb1c0-7120-058b-452d-a6d4cca3c267@bell-sw.com>
References: <79cfb1c0-7120-058b-452d-a6d4cca3c267@bell-sw.com>
Message-ID: <65260091-1027-e191-1b3b-7e867abc7748@samersoff.net>

Aleksei,

Looks good to me.

-Dmitry

On 13.07.2018 18:28, Aleksei Voitylov wrote:
> Hi,
> 
> please review this low risk fix that re-enables C2-only VM build for
> AARCH64.
> 
> webrev:
> http://cr.openjdk.java.net/~dchuyko/aleksei.voitylov/8207240/webrev.00
> bug: https://bugs.openjdk.java.net/browse/JDK-8207240
> 
> Testing: VM built this way passed jtreg hotspot tests in fastdebug mode.
> 
> OK for 11?
> 
> Thanks,
> 
> -Aleksei
> 


-- 
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...


From gnu.andrew at redhat.com  Wed Jul 18 22:10:28 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 18 Jul 2018 23:10:28 +0100
Subject: [8u] RFR: 8206425: .gnu_debuglink sections added unconditionally
 when no debuginfo is stripped
In-Reply-To: <09837b38b632b66342f0a07e4e6d4a4c316624ca.camel@redhat.com>
References: <cb338c7bb57a5b35405998f81907aaffb623b294.camel@redhat.com>
 <8982397a-6165-3471-e15f-5dc3694027d7@oracle.com>
 <59dc6ee9d7d77991b72e480c1d62797050425959.camel@redhat.com>
 <CABi63P5WwDuT9Ww7nTnr=icuCu=HCXAHTNBCBKDEJtpgART_Dg@mail.gmail.com>
 <09837b38b632b66342f0a07e4e6d4a4c316624ca.camel@redhat.com>
Message-ID: <CABi63P4RK8ZnsjTD4Y2DuohzLCprkZ8OsuwyNbv0Lv=N=7cOeA@mail.gmail.com>

On 17 July 2018 at 14:57, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> Hi Andrew,
>
> On Sun, 2018-07-15 at 03:11 +0100, Andrew Hughes wrote:
>> On 6 July 2018 at 09:26, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>> > Hi David,
>> >
>> > On Fri, 2018-07-06 at 11:53 +1000, David Holmes wrote:
>> > > Hi Severin,
>> > >
>> > > On 6/07/2018 2:41 AM, Severin Gehwolf wrote:
>> > > > Hi,
>> > > >
>> > > > Please review this 8u-only change. JDK 10+ are not affected.
>> > > >
>> > > > For JDK 8 builds which don't perform any debug info stripping no
>> > > > .gnu_debuglink sections should get generated. The fix is to move the
>> > > > objcopy --add-gnu-debuglink calls into branches which actually perform
>> > > > some stripping: all_strip, min_strip. Thoughts?
>> > >
>> > > Has anything changed with the tools here? This has been in place since
>> > > back in 2011 with 7u2 and 8 GA! Why has it only become an issue now?
>> >
>> > I'm doubtful anything has changed with the tools. This is one of those
>> > patches which we seem to have been carrying downstream for a very long
>> > time. My archeology seems to suggest it started to show up in Fedora 23
>> > in November 2016. If anything, we'd be to blame to not push this fix
>> > upstream earlier.
>>
>> The issue of 'no_strip' not being respected is a lot older than that
>> and has been
>> discussed on these lists at length before (e.g. [0] [1] [2]). The
>> impression I got
>> back that was that change was not wanted upstream and we should hack around
>> the defaults with various environment variables.
>>
>> This fix only seems to make things more confusing. The .gnu_debuglink section
>> is now only created when STRIP_POLICY is 'all_strip' or 'min_strip', but the
>> debuginfo file is created for any value of STRIP_POLICY. The result is that
>> other values of STRIP_POLICY will create a debuginfo file that is not linked
>> to the original object. That seems like a regression from what happened
>> previously.
>>
>> defs.make refers to a 'no_strip' value for STRIP_POLICY, but it is never
>> checked for elsewhere in the build, as far as I can see. I feel that the clearer
>> logic in these files would be:
>>
>>   ifneq ($(STRIP_POLICY),no_strip)
>>     $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJVM_DEBUGINFO)
>>     $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJVM_DEBUGINFO) $@
>>   endif
>
> I can fix this with https://bugs.openjdk.java.net/browse/JDK-8207402,
> but if JDK-8207234 goes into JDK 8u, unknown values for STRIP_POLICY
> should become less likely as users would be able to use --with-native-
> debug-symbols=internal for that use-case. That would be in-line with
> JDK 9+
>
> Thanks,
> Severin
>
>> [0] http://mail.openjdk.java.net/pipermail/build-dev/2012-September/006680.html
>> [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-March/003186.html
>> [2] http://mail.openjdk.java.net/pipermail/build-dev/2014-February/012019.html
>> [3] http://mail.openjdk.java.net/pipermail/build-dev/2012-September/006695.html

I'm not too familiar with how it works in 9, but this sounds good. I'll look
over these changes.

My main point was to make clear that the reason we haven't fixed this already
is not for lack of trying!
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gromero at linux.vnet.ibm.com  Wed Jul 18 22:46:02 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 18 Jul 2018 19:46:02 -0300
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <CAN_ztC3O85mp5i6yGAjnVDDkseNERWHGzTLMjUEEwQddGjff3w@mail.gmail.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
 <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
 <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>
 <BL0PR07MB3890CD2AA56F084140125F75845B0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <DM5PR12MB1177DCF7A508FA7978B417A0F65A0@DM5PR12MB1177.namprd12.prod.outlook.com>
 <b4cf463e-f26e-1805-1392-4910b13a3260@linux.vnet.ibm.com>
 <CAN_ztC3O85mp5i6yGAjnVDDkseNERWHGzTLMjUEEwQddGjff3w@mail.gmail.com>
Message-ID: <2621c43f-545c-82a7-7dfb-49accbd55697@linux.vnet.ibm.com>

Hi Community,

In the light of the additional information brought by Derek and Swati on this
issue (which I summarized below) would it be possible to get a second assessment
for this issue regarding its priority? Would it be sound to qualify it as P3
instead of P4? I don't have experience on doing such an assessment so I ask.

- If the JVM isn't allowed to use memory on all of the numa nodes, for instance,
   by numactl, cgroups, and docker container, then a significant fraction of the
   JVM heap will be unusable, causing early GC;

- The waste can be up to (N-1)/N of the young generation in some cases, where N
   is the total number of nodes available on the system (unpinned); So on an EPYC
   machine with 8 numa nodes, for instance, waste can be up to 7/8 of total memory
   available on a given node;

- With the patch for this issue applied SPECjbb2015 on a EPYC machine (8 NUMA
   nodes) shows a significant performance improvement:

   Case 1: Performance for 1 NUMA node bound, MultiJVM 1 Group Run (numactl --cpunodebind=0 --membind=0)
     Max-jOPS      : +27.59%
     Critical-jOPS : +260% (As base memory without patch is 1/8 of total available memory, heap size impacts Critical-jOPS)

   Case 2: Performance for 2 NUMA nodes bound, Composite Run (numactl --cpunodebind=0,7 --membind=0,7)
     Max-jOPS      : +10.35%
     Critical-jOPS : +9.89%

- It affects AARCH64, PPC64, and Intel/AMD.


Thank you.


Best regards,
Gustavo

On 07/18/2018 03:32 AM, Swati Sharma wrote:
> Hi All,
> 
> Significant performance improvement with the patch we have observed for SPECJBB2015:
> 
> Tested the specjbb2015 with patch on EPYC( 8 NUMA nodes configuration )
> 
> Case 1 : Performance On 1 NUMA Node MultiJVM 1 Group Run (numactl --cpunodebind=0 --membind=0)
> 
>     Max-jOPS         Critical-jOPS
>    +27.59%             +260%                     (As base memory without patch is 1/8 of Total, heap size impacts Critical -jOPS)
> 
> Case 2 : Performance on 2 NUMA Nodes Composite Run (numactl --cpunodebind=0,7 --membind=0,7)
> 
>    Max-jOPS          Critical-jOPS
>     +10.35%             +9.89%
> 
> If more information is required for different configurations on EPYC, Please let me know.
> 
> Thanks,
> Swati Sharma
> Software Engineer -2 at AMD
> 
> On Thu, Jul 12, 2018 at 3:36 AM, Gustavo Romero <gromero at linux.vnet.ibm.com <mailto:gromero at linux.vnet.ibm.com>> wrote:
> 
>     Hi,
> 
>     I concur with Derek about the impact on the GC.
> 
>     I can't comment about the impact on the container context.
> 
>     I can try to take additional performance numbers on that, if that helps to
>     define the priority (is there any available?).
> 
>     Prakash, Swati,
> 
>     It's not necessary to stop improving the JVM NUMA support. jdk/jdk (JDK 12)
>     repository is open and the next changes can go there normally, i.e. even if
>     8189922 is not able to get into JDK 11 (jdk/jdk11), it can go into jdk/jdk and
>     so we move on. Also I don't think it's possible to get the additional changes
>     into JDK 11 anyway.
> 
>     On the other hand, since 11 is LTS, I _think_ that OpenJDK 11 LTS will be open
>     for updates after the GA and so it's possible to request the backports, as
>     Dalibor [1] says: "[After September 2018] Oracle plans to initiate and
>     contribute to the development JDK 11 Updates with this OpenJDK Project in due
>     course."
> 
> 
>     Best regards,
>     Gustavo
> 
>     [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-May/000128.html <http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-May/000128.html>
> 
> 
>     On 07/11/2018 01:46 AM, Raghavendra, Prakash wrote:
> 
>         Apart from the impact on EPYC (with large memory), we have also have identified a few fixes on top of this, which is waiting for this to go. The one which is very essential is the case when GC is triggered prematurely when one of the lgrps is full, the fix is to see if we can try and allocate on another closest (in terms of latencies) lgrps, instead.
> 
> 
>         Thanks
>         Regards
>         Prakash
> 
>         -----Original Message-----
>         From: White, Derek [mailto:Derek.White at cavium.com <mailto:Derek.White at cavium.com>]
>         Sent: Wednesday, July 11, 2018 5:25 AM
>         To: David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>>; Gustavo Romero <gromero at linux.vnet.ibm.com <mailto:gromero at linux.vnet.ibm.com>>; Swati Sharma <swatibits14 at gmail.com <mailto:swatibits14 at gmail.com>>; Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>
>         Cc: Vishwanath, Prasad <Prasad.Vishwanath at amd.com <mailto:Prasad.Vishwanath at amd.com>>; hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net>; Raghavendra, Prakash <Prakash.Raghavendra at amd.com <mailto:Prakash.Raghavendra at amd.com>>
>         Subject: RE: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs membind
> 
>         Hi David,
> 
>         [Gustavo and others, please correct me if I'm wrong].
> 
>         I think as far as impact goes, this may waste up to (N-1)/N of the young generation in some cases, where N is number of nodes. For example, on 2-socket Epyc, this could waste 7/8ths of the young gen. This has non-trivial impact on GC behavior ??
> 
>         This occurs when there's a mismatch between memory binding and JVM arguments (or rather can be avoided by carefully setting JVM arguments), and I could see this happening easily when using containers.
> 
>         - Derek
> 
>             -----Original Message-----
>             From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net <mailto:hotspot-dev-bounces at openjdk.java.net>] On
>             Behalf Of David Holmes
>             Sent: Tuesday, July 10, 2018 5:39 PM
>             To: Gustavo Romero <gromero at linux.vnet.ibm.com <mailto:gromero at linux.vnet.ibm.com>>; Swati Sharma
>             <swatibits14 at gmail.com <mailto:swatibits14 at gmail.com>>; Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>
>             Cc: Prasad.Vishwanath at amd.com <mailto:Prasad.Vishwanath at amd.com>; hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net>;
>             Prakash.Raghavendra at amd.com <mailto:Prakash.Raghavendra at amd.com>
>             Subject: Re: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory
>             interleaving vs membind
> 
>             External Email
> 
>             Hi Gustavo,
> 
>             On 11/07/2018 6:14 AM, Gustavo Romero wrote:
> 
>                 Hi Swati,
> 
>                 As David pointed out, it's necessary to determine if that bug
>                 qualifies as P3 in order to get it into JDK 11 RDP1.
> 
>                 AFAICS, that bug was never triaged explicitly and got its current
>                 priority (P4) from the default.
> 
> 
>             Actually no, the P4 was from the (Oracle internal) ILW prioritization scheme.
> 
>             For this to be a P3 it needs to be shown either that the impact is
>             quite significant (IIUC it's only a mild performance issue based on
>             the bug report); or that the likelihood of this being encountered is
>             very high (again it seems not that likely based on the info in the bug report).
> 
>             HTH.
> 
>             David
>             -----
> 
> 
> 
>                 Once it's defined the correct integration version, I can sponsor
>                 that change for you. I think there won't be any updates for JDK 11
>                 (contrary to what happened for JDK 10), but I think we can
>                 understand how distros are handling it and so find out if there is a
>                 possibility to get the change into the distros once it's pushed to JDK 12.
> 
> 
>                 David, Alan,
> 
>                 I could not find a documentation on how to formally triage a bug.
>                 For instance, on [1] I see Alan used some markers as "ILW =" and "MLH = "
>                 but I don't know if these markers are only for Oracle internal
>                 control. Do you know how could I triage that bug? I understand its
>                 risk of integration is small but even tho I think it's necessary to
>                 bring up additional information on that to combine in a final bug
>                 priority.
> 
>                 Thanks.
> 
> 
>                 Best regards,
>                 Gustavo
> 
>                 [1] https://bugs.openjdk.java.net/browse/JDK-8206953 <https://bugs.openjdk.java.net/browse/JDK-8206953>
> 
>                 On 07/03/2018 03:06 AM, David Holmes wrote:
> 
>                     Looks fine.
> 
>                     Thanks,
>                     David
> 
>                     On 3/07/2018 3:08 PM, Swati Sharma wrote:
> 
>                         Hi David,
> 
>                         I have added NULL check for _numa_bitmask_isbitset in
>                         isbound_to_single_node() method.
> 
>                         Hosted:http://cr.openjdk.java.net/~gromero/8189922/v2/ <http://cr.openjdk.java.net/~gromero/8189922/v2/>
>                         <http://cr.openjdk.java.net/~gromero/8189922/v2/ <http://cr.openjdk.java.net/~gromero/8189922/v2/>>
> 
>                         Swati
> 
>                         On Mon, Jul 2, 2018 at 5:54 AM, David Holmes
>                         <david.holmes at oracle.com <mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>> wrote:
> 
>                               Hi Swati,
> 
>                               I took a look at this though I'm not familiar with the functional
>                               operation of the NUMA API's - I'm relying on Gustavo and Derek to
>                               spot any actual usage errors there.
> 
>                               In isbound_to_single_node() there is no NULL check for
>                               _numa_bitmask_isbitset (which seems to be the normal pattern for
>                               using all of these function pointers).
> 
>                               Otherwise this seems fine.
> 
>                               Thanks,
>                               David
> 
> 
>                               On 30/06/2018 2:46 AM, Swati Sharma wrote:
> 
>                                      Hi,
> 
>                                   Could I get a review for this change that affects the JVM when
>                                   there are
>                                   pinned memory nodes please?
> 
>                                   It's already reviewed and tested on PPC64 and on AARCH64 by
>                                   Gustavo and
>                                   Derek, however both are not Reviewers so I need additional
>                                   reviews for that
>                                   change.
> 
> 
>                                   Thanks in advance.
> 
>                                   Swati
> 
>                                   On Tue, Jun 19, 2018 at 5:58 PM, Swati Sharma
>                                   <swatibits14 at gmail.com <mailto:swatibits14 at gmail.com> <mailto:swatibits14 at gmail.com <mailto:swatibits14 at gmail.com>>> wrote:
> 
>                                       Hi All,
> 
>                                       Here is the numa information of the system :
>                                       swati at java-diesel1:~$ numactl -H
>                                       available: 8 nodes (0-7)
>                                       node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
>                                       node 0 size: 64386 MB
>                                       node 0 free: 64134 MB
>                                       node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
>                                       node 1 size: 64509 MB
>                                       node 1 free: 64232 MB
>                                       node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
>                                       node 2 size: 64509 MB
>                                       node 2 free: 64215 MB
>                                       node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
>                                       node 3 size: 64509 MB
>                                       node 3 free: 64157 MB
>                                       node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100
>                         101
>                         102 103
>                                       node 4 size: 64509 MB
>                                       node 4 free: 64336 MB
>                                       node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109
>                                       110 111
>                                       node 5 size: 64509 MB
>                                       node 5 free: 64352 MB
>                                       node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117
>                                       118 119
>                                       node 6 size: 64509 MB
>                                       node 6 free: 64359 MB
>                                       node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125
>                                       126 127
>                                       node 7 size: 64508 MB
>                                       node 7 free: 64350 MB
>                                       node distances:
>                                       node   0   1   2   3   4   5   6   7
>                                           0:  10  16  16  16  32  32  32  32
>                                           1:  16  10  16  16  32  32  32  32
>                                           2:  16  16  10  16  32  32  32  32
>                                           3:  16  16  16  10  32  32  32  32
>                                           4:  32  32  32  32  10  16  16  16
>                                           5:  32  32  32  32  16  10  16  16
>                                           6:  32  32  32  32  16  16  10  16
>                                           7:  32  32  32  32  16  16  16  10
> 
>                                       Thanks,
>                                       Swati
> 
>                                       On Tue, Jun 19, 2018 at 12:00 AM, Gustavo Romero <
>                         gromero at linux.vnet.ibm.com <mailto:gromero at linux.vnet.ibm.com>
>                                       <mailto:gromero at linux.vnet.ibm.com <mailto:gromero at linux.vnet.ibm.com>>> wrote:
> 
>                                           Hi Swati,
> 
>                                           On 06/16/2018 02:52 PM, Swati Sharma wrote:
> 
>                                               Hi All,
> 
>                                               This is my first patch,I would appreciate if anyone
>                                               can review the fix:
> 
>                                               Bug :
>                         https://bugs.openjdk.java.net/browse/JDK-8189922 <https://bugs.openjdk.java.net/browse/JDK-8189922>
>                                               <https://bugs.openjdk.java.net/browse/JDK-8189922 <https://bugs.openjdk.java.net/browse/JDK-8189922>> <
>                         https://bugs.openjdk.java.net/browse/JDK-8189922 <https://bugs.openjdk.java.net/browse/JDK-8189922>
>                                               <https://bugs.openjdk.java.net/browse/JDK-8189922 <https://bugs.openjdk.java.net/browse/JDK-8189922>>>
>                                               Webrev
>                                               :http://cr.openjdk.java.net/~gromero/8189922/v1 <http://cr.openjdk.java.net/~gromero/8189922/v1>
>                                               <http://cr.openjdk.java.net/~gromero/8189922/v1 <http://cr.openjdk.java.net/~gromero/8189922/v1>>
> 
>                                               The bug is about JVM flag UseNUMA which bypasses the
>                                               user specified
>                                               numactl --membind option and divides the whole heap
>                                               in lgrps according to
>                                               available numa nodes.
> 
>                                               The proposed solution is to disable UseNUMA if bound
>                                               to single numa
>                                               node. In case more than one numa node binding,
>                                               create the lgrps according
>                                               to bound nodes.If there is no binding, then JVM will
>                                               divide the whole heap
>                                               based on the number of NUMA nodes available on the
>                                               system.
> 
>                                               I appreciate Gustavo's help for fixing the thread
>                                               allocation based on
>                                               numa distance for membind which was a dangling issue
>                                               associated with main
>                                               patch.
> 
> 
>                                           Thanks. I have no further comments on it. LGTM.
> 
> 
>                                           Best regards,
>                                           Gustavo
> 
>                                           PS: Please, provide numactl -H information when
>                                           possible. It helps to
>                                           grasp
>                                           promptly the actual NUMA topology in question :)
> 
>                                           Tested the fix by running specjbb2015 composite workload
>                                           on 8 NUMA node
> 
>                                               system.
>                                               Case 1 : Single NUMA node bind
>                                               numactl --cpunodebind=0 --membind=0 java -Xmx24g
>                                               -Xms24g -Xmn22g
>                                               -XX:+UseNUMA
>                                               -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>                                               <composite_application>
>                                               Before Patch: gc.log
>                                               eden space 22511616K(22GB), 12% used
>                                                      lgrp 0 space 2813952K, 100% used
>                                                      lgrp 1 space 2813952K, 0% used
>                                                      lgrp 2 space 2813952K, 0% used
>                                                      lgrp 3 space 2813952K, 0% used
>                                                      lgrp 4 space 2813952K, 0% used
>                                                      lgrp 5 space 2813952K, 0% used
>                                                      lgrp 6 space 2813952K, 0% used
>                                                      lgrp 7 space 2813952K, 0% used
>                                               After Patch : gc.log
>                                               eden space 46718976K(45GB), 99% used(NUMA
>                         disabled)
> 
>                                               Case 2 : Multiple NUMA node bind
>                                               numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g
>                                               -Xmx50g -Xmn45g
>                                               -XX:+UseNUMA
>                                               -Xlog:gc*=debug:file=gc.log:time,uptimemillis
>                                               <composite_application>
>                                               Before Patch :gc.log
>                                               eden space 46718976K, 6% used
>                                                      lgrp 0 space 5838848K, 14% used
>                                                      lgrp 1 space 5838848K, 0% used
>                                                      lgrp 2 space 5838848K, 0% used
>                                                      lgrp 3 space 5838848K, 0% used
>                                                      lgrp 4 space 5838848K, 0% used
>                                                      lgrp 5 space 5838848K, 0% used
>                                                      lgrp 6 space 5838848K, 0% used
>                                                      lgrp 7 space 5847040K, 35% used
>                                               After Patch : gc.log
>                                               eden space 46718976K(45GB), 99% used
>                                                       lgrp 0 space 23359488K(23.5GB), 100% used
>                                                       lgrp 7 space 23359488K(23.5GB), 99%
>                         used
> 
> 
>                                               Note: The proposed solution is only for numactl
>                                               membind option.The fix
>                                               is not for --cpunodebind and localalloc which is a
>                                               separate bug bug
>                         https://bugs.openjdk.java.net/browse/JDK-8205051 <https://bugs.openjdk.java.net/browse/JDK-8205051>
>                                               <https://bugs.openjdk.java.net/browse/JDK-8205051 <https://bugs.openjdk.java.net/browse/JDK-8205051>>
>                                               and fix is in progress
>                                               on this.
> 
>                                               Thanks,
>                                               Swati Sharma
>                                               Software Engineer -2 at AMD
> 
> 
> 
> 
> 
> 
> 
> 
> 


From goetz.lindenmaier at sap.com  Thu Jul 19 07:17:33 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 19 Jul 2018 07:17:33 +0000
Subject: 8207830: [aix] disable jfr in build and tests
Message-ID: <0645e7f5a7a04934a66d1b83e7bdf025@sap.com>

Hi,

We didn't manage to port JFR to aix in the jdk11 time frame.
Thus I would like to disable it in the build. 
As well, I would like to introduce @requires vm.hasJFR which 
will disable the tests on aix, and also on linuxsparcv9 and zero.

Two webrevs for better readability:
This contains the functional changes
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
This contains adding @requires. 
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/
The only one not straight forward is runtime/appcds/sharedStrings/FlagCombo.java

Best regards,
  Goetz.

From thomas.schatzl at oracle.com  Thu Jul 19 12:36:24 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 19 Jul 2018 14:36:24 +0200
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <2621c43f-545c-82a7-7dfb-49accbd55697@linux.vnet.ibm.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
 <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
 <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>
 <BL0PR07MB3890CD2AA56F084140125F75845B0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <DM5PR12MB1177DCF7A508FA7978B417A0F65A0@DM5PR12MB1177.namprd12.prod.outlook.com>
 <b4cf463e-f26e-1805-1392-4910b13a3260@linux.vnet.ibm.com>
 <CAN_ztC3O85mp5i6yGAjnVDDkseNERWHGzTLMjUEEwQddGjff3w@mail.gmail.com>
 <2621c43f-545c-82a7-7dfb-49accbd55697@linux.vnet.ibm.com>
Message-ID: <b3e3e2454e82bd2afa4f50921a0c03fc300f1576.camel@oracle.com>

Hi,

On Wed, 2018-07-18 at 19:46 -0300, Gustavo Romero wrote:
> Hi Community,
> 
> In the light of the additional information brought by Derek and Swati
> on this issue (which I summarized below) would it be possible to get
> a second assessment for this issue regarding its priority? Would it
> be sound to qualify it as P3 instead of P4? I don't have experience
> on doing such an assessment so I ask.
> 
> - If the JVM isn't allowed to use memory on all of the numa nodes,
> for instance, by numactl, cgroups, and docker container, then a
> significant fraction of the JVM heap will be unusable, causing early
> GC;
> 
> - The waste can be up to (N-1)/N of the young generation in some
> cases, where N is the total number of nodes available on the system
> (unpinned); So on an EPYC machine with 8 numa nodes, for instance,
> waste can be up to 7/8 of total memory available on a given node;
> 
> - With the patch for this issue applied SPECjbb2015 on a EPYC machine
> (8 NUMA nodes) shows a significant performance improvement:
> 
>    Case 1: Performance for 1 NUMA node bound, MultiJVM 1 Group Run
> (numactl --cpunodebind=0 --membind=0)
>      Max-jOPS      : +27.59%
>      Critical-jOPS : +260% (As base memory without patch is 1/8 of
> total available memory, heap size impacts Critical-jOPS)
> 
>    Case 2: Performance for 2 NUMA nodes bound, Composite Run (numactl
> --cpunodebind=0,7 --membind=0,7)
>      Max-jOPS      : +10.35%
>      Critical-jOPS : +9.89%
> 
> - It affects AARCH64, PPC64, and Intel/AMD.
> 

  I believe the priority could be increased given these numbers. I will
ask other triaging people what they think too.

Not expecting any issues, I will run it through our test infra (that
does not use non-default node binding) too.

I looked at the webrev, some comments:

- the v2 (http://cr.openjdk.java.net/~gromero/8189922/v2/) webrev does
not apply cleanly any more.

- but it seems good except for some odd naming (imo): the getters
returning a bool do not have the "is" prefix followed by an underscore.
Is that somehow intentional or related to the libnuma naming? (the
"isnode_..." / "isbound_..." prefixes which I would call "is_node_..."
and "is_bound_..") I saw that the numa methods introduced in (I think)
your other patch do the same, so I am not sure. In any case it is no
real issue, and could be cleaned up later too.

I can sponsor to push the change into whatever JDK it ends up.

Thanks,
  Thomas


From vladimir.kozlov at oracle.com  Thu Jul 19 17:22:02 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Jul 2018 10:22:02 -0700
Subject: 8207830: [aix] disable jfr in build and tests
In-Reply-To: <0645e7f5a7a04934a66d1b83e7bdf025@sap.com>
References: <0645e7f5a7a04934a66d1b83e7bdf025@sap.com>
Message-ID: <8a804dbc-2f86-a69d-05e6-0002dedfb0c3@oracle.com>

Tests changes are good.

Thank you for fixing aot check in hotspot.m4

In VMProps.java I would suggest to follow code pattern from other 
features. Add new method vmHasJFR() which returns "true" or "false" 
instead of:

map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());

We may need such method to add other conditions in future.

Thanks,
Vladimir

On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:
> Hi,
> 
> We didn't manage to port JFR to aix in the jdk11 time frame.
> Thus I would like to disable it in the build.
> As well, I would like to introduce @requires vm.hasJFR which
> will disable the tests on aix, and also on linuxsparcv9 and zero.
> 
> Two webrevs for better readability:
> This contains the functional changes
> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
> This contains adding @requires.
> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/

http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/

> The only one not straight forward is runtime/appcds/sharedStrings/FlagCombo.java
> 
> Best regards,
>    Goetz.
> 

From erik.joelsson at oracle.com  Thu Jul 19 17:33:07 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 19 Jul 2018 10:33:07 -0700
Subject: 8207830: [aix] disable jfr in build and tests
In-Reply-To: <8a804dbc-2f86-a69d-05e6-0002dedfb0c3@oracle.com>
References: <0645e7f5a7a04934a66d1b83e7bdf025@sap.com>
 <8a804dbc-2f86-a69d-05e6-0002dedfb0c3@oracle.com>
Message-ID: <b7971c7a-550a-222f-02bb-c58d2503568f@oracle.com>

Build changes look good.

/Erik


On 2018-07-19 10:22, Vladimir Kozlov wrote:
> Tests changes are good.
>
> Thank you for fixing aot check in hotspot.m4
>
> In VMProps.java I would suggest to follow code pattern from other 
> features. Add new method vmHasJFR() which returns "true" or "false" 
> instead of:
>
> map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());
>
> We may need such method to add other conditions in future.
>
> Thanks,
> Vladimir
>
> On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> We didn't manage to port JFR to aix in the jdk11 time frame.
>> Thus I would like to disable it in the build.
>> As well, I would like to introduce @requires vm.hasJFR which
>> will disable the tests on aix, and also on linuxsparcv9 and zero.
>>
>> Two webrevs for better readability:
>> This contains the functional changes
>> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
>> This contains adding @requires.
>> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/
>
> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/
>
>> The only one not straight forward is 
>> runtime/appcds/sharedStrings/FlagCombo.java
>>
>> Best regards,
>> ?? Goetz.
>>


From christian.tornqvist at oracle.com  Thu Jul 19 18:14:33 2018
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 19 Jul 2018 14:14:33 -0400
Subject: RFR: 8207855: Make applications/jcstress invoke tests in batches
Message-ID: <1C37C5DE-1F9B-4712-AE5D-3CBBBE13CC44@oracle.com>

Please review this change that changes the way we invoke the jcstress tests, using batch invocation rather than individual invocation. The time savings are significant, in the Oracle test farm the time executing these tests on Linux x64 went from 182h to 8h. 

TestGenerator.java: Changed it to not add @run tags for all the individual tests, but rather group them by package name. Removed ?-m default? from the list of arguments passed to jcstress, since ?default? is the default mode when nothing has been specified. Timeout has been adjusted for dealing with the 3-4h it takes to run some of the bigger groups.

TEST.groups: Created jcstress_partX groups to be able to execute these tests efficiently in parallel in our test farm.

The rest of the files have been generated by TestGenerator. The change has been tested in Mach 5.

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8207855/webrev.00/ <http://cr.openjdk.java.net/~ctornqvi/webrev/8207855/webrev.00/>
Bug: https://bugs.openjdk.java.net/browse/JDK-8207855 <https://bugs.openjdk.java.net/browse/JDK-8207855>

Thanks,
Christian

From vladimir.kozlov at oracle.com  Thu Jul 19 18:27:44 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Jul 2018 11:27:44 -0700
Subject: RFR: 8207855: Make applications/jcstress invoke tests in batches
In-Reply-To: <1C37C5DE-1F9B-4712-AE5D-3CBBBE13CC44@oracle.com>
References: <1C37C5DE-1F9B-4712-AE5D-3CBBBE13CC44@oracle.com>
Message-ID: <c43a5f5e-9542-c396-783c-48523c0447ee@oracle.com>

Nice improvements! Looks good. Please, add link to test runs into bug 
report.

Thanks,
Vladimir

On 7/19/18 11:14 AM, Christian Tornqvist wrote:
> Please review this change that changes the way we invoke the jcstress tests, using batch invocation rather than individual invocation. The time savings are significant, in the Oracle test farm the time executing these tests on Linux x64 went from 182h to 8h.
> 
> TestGenerator.java: Changed it to not add @run tags for all the individual tests, but rather group them by package name. Removed ?-m default? from the list of arguments passed to jcstress, since ?default? is the default mode when nothing has been specified. Timeout has been adjusted for dealing with the 3-4h it takes to run some of the bigger groups.
> 
> TEST.groups: Created jcstress_partX groups to be able to execute these tests efficiently in parallel in our test farm.
> 
> The rest of the files have been generated by TestGenerator. The change has been tested in Mach 5.
> 
> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8207855/webrev.00/ <http://cr.openjdk.java.net/~ctornqvi/webrev/8207855/webrev.00/>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8207855 <https://bugs.openjdk.java.net/browse/JDK-8207855>
> 
> Thanks,
> Christian
> 

From igor.ignatyev at oracle.com  Thu Jul 19 21:16:16 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 19 Jul 2018 14:16:16 -0700
Subject: RFR: 8207855: Make applications/jcstress invoke tests in batches
In-Reply-To: <c43a5f5e-9542-c396-783c-48523c0447ee@oracle.com>
References: <1C37C5DE-1F9B-4712-AE5D-3CBBBE13CC44@oracle.com>
 <c43a5f5e-9542-c396-783c-48523c0447ee@oracle.com>
Message-ID: <A0D66618-846E-46E9-9D4E-BBAB4447E370@oracle.com>

I haven't gone that path at the beginning as it doesn't allow us to get individual test results from jtreg and doesn't give us a way to problem-list on test-by-test basis. as we haven't seen  (at least recently)  needs for any of it and performance benefits are so huge, I'm fine w/ switching to batch execution mode. Looks good to me.

Thanks,
-- Igor

> On Jul 19, 2018, at 11:27 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Nice improvements! Looks good. Please, add link to test runs into bug report.
> 
> Thanks,
> Vladimir
> 
> On 7/19/18 11:14 AM, Christian Tornqvist wrote:
>> Please review this change that changes the way we invoke the jcstress tests, using batch invocation rather than individual invocation. The time savings are significant, in the Oracle test farm the time executing these tests on Linux x64 went from 182h to 8h.
>> TestGenerator.java: Changed it to not add @run tags for all the individual tests, but rather group them by package name. Removed ?-m default? from the list of arguments passed to jcstress, since ?default? is the default mode when nothing has been specified. Timeout has been adjusted for dealing with the 3-4h it takes to run some of the bigger groups.
>> TEST.groups: Created jcstress_partX groups to be able to execute these tests efficiently in parallel in our test farm.
>> The rest of the files have been generated by TestGenerator. The change has been tested in Mach 5.
>> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8207855/webrev.00/ <http://cr.openjdk.java.net/~ctornqvi/webrev/8207855/webrev.00/>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8207855 <https://bugs.openjdk.java.net/browse/JDK-8207855>
>> Thanks,
>> Christian


From gromero at linux.vnet.ibm.com  Thu Jul 19 21:20:56 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 19 Jul 2018 18:20:56 -0300
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <b3e3e2454e82bd2afa4f50921a0c03fc300f1576.camel@oracle.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
 <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
 <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>
 <BL0PR07MB3890CD2AA56F084140125F75845B0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <DM5PR12MB1177DCF7A508FA7978B417A0F65A0@DM5PR12MB1177.namprd12.prod.outlook.com>
 <b4cf463e-f26e-1805-1392-4910b13a3260@linux.vnet.ibm.com>
 <CAN_ztC3O85mp5i6yGAjnVDDkseNERWHGzTLMjUEEwQddGjff3w@mail.gmail.com>
 <2621c43f-545c-82a7-7dfb-49accbd55697@linux.vnet.ibm.com>
 <b3e3e2454e82bd2afa4f50921a0c03fc300f1576.camel@oracle.com>
Message-ID: <ad31f313-21b6-9a59-5e39-323dd99f4fc7@linux.vnet.ibm.com>

Hi Thomas,

On 07/19/2018 09:36 AM, Thomas Schatzl wrote:
> Hi,
> 
> On Wed, 2018-07-18 at 19:46 -0300, Gustavo Romero wrote:
>> Hi Community,
>>
>> In the light of the additional information brought by Derek and Swati
>> on this issue (which I summarized below) would it be possible to get
>> a second assessment for this issue regarding its priority? Would it
>> be sound to qualify it as P3 instead of P4? I don't have experience
>> on doing such an assessment so I ask.
>>
>> - If the JVM isn't allowed to use memory on all of the numa nodes,
>> for instance, by numactl, cgroups, and docker container, then a
>> significant fraction of the JVM heap will be unusable, causing early
>> GC;
>>
>> - The waste can be up to (N-1)/N of the young generation in some
>> cases, where N is the total number of nodes available on the system
>> (unpinned); So on an EPYC machine with 8 numa nodes, for instance,
>> waste can be up to 7/8 of total memory available on a given node;
>>
>> - With the patch for this issue applied SPECjbb2015 on a EPYC machine
>> (8 NUMA nodes) shows a significant performance improvement:
>>
>>     Case 1: Performance for 1 NUMA node bound, MultiJVM 1 Group Run
>> (numactl --cpunodebind=0 --membind=0)
>>       Max-jOPS      : +27.59%
>>       Critical-jOPS : +260% (As base memory without patch is 1/8 of
>> total available memory, heap size impacts Critical-jOPS)
>>
>>     Case 2: Performance for 2 NUMA nodes bound, Composite Run (numactl
>> --cpunodebind=0,7 --membind=0,7)
>>       Max-jOPS      : +10.35%
>>       Critical-jOPS : +9.89%
>>
>> - It affects AARCH64, PPC64, and Intel/AMD.
>>
> 
>    I believe the priority could be increased given these numbers. I will
> ask other triaging people what they think too.
> 
> Not expecting any issues, I will run it through our test infra (that
> does not use non-default node binding) too.

Thank you so much, Thomas.


> I looked at the webrev, some comments:
> 
> - the v2 (http://cr.openjdk.java.net/~gromero/8189922/v2/) webrev does
> not apply cleanly any more.

It's rebased:

http://cr.openjdk.java.net/~gromero/8189922/v3/

I also added the following to the commit message, if that helps:

8189922: UseNUMA memory interleaving vs membind
Reviewed-by: gromero, drwhite, dholmes, tschatzl
Contributed-by: Swati Sharma <swatibits14 at gmail.com>


> - but it seems good except for some odd naming (imo): the getters
> returning a bool do not have the "is" prefix followed by an underscore.
> Is that somehow intentional or related to the libnuma naming? (the
> "isnode_..." / "isbound_..." prefixes which I would call "is_node_..."
> and "is_bound_..") I saw that the numa methods introduced in (I think)
> your other patch do the same, so I am not sure. In any case it is no
> real issue, and could be cleaned up later too.

I think I took it from libnuma 'numa_bitmask_isbitset', tho 'is' does
not occur at the beginning. Sure, I can send a separate change to clean
up it once that change lands. Thanks for reviewing it!


> I can sponsor to push the change into whatever JDK it ends up.

OK. I'll stay tuned to see how the new triage goes. Thanks a lot for
sponsoring it as well.


Best regards,
Gustavo

> Thanks,
>    Thomas
> 


From goetz.lindenmaier at sap.com  Fri Jul 20 05:41:12 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 20 Jul 2018 05:41:12 +0000
Subject: 8207830: [aix] disable jfr in build and tests
In-Reply-To: <8a804dbc-2f86-a69d-05e6-0002dedfb0c3@oracle.com>
References: <0645e7f5a7a04934a66d1b83e7bdf025@sap.com>
 <8a804dbc-2f86-a69d-05e6-0002dedfb0c3@oracle.com>
Message-ID: <6b8213bfeb20438a9f01d2ae5112334f@sap.com>

Hi Vladimir, 

Thanks for looking at my change. 

> Thank you for fixing aot check in hotspot.m4
I guess this does no harm if aot is enabled, but I saw it on aix.

> Add new method vmHasJFR()
Fixed.

New partial webrev:
http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/02/
The other part is unchanged.

Best regards,
  Goetz.


> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: Thursday, July 19, 2018 7:22 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
> developers <hotspot-dev at openjdk.java.net>
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: Re: 8207830: [aix] disable jfr in build and tests
> 
> Tests changes are good.
> 
> Thank you for fixing aot check in hotspot.m4
> 
> In VMProps.java I would suggest to follow code pattern from other
> features. Add new method vmHasJFR() which returns "true" or "false"
> instead of:
> 
> map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());
> 
> We may need such method to add other conditions in future.
> 
> Thanks,
> Vladimir
> 
> On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > We didn't manage to port JFR to aix in the jdk11 time frame.
> > Thus I would like to disable it in the build.
> > As well, I would like to introduce @requires vm.hasJFR which
> > will disable the tests on aix, and also on linuxsparcv9 and zero.
> >
> > Two webrevs for better readability:
> > This contains the functional changes
> > http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
> > This contains adding @requires.
> > http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/
> 
> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/
> 
> > The only one not straight forward is
> runtime/appcds/sharedStrings/FlagCombo.java
> >
> > Best regards,
> >    Goetz.
> >

From vladimir.kozlov at oracle.com  Fri Jul 20 06:25:54 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Jul 2018 23:25:54 -0700
Subject: 8207830: [aix] disable jfr in build and tests
In-Reply-To: <6b8213bfeb20438a9f01d2ae5112334f@sap.com>
References: <0645e7f5a7a04934a66d1b83e7bdf025@sap.com>
 <8a804dbc-2f86-a69d-05e6-0002dedfb0c3@oracle.com>
 <6b8213bfeb20438a9f01d2ae5112334f@sap.com>
Message-ID: <aeefd6ce-39e0-578d-5385-c8562fc35de6@oracle.com>

Looks good.

Thanks,
Vladimir

On 7/19/18 10:41 PM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
> 
> Thanks for looking at my change.
> 
>> Thank you for fixing aot check in hotspot.m4
> I guess this does no harm if aot is enabled, but I saw it on aix.
> 
>> Add new method vmHasJFR()
> Fixed.
> 
> New partial webrev:
> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/02/
> The other part is unchanged.
> 
> Best regards,
>    Goetz.
> 
> 
>> -----Original Message-----
>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> Sent: Thursday, July 19, 2018 7:22 PM
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-dev
>> developers <hotspot-dev at openjdk.java.net>
>> Cc: build-dev <build-dev at openjdk.java.net>
>> Subject: Re: 8207830: [aix] disable jfr in build and tests
>>
>> Tests changes are good.
>>
>> Thank you for fixing aot check in hotspot.m4
>>
>> In VMProps.java I would suggest to follow code pattern from other
>> features. Add new method vmHasJFR() which returns "true" or "false"
>> instead of:
>>
>> map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());
>>
>> We may need such method to add other conditions in future.
>>
>> Thanks,
>> Vladimir
>>
>> On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> We didn't manage to port JFR to aix in the jdk11 time frame.
>>> Thus I would like to disable it in the build.
>>> As well, I would like to introduce @requires vm.hasJFR which
>>> will disable the tests on aix, and also on linuxsparcv9 and zero.
>>>
>>> Two webrevs for better readability:
>>> This contains the functional changes
>>> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
>>> This contains adding @requires.
>>> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/
>>
>> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/
>>
>>> The only one not straight forward is
>> runtime/appcds/sharedStrings/FlagCombo.java
>>>
>>> Best regards,
>>>     Goetz.
>>>

From serguei.spitsyn at oracle.com  Fri Jul 20 18:18:20 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 20 Jul 2018 11:18:20 -0700
Subject: RFR (S): 8207252: C1 still does eden allocations when TLAB is
 enabled
In-Reply-To: <CAF9BGBweLjX0BOOmcNCwwsLiAz2Jimx8AHjWiMC7mdeCYvdtJg@mail.gmail.com>
References: <CAF9BGBzAVdC3JZCu2945n8JXo0usocBxVxYzdfdBU_gWOTe8wg@mail.gmail.com>
 <9216B675-A5EB-4D45-8F16-D48B83BE93C9@oracle.com>
 <CAF9BGBx7TnVo5vmNx75TUhd1VSeow6KsgcSk2ztKdibKuzv9fw@mail.gmail.com>
 <497549C6-6A68-4407-BA8A-3F001A47EDD0@oracle.com>
 <CAF9BGBxLchBQ3g1uwD=34E+QR5ARO7DqBfxZpFU2TRWTSaTajQ@mail.gmail.com>
 <CAF9BGBzGTsbna1nAh-iQOE-GXqfS6M5wGSBwWEGQX1ADd492JA@mail.gmail.com>
 <a44df8bb9dbd7e951d6fdc2b46d106c42a556f16.camel@oracle.com>
 <CAF9BGBweLjX0BOOmcNCwwsLiAz2Jimx8AHjWiMC7mdeCYvdtJg@mail.gmail.com>
Message-ID: <c9561d70-8831-9b43-fb38-38f94426c7f6@oracle.com>

Restored the bug number and added back the hotspot-dev and 
serviceability-dev mailing lists.

Thanks,
Serguei


On 7/20/18 08:30, JC Beyler wrote:
> Awesome thanks Thomas!
>
> Here is the webrev with the extra information then:
> http://cr.openjdk.java.net/~jcbeyler/8207252/webrev.03/
>
> Thanks again for all the reviews everyone!
> Jc
>
> On Fri, Jul 20, 2018 at 3:23 AM Thomas Schatzl <thomas.schatzl at oracle.com>
> wrote:
>
>> Hi,
>>
>> On Mon, 2018-07-16 at 14:58 -0700, JC Beyler wrote:
>>> Hi all,
>>>
>>> Here is a webrev that does all the architectures in the same way:
>>> http://cr.openjdk.java.net/~jcbeyler/8207252/webrev.02/
>>>
>>> Could anyone review the other architectures and test?
>>>    - arm, sparc & aarch64 are also modified now to follow the same "if
>>> no
>>> tlab, then consider eden space allocation" logic.
>>>
>>> Thanks for your help!
>>> Jc
>>>
>>    looks good.
>>
>> I ran the change through hs-tier1-3 with no issues. It only tests on
>> sparc and x64 though.
>>
>> I do not expect issues on the other platforms though :)
>>
>> Thanks,
>>    Thomas
>>
>>


From thomas.schatzl at oracle.com  Fri Jul 20 20:34:51 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 20 Jul 2018 22:34:51 +0200
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <ad31f313-21b6-9a59-5e39-323dd99f4fc7@linux.vnet.ibm.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
 <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
 <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>
 <BL0PR07MB3890CD2AA56F084140125F75845B0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <DM5PR12MB1177DCF7A508FA7978B417A0F65A0@DM5PR12MB1177.namprd12.prod.outlook.com>
 <b4cf463e-f26e-1805-1392-4910b13a3260@linux.vnet.ibm.com>
 <CAN_ztC3O85mp5i6yGAjnVDDkseNERWHGzTLMjUEEwQddGjff3w@mail.gmail.com>
 <2621c43f-545c-82a7-7dfb-49accbd55697@linux.vnet.ibm.com>
 <b3e3e2454e82bd2afa4f50921a0c03fc300f1576.camel@oracle.com>
 <ad31f313-21b6-9a59-5e39-323dd99f4fc7@linux.vnet.ibm.com>
Message-ID: <4b17180560f2ead62368e58c194a8afaddfecc33.camel@oracle.com>

Hi,

On Thu, 2018-07-19 at 18:20 -0300, Gustavo Romero wrote:
> Hi Thomas,
> 
> On 07/19/2018 09:36 AM, Thomas Schatzl wrote:
> > Hi,
> > 
> > 
[...]
> 
> > I can sponsor to push the change into whatever JDK it ends up.
> 
> OK. I'll stay tuned to see how the new triage goes. Thanks a lot for
> sponsoring it as well.


I will push the v3 change into 11 on Monday. The numbers you gave (here
and on the CR) showed significant perf degradation.

Thanks for making us aware of that.

Thanks,
  Thomas


From gromero at linux.vnet.ibm.com  Fri Jul 20 20:53:45 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Fri, 20 Jul 2018 17:53:45 -0300
Subject: [ping] Re: [11] RFR(M): 8189922: UseNUMA memory interleaving vs
 membind
In-Reply-To: <4b17180560f2ead62368e58c194a8afaddfecc33.camel@oracle.com>
References: <CAN_ztC2J0iC=7b3q=1gaJAd=daMZPSsA04p_Z_3iTbm1V+knkQ@mail.gmail.com>
 <b762a0f0-fca6-5100-ad19-5a3376ffeeeb@oracle.com>
 <CAN_ztC3Uu79mFXxAiaJP-2MSpJBrs7EE3fgZbDDhP7g1bz2+kg@mail.gmail.com>
 <7845462c-802d-2d79-a60e-63f4e3564d43@oracle.com>
 <71c2d874-94d6-f3c0-6d49-efd1d1168ba2@linux.vnet.ibm.com>
 <648d4fd5-c507-ccd8-6ed4-cfdf8a9ad3b4@oracle.com>
 <BL0PR07MB3890CD2AA56F084140125F75845B0@BL0PR07MB3890.namprd07.prod.outlook.com>
 <DM5PR12MB1177DCF7A508FA7978B417A0F65A0@DM5PR12MB1177.namprd12.prod.outlook.com>
 <b4cf463e-f26e-1805-1392-4910b13a3260@linux.vnet.ibm.com>
 <CAN_ztC3O85mp5i6yGAjnVDDkseNERWHGzTLMjUEEwQddGjff3w@mail.gmail.com>
 <2621c43f-545c-82a7-7dfb-49accbd55697@linux.vnet.ibm.com>
 <b3e3e2454e82bd2afa4f50921a0c03fc300f1576.camel@oracle.com>
 <ad31f313-21b6-9a59-5e39-323dd99f4fc7@linux.vnet.ibm.com>
 <4b17180560f2ead62368e58c194a8afaddfecc33.camel@oracle.com>
Message-ID: <a216681f-5ab8-684d-d113-a673185f278c@linux.vnet.ibm.com>

Hi Thomas,

On 07/20/2018 05:34 PM, Thomas Schatzl wrote:
> Hi,
> 
> On Thu, 2018-07-19 at 18:20 -0300, Gustavo Romero wrote:
>> Hi Thomas,
>>
>> On 07/19/2018 09:36 AM, Thomas Schatzl wrote:
>>> Hi,
>>>
>>>
> [...]
>>
>>> I can sponsor to push the change into whatever JDK it ends up.
>>
>> OK. I'll stay tuned to see how the new triage goes. Thanks a lot for
>> sponsoring it as well.
> 
> 
> I will push the v3 change into 11 on Monday. The numbers you gave (here
> and on the CR) showed significant perf degradation.
> 
> Thanks for making us aware of that.

Who first caught my attention about that issue was Swati from AMD.
I basically only confirmed the issue on PPC64, reviewed her initial change and
after Derek confirmed it also fixed the issue on AARCH64 I offered to host
Swati's final version, which is now v3 after you, Derek, David reviewed it :)

Hence I added the following to the commit msg:

8189922: UseNUMA memory interleaving vs membind
Reviewed-by: gromero, drwhite, dholmes, tschatzl
Contributed-by: Swati Sharma <swatibits14 at gmail.com>


Thanks a lot for reviewing it and sponsoring the change!


Best regards,
Gustavo

> Thanks,
>    Thomas
> 


From goetz.lindenmaier at sap.com  Mon Jul 23 06:21:08 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 23 Jul 2018 06:21:08 +0000
Subject: 8207830: [aix] disable jfr in build and tests
In-Reply-To: <b7971c7a-550a-222f-02bb-c58d2503568f@oracle.com>
References: <0645e7f5a7a04934a66d1b83e7bdf025@sap.com>
 <8a804dbc-2f86-a69d-05e6-0002dedfb0c3@oracle.com>
 <b7971c7a-550a-222f-02bb-c58d2503568f@oracle.com>
Message-ID: <6aaeaa36932b4b3ba5280337c6753ac1@sap.com>

Thanks Erik!

Best regards,
  Goetz.

> -----Original Message-----
> From: Erik Joelsson <erik.joelsson at oracle.com>
> Sent: Donnerstag, 19. Juli 2018 19:33
> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; hotspot-dev developers <hotspot-
> dev at openjdk.java.net>
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: Re: 8207830: [aix] disable jfr in build and tests
> 
> Build changes look good.
> 
> /Erik
> 
> 
> On 2018-07-19 10:22, Vladimir Kozlov wrote:
> > Tests changes are good.
> >
> > Thank you for fixing aot check in hotspot.m4
> >
> > In VMProps.java I would suggest to follow code pattern from other
> > features. Add new method vmHasJFR() which returns "true" or "false"
> > instead of:
> >
> > map.put("vm.hasJFR", "" + WB.isJFRIncludedInVmBuild());
> >
> > We may need such method to add other conditions in future.
> >
> > Thanks,
> > Vladimir
> >
> > On 7/19/18 12:17 AM, Lindenmaier, Goetz wrote:
> >> Hi,
> >>
> >> We didn't manage to port JFR to aix in the jdk11 time frame.
> >> Thus I would like to disable it in the build.
> >> As well, I would like to introduce @requires vm.hasJFR which
> >> will disable the tests on aix, and also on linuxsparcv9 and zero.
> >>
> >> Two webrevs for better readability:
> >> This contains the functional changes
> >> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01/
> >> This contains adding @requires.
> >> http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-test/
> >
> > http://cr.openjdk.java.net/~goetz/wr18/8207830-aixDisableJFR/01-tests/
> >
> >> The only one not straight forward is
> >> runtime/appcds/sharedStrings/FlagCombo.java
> >>
> >> Best regards,
> >> ?? Goetz.
> >>


From mvala at redhat.com  Mon Jul 23 13:38:50 2018
From: mvala at redhat.com (Michal Vala)
Date: Mon, 23 Jul 2018 15:38:50 +0200
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier not
 found"
Message-ID: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>

Hi,

JDK-8208084 introduced build failure on Windows, where `snprintf` function is 
not implemented by Visual Studio 2013 (currently latest compiler supported by 
OpenJDK).

I believe using `sprintf` is safe here. Please see the webrev. If it's ok, I 
would also need a sponsor for this.

bug: https://bugs.openjdk.java.net/browse/JDK-8208084
webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.00/


Thanks

-- 
Michal Vala
OpenJDK QE
Red Hat Czech

From kim.barrett at oracle.com  Mon Jul 23 15:27:29 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 23 Jul 2018 11:27:29 -0400
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier
 not found"
In-Reply-To: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
References: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
Message-ID: <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>

> On Jul 23, 2018, at 9:38 AM, Michal Vala <mvala at redhat.com> wrote:
> 
> Hi,
> 
> JDK-8208084 introduced build failure on Windows, where `snprintf` function is not implemented by Visual Studio 2013 (currently latest compiler supported by OpenJDK).
> 
> I believe using `sprintf` is safe here. Please see the webrev. If it's ok, I would also need a sponsor for this.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8208084
> webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.00/
> 
> 
> Thanks
> 
> -- 
> Michal Vala
> OpenJDK QE
> Red Hat Czech

It seems there's some documentation that needs to be updated.  JDK 11
supports building with VS2017, and I think with JDK 12 we'll be
requiring it, in preparation for starting to use features from more
recent C++ standards.


From erik.joelsson at oracle.com  Mon Jul 23 17:15:09 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 23 Jul 2018 10:15:09 -0700
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier
 not found"
In-Reply-To: <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>
References: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
 <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>
Message-ID: <7cdd5ac4-f9e9-58ea-6a5b-9c13222183e6@oracle.com>

Hello,

On 2018-07-23 08:27, Kim Barrett wrote:
>> On Jul 23, 2018, at 9:38 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>> Hi,
>>
>> JDK-8208084 introduced build failure on Windows, where `snprintf` function is not implemented by Visual Studio 2013 (currently latest compiler supported by OpenJDK).
>>
>> I believe using `sprintf` is safe here. Please see the webrev. If it's ok, I would also need a sponsor for this.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8208084
>> webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.00/
>>
>>
>> Thanks
>>
>> -- 
>> Michal Vala
>> OpenJDK QE
>> Red Hat Czech
> It seems there's some documentation that needs to be updated.  JDK 11
> supports building with VS2017, and I think with JDK 12 we'll be
> requiring it, in preparation for starting to use features from more
> recent C++ standards.
>
Indeed, that's on me. I just sent out an RFR to correct this.

/Erik

From mvala at redhat.com  Tue Jul 24 06:03:50 2018
From: mvala at redhat.com (Michal Vala)
Date: Tue, 24 Jul 2018 08:03:50 +0200
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier
 not found"
In-Reply-To: <7cdd5ac4-f9e9-58ea-6a5b-9c13222183e6@oracle.com>
References: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
 <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>
 <7cdd5ac4-f9e9-58ea-6a5b-9c13222183e6@oracle.com>
Message-ID: <d63378a3-e36c-1b92-8c1f-ab6c9dab30be@redhat.com>



On 07/23/2018 07:15 PM, Erik Joelsson wrote:
> Hello,
> 
> On 2018-07-23 08:27, Kim Barrett wrote:
>>> On Jul 23, 2018, at 9:38 AM, Michal Vala <mvala at redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> JDK-8208084 introduced build failure on Windows, where `snprintf` function is 
>>> not implemented by Visual Studio 2013 (currently latest compiler supported by 
>>> OpenJDK).
>>>
>>> I believe using `sprintf` is safe here. Please see the webrev. If it's ok, I 
>>> would also need a sponsor for this.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208084
>>> webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.00/
>>>
>>>
>>> Thanks
>>>
>>> -- 
>>> Michal Vala
>>> OpenJDK QE
>>> Red Hat Czech
>> It seems there's some documentation that needs to be updated.? JDK 11
>> supports building with VS2017, and I think with JDK 12 we'll be
>> requiring it, in preparation for starting to use features from more
>> recent C++ standards.
>>
> Indeed, that's on me. I just sent out an RFR to correct this.

Your changeset doesn't update minimal Visual Studio version. It's not buildable 
with VS2010.

-- 
Michal Vala
OpenJDK QE
Red Hat Czech

From matthias.baesken at sap.com  Tue Jul 24 09:04:50 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 24 Jul 2018 09:04:50 +0000
Subject: test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java fails
 on some ppc64 machines
Message-ID: <b4d098b7a3bd478e9a5c73b1bcf6a479@sap.com>

Hello,

The    test compiler/intrinsics/base64/TestBase64.java

came with JDK-8205528 : Base64 encoding algorithm using AVX512 instructions,  please see

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

This change said to bring performance improvements for java.util.Base64 , however the change seems to include only improvements for Intel x86_64 .
So  currently  we run into timeouts  on some ppc64 machines .

I suggest to increase the timeout  , please see :


Bug :

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


Diff  (I'll  prepare a webrev later) :

diff -r c96c7d08ae49 test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java
--- a/test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java     Thu Jul 19 16:22:19 2018 +0800
+++ b/test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java  Thu Jul 19 14:09:30 2018 +0200
@@ -26,7 +26,7 @@
  * @author Eric Wang <yiming.wang at oracle.com>
  * @summary tests java.util.Base64
  *
- * @run main/othervm/timeout=600 -Xbatch -DcheckOutput=true
+ * @run main/othervm/timeout=2000 -Xbatch -DcheckOutput=true
  *      compiler.intrinsics.base64.TestBase64
  */




Best regards, Matthias

From vladimir.kozlov at oracle.com  Tue Jul 24 15:46:55 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 24 Jul 2018 08:46:55 -0700
Subject: test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java
 fails on some ppc64 machines
In-Reply-To: <b4d098b7a3bd478e9a5c73b1bcf6a479@sap.com>
References: <b4d098b7a3bd478e9a5c73b1bcf6a479@sap.com>
Message-ID: <3386a90d-eaa7-bd70-adad-26c7dbc594c8@oracle.com>

Hi Matthias,

This is duplicate of

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

which I am planning to work on soon. Increase timeout is not correct solution. These tests should be run only when 
intrinsics are used.

Regards,
Vladimir

On 7/24/18 2:04 AM, Baesken, Matthias wrote:
> Hello,
> 
> The    test compiler/intrinsics/base64/TestBase64.java
> 
> came with JDK-8205528 : Base64 encoding algorithm using AVX512 instructions,  please see
> 
> https://bugs.openjdk.java.net/browse/JDK-8205528
> 
> This change said to bring performance improvements for java.util.Base64 , however the change seems to include only improvements for Intel x86_64 .
> So  currently  we run into timeouts  on some ppc64 machines .
> 
> I suggest to increase the timeout  , please see :
> 
> 
> Bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8208124
> 
> 
> Diff  (I'll  prepare a webrev later) :
> 
> diff -r c96c7d08ae49 test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java
> --- a/test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java     Thu Jul 19 16:22:19 2018 +0800
> +++ b/test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java  Thu Jul 19 14:09:30 2018 +0200
> @@ -26,7 +26,7 @@
>    * @author Eric Wang <yiming.wang at oracle.com>
>    * @summary tests java.util.Base64
>    *
> - * @run main/othervm/timeout=600 -Xbatch -DcheckOutput=true
> + * @run main/othervm/timeout=2000 -Xbatch -DcheckOutput=true
>    *      compiler.intrinsics.base64.TestBase64
>    */
> 
> 
> 
> 
> Best regards, Matthias
> 

From HORIE at jp.ibm.com  Wed Jul 25 05:43:59 2018
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Wed, 25 Jul 2018 14:43:59 +0900
Subject: RFR: 8208171: PPC64: Enrich SLP support
Message-ID: <OF27BFB560.0558A39A-ON002582D5.000EEFEA-492582D5.001F7E2E@notes.na.collabserv.com>



Dear all,

Would you review the following change?
Bug: https://bugs.openjdk.java.net/browse/JDK-8208171
Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00

This change adds support for vectorized arithmetic calculation with SLP.

The to_vr function is added to convert VSR to VR. Currently, vecX is
associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad,
which are exactly overlapped with VRs. Instruction APIs receiving VRs use
the to_vr via vecX. Another thing is the change in sqrtF_reg to enable the
matching with SqrtVF. I think the change in sqrtF_reg would be fine due to
the ConvD2FNode::Value in convertnode.cpp.

I confirmed this change with JTREG. In addition, I used attached micro
benchmarks.
(See attached file: slp_microbench.zip)


Best regards,
--
Michihiro,
IBM Research - Tokyo

From matthias.baesken at sap.com  Wed Jul 25 06:39:01 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 25 Jul 2018 06:39:01 +0000
Subject: test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java
 fails on some ppc64 machines
In-Reply-To: <3386a90d-eaa7-bd70-adad-26c7dbc594c8@oracle.com>
References: <b4d098b7a3bd478e9a5c73b1bcf6a479@sap.com>
 <3386a90d-eaa7-bd70-adad-26c7dbc594c8@oracle.com>
Message-ID: <8b67198d942446759bd4e9b9e0d9889d@sap.com>

Hi Vladimir,  thanks for  pointing  me to  the  other bug .

I think it makes sense to  restrict  the test(s)  to CPUs where intrinsics are used .
Until then we might keep the test on our exclude list.

Best regards, Matthias

> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: Dienstag, 24. Juli 2018 17:47
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java
> fails on some ppc64 machines
> 
> Hi Matthias,
> 
> This is duplicate of
> 
> https://bugs.openjdk.java.net/browse/JDK-8207153
> 
> which I am planning to work on soon. Increase timeout is not correct
> solution. These tests should be run only when
> intrinsics are used.
> 
> Regards,
> Vladimir
> 
> On 7/24/18 2:04 AM, Baesken, Matthias wrote:
> > Hello,
> >
> > The    test compiler/intrinsics/base64/TestBase64.java
> >
> > came with JDK-8205528 : Base64 encoding algorithm using AVX512
> instructions,  please see
> >
> > https://bugs.openjdk.java.net/browse/JDK-8205528
> >
> > This change said to bring performance improvements for java.util.Base64 ,
> however the change seems to include only improvements for Intel x86_64 .
> > So  currently  we run into timeouts  on some ppc64 machines .
> >
> > I suggest to increase the timeout  , please see :
> >
> >
> > Bug :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8208124
> >
> >
> > Diff  (I'll  prepare a webrev later) :
> >
> > diff -r c96c7d08ae49
> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java
> > --- a/test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java     Thu
> Jul 19 16:22:19 2018 +0800
> > +++ b/test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java  Thu
> Jul 19 14:09:30 2018 +0200
> > @@ -26,7 +26,7 @@
> >    * @author Eric Wang <yiming.wang at oracle.com>
> >    * @summary tests java.util.Base64
> >    *
> > - * @run main/othervm/timeout=600 -Xbatch -DcheckOutput=true
> > + * @run main/othervm/timeout=2000 -Xbatch -DcheckOutput=true
> >    *      compiler.intrinsics.base64.TestBase64
> >    */
> >
> >
> >
> >
> > Best regards, Matthias
> >

From erik.osterlund at oracle.com  Wed Jul 25 13:50:07 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 25 Jul 2018 15:50:07 +0200
Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter
In-Reply-To: <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com>
References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com>
 <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com>
 <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com>
 <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com>
 <A08320C0-A1AF-4EF8-8B2E-05AA4373EE57@redhat.com>
 <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com>
 <a1416699-78f6-b450-50c3-5d4ac2642a1d@oracle.com>
 <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com>
 <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com>
Message-ID: <5B58800F.1050603@oracle.com>

Hi Roman,

I gotta say I like this a lot better. With the safe defaults for the 
non-expert, yet allowing you guys to be more precise where you know it 
is okay, I am okay with this.
Just a small thing though:

6290 void MacroAssembler::resolve(DecoratorSet decorators, Register obj) {
6291   // Use stronger ACCESS_WRITE by default.
6292   if ((decorators & ACCESS_READ) == 0) {
6293     decorators |= ACCESS_WRITE;
6294   }
6295   BarrierSetAssembler* bs = 
BarrierSet::barrier_set()->barrier_set_assembler();
6296   return bs->resolve(this, decorators, obj);
6297 }

Just in terms of semantics, I think you should really change these 
defaults to:

6292   if ((decorators & (ACCESS_READ | ACCESS_WRITE)) == 0) {
6293     decorators |= ACCESS_READ | ACCESS_WRITE;
6294   }

In other words, the default resolve unless specified is for ACCESS_READ 
| ACCESS_WRITE - you may read or write primitives on the resolved oop. I 
don't think it is necesarily intuitive that being allowed to write 
implicitly means that you are allowed to read too; that is just an 
implementation detail of relocating on writes as Shenandoah does things. 
So if you just change that, you have looks good from me. And I don't 
need another webrev for that.

Thanks,
/Erik

On 2018-07-02 13:56, Roman Kennke wrote:
>>> I am a fan of profile guided optimization. I would definitely not mind
>>> introducing these concepts in the compilers where they are with no doubt
>>> necessary (and we also have the right tools for dealing with this
>>> better). In fact, they already have read/write decorators that could be
>>> used for resolve barriers in our compilers, and can use algorithms to
>>> safely elide barriers where provably correct, so it makes perfect sense
>>> for me to use such concepts there.
>>> I'm just not sure that the interpreter needs to be polluted with this
>>> conceptual overhead, unless there is at least one benchmark that can
>>> show that we are solving an actual problem with this. Remember,
>>> premature optimizations are the root of all evil.
>> but efficient systems are made from thousands of tiny optimizations, each
>> one too small to be measured above the noise on its own.
>>
> After some offline discussion with Erik, I want to propose a solution
> that 1. keeps the API simple to use, even if not sure if it's a read- or
> write-access (defaulting to stronger write, 2. remains flexible enough
> to optimize for read-only acces.
>
> This changeset introduces an API BarrierSetAssembler::resolve() which
> takes the 'hint' about read- vs write-access via a Decorator ACCESS_READ
> and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets
> ACCESS_WRITE if ACCESS_READ is not explicitely set.
>
> Incremental webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/
> Full webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/
>
> If this proposal gets accepted, I'd take this further (in separate RFEs):
> 1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS
> and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they
> are currently passed into Access API that 'knows' what it is, e.g.
> store_at/load_at, etc).
> 2. introduce same pattern for resolve() in runtime (and later, c1 and c2).
>
> What do you think?
>
> Roman
>


From gromero at linux.vnet.ibm.com  Wed Jul 25 14:05:22 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 25 Jul 2018 11:05:22 -0300
Subject: RFR: 8208171: PPC64: Enrich SLP support
In-Reply-To: <OF27BFB560.0558A39A-ON002582D5.000EEFEA-492582D5.001F7E2E@notes.na.collabserv.com>
References: <OF27BFB560.0558A39A-ON002582D5.000EEFEA-492582D5.001F7E2E@notes.na.collabserv.com>
Message-ID: <b235720a-353b-c0e4-d494-eb337eba06a7@linux.vnet.ibm.com>

Hi Michi,

On 07/25/2018 02:43 AM, Michihiro Horie wrote:
> Dear all,
> 
> Would you review the following change?
> Bug: https://bugs.openjdk.java.net/browse/JDK-8208171
> Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00
> 
> This change adds support for vectorized arithmetic calculation with SLP.
> 
> The to_vr function is added to convert VSR to VR. Currently, vecX is associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, which are exactly overlapped with VRs. Instruction APIs receiving VRs use the to_vr via vecX. Another thing is the change in sqrtF_reg to enable the matching with SqrtVF. I think the change in sqrtF_reg would be fine due to the ConvD2FNode::Value in convertnode.cpp.

Looks good. Just a few comments:

- In vmul4F_reg() would it be reasonable to use xvmulsp instead of vmaddfp in
   order to avoid the splat?

- Although all instructions added by your change where introduced in ISA 2.06,
   so POWER7 and above are OK, as I see probes for PowerArchictecturePPC64=6|5 in
   vm_version_ppc.cpp (line 64),  I'm wondering if there is any control point to
   guarantee that these instructions won't be emitted on a CPU that does not
   support them.

- I think that in general string in format %{} are in upper case. For instance,
   this the current output on optoassembly for vmul4F:

2941835 5b4     ADDI    R24, R24, #64
2941836 5b8     vmaddfp  VSR32,VSR32,VSR36      ! mul packed4F
2941837 5c0     STXVD2X     [R17], VSR32        // store 16-byte Vector

   I think it would be better to be in upper case instead. I also think that if
   the node match emits more than one instruction all instructions must be listed
   in format %{}, since it's meant for detailed debugging. Finally I think it
   would be better to replace \t! by \t// in that string (unless I'm missing any
   special meaning for that char). So for vmul4F it would be something like:

2941835 5b4     ADDI      R24, R24, #64
                 VSPLTISW  VSR34, 0                 // Splat 0 imm in VSR34
2941836 5b8     VMADDFP   VSR32,VSR32,VSR36,VSR34  // Mul packed4F
2941837 5c0     STXVD2X   [R17], VSR32             // store 16-byte Vector


But feel free to change anything just after you get additional reviews :)


> I confirmed this change with JTREG. In addition, I used attached micro benchmarks.
> /(See attached file: slp_microbench.zip)/

Thanks for sharing it.
Btw, another option to host it would be in the CR
server, in http://cr.openjdk.java.net/~mhorie/8208171


Best regards,
Gustavo
  
> 
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo
> 


From gromero at linux.vnet.ibm.com  Wed Jul 25 14:05:22 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 25 Jul 2018 11:05:22 -0300
Subject: RFR: 8208171: PPC64: Enrich SLP support
In-Reply-To: <OF27BFB560.0558A39A-ON002582D5.000EEFEA-492582D5.001F7E2E@notes.na.collabserv.com>
References: <OF27BFB560.0558A39A-ON002582D5.000EEFEA-492582D5.001F7E2E@notes.na.collabserv.com>
Message-ID: <b235720a-353b-c0e4-d494-eb337eba06a7@linux.vnet.ibm.com>

Hi Michi,

On 07/25/2018 02:43 AM, Michihiro Horie wrote:
> Dear all,
> 
> Would you review the following change?
> Bug: https://bugs.openjdk.java.net/browse/JDK-8208171
> Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00
> 
> This change adds support for vectorized arithmetic calculation with SLP.
> 
> The to_vr function is added to convert VSR to VR. Currently, vecX is associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, which are exactly overlapped with VRs. Instruction APIs receiving VRs use the to_vr via vecX. Another thing is the change in sqrtF_reg to enable the matching with SqrtVF. I think the change in sqrtF_reg would be fine due to the ConvD2FNode::Value in convertnode.cpp.

Looks good. Just a few comments:

- In vmul4F_reg() would it be reasonable to use xvmulsp instead of vmaddfp in
   order to avoid the splat?

- Although all instructions added by your change where introduced in ISA 2.06,
   so POWER7 and above are OK, as I see probes for PowerArchictecturePPC64=6|5 in
   vm_version_ppc.cpp (line 64),  I'm wondering if there is any control point to
   guarantee that these instructions won't be emitted on a CPU that does not
   support them.

- I think that in general string in format %{} are in upper case. For instance,
   this the current output on optoassembly for vmul4F:

2941835 5b4     ADDI    R24, R24, #64
2941836 5b8     vmaddfp  VSR32,VSR32,VSR36      ! mul packed4F
2941837 5c0     STXVD2X     [R17], VSR32        // store 16-byte Vector

   I think it would be better to be in upper case instead. I also think that if
   the node match emits more than one instruction all instructions must be listed
   in format %{}, since it's meant for detailed debugging. Finally I think it
   would be better to replace \t! by \t// in that string (unless I'm missing any
   special meaning for that char). So for vmul4F it would be something like:

2941835 5b4     ADDI      R24, R24, #64
                 VSPLTISW  VSR34, 0                 // Splat 0 imm in VSR34
2941836 5b8     VMADDFP   VSR32,VSR32,VSR36,VSR34  // Mul packed4F
2941837 5c0     STXVD2X   [R17], VSR32             // store 16-byte Vector


But feel free to change anything just after you get additional reviews :)


> I confirmed this change with JTREG. In addition, I used attached micro benchmarks.
> /(See attached file: slp_microbench.zip)/

Thanks for sharing it.
Btw, another option to host it would be in the CR
server, in http://cr.openjdk.java.net/~mhorie/8208171


Best regards,
Gustavo
  
> 
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo
> 


From daniel.daugherty at oracle.com  Wed Jul 25 16:25:21 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 25 Jul 2018 12:25:21 -0400
Subject: RFR(XXS): 8208189 put compiler/graalunit/JttThreadsTest.java on the
 ProblemList
Message-ID: <cea4eead-a247-ed85-ad8e-3bdaba05854b@oracle.com>

Greetings,

I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
I need a single (R)eviewer for the following fix:

 ? JDK-8208189 put compiler/graalunit/JttThreadsTest.java on the ProblemList
 ? https://bugs.openjdk.java.net/browse/JDK-8208189

Here's the diff:

$ hg diff
diff -r ea900a7dc7d7 test/hotspot/jtreg/ProblemList-graal.txt
--- a/test/hotspot/jtreg/ProblemList-graal.txt?? ?Wed Jul 25 08:36:46 
2018 -0700
+++ b/test/hotspot/jtreg/ProblemList-graal.txt?? ?Wed Jul 25 12:17:53 
2018 -0400
@@ -40,6 +40,8 @@
 ?compiler/compilercontrol/jcmd/AddLogTest.java 8181753?? generic-all
 ?compiler/compilercontrol/mixed/RandomValidCommandsTest.java 8181753?? 
generic-all

+compiler/graalunit/JttThreadsTest.java 8208066?? generic-all
+
 ?compiler/intrinsics/mathexact/LongMulOverflowTest.java 8196568?? 
generic-all

 ?compiler/jvmci/SecurityRestrictionsTest.java 8181837?? generic-all


Thanks, in advance, for any questions, comments or suggestions.

Dan

From joe.darcy at oracle.com  Wed Jul 25 16:26:55 2018
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 25 Jul 2018 09:26:55 -0700
Subject: RFR(XXS): 8208189 put compiler/graalunit/JttThreadsTest.java on
 the ProblemList
In-Reply-To: <cea4eead-a247-ed85-ad8e-3bdaba05854b@oracle.com>
References: <cea4eead-a247-ed85-ad8e-3bdaba05854b@oracle.com>
Message-ID: <acd6f0f5-159b-818d-4986-785ce11b72fc@oracle.com>

+1

Cheers,

-Joe


On 7/25/2018 9:25 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
> I need a single (R)eviewer for the following fix:
>
> ? JDK-8208189 put compiler/graalunit/JttThreadsTest.java on the 
> ProblemList
> ? https://bugs.openjdk.java.net/browse/JDK-8208189
>
> Here's the diff:
>
> $ hg diff
> diff -r ea900a7dc7d7 test/hotspot/jtreg/ProblemList-graal.txt
> --- a/test/hotspot/jtreg/ProblemList-graal.txt?? ?Wed Jul 25 08:36:46 
> 2018 -0700
> +++ b/test/hotspot/jtreg/ProblemList-graal.txt?? ?Wed Jul 25 12:17:53 
> 2018 -0400
> @@ -40,6 +40,8 @@
> ?compiler/compilercontrol/jcmd/AddLogTest.java 8181753 generic-all
> ?compiler/compilercontrol/mixed/RandomValidCommandsTest.java 8181753?? 
> generic-all
>
> +compiler/graalunit/JttThreadsTest.java 8208066?? generic-all
> +
> ?compiler/intrinsics/mathexact/LongMulOverflowTest.java 8196568 
> generic-all
>
> ?compiler/jvmci/SecurityRestrictionsTest.java 8181837 generic-all
>
>
> Thanks, in advance, for any questions, comments or suggestions.
>
> Dan


From daniel.daugherty at oracle.com  Wed Jul 25 16:30:12 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 25 Jul 2018 12:30:12 -0400
Subject: RFR(XXS): 8208189 put compiler/graalunit/JttThreadsTest.java on
 the ProblemList
In-Reply-To: <acd6f0f5-159b-818d-4986-785ce11b72fc@oracle.com>
References: <cea4eead-a247-ed85-ad8e-3bdaba05854b@oracle.com>
 <acd6f0f5-159b-818d-4986-785ce11b72fc@oracle.com>
Message-ID: <0c7beaac-ffb8-fc06-b41d-26455bd115a3@oracle.com>

Thanks for the fast review!

Dan


On 7/25/18 12:26 PM, joe darcy wrote:
> +1
>
> Cheers,
>
> -Joe
>
>
> On 7/25/2018 9:25 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
>> I need a single (R)eviewer for the following fix:
>>
>> ? JDK-8208189 put compiler/graalunit/JttThreadsTest.java on the 
>> ProblemList
>> ? https://bugs.openjdk.java.net/browse/JDK-8208189
>>
>> Here's the diff:
>>
>> $ hg diff
>> diff -r ea900a7dc7d7 test/hotspot/jtreg/ProblemList-graal.txt
>> --- a/test/hotspot/jtreg/ProblemList-graal.txt?? ?Wed Jul 25 08:36:46 
>> 2018 -0700
>> +++ b/test/hotspot/jtreg/ProblemList-graal.txt?? ?Wed Jul 25 12:17:53 
>> 2018 -0400
>> @@ -40,6 +40,8 @@
>> ?compiler/compilercontrol/jcmd/AddLogTest.java 8181753 generic-all
>> ?compiler/compilercontrol/mixed/RandomValidCommandsTest.java 
>> 8181753?? generic-all
>>
>> +compiler/graalunit/JttThreadsTest.java 8208066?? generic-all
>> +
>> ?compiler/intrinsics/mathexact/LongMulOverflowTest.java 8196568 
>> generic-all
>>
>> ?compiler/jvmci/SecurityRestrictionsTest.java 8181837 generic-all
>>
>>
>> Thanks, in advance, for any questions, comments or suggestions.
>>
>> Dan
>


From kevin.walls at oracle.com  Thu Jul 26 10:22:05 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 26 Jul 2018 11:22:05 +0100
Subject: [8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function
 Causes C2084 Already Defined Compilation Error
In-Reply-To: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com>
References: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com>
Message-ID: <a56652f6-c8a5-da3f-077c-bec851fc724a@oracle.com>

Hi - Is anybody available to comment on this one...? Thanks!



On 13/07/2018 20:12, Kevin Walls wrote:
> Hi,
>
> I'd like to request a review of a backport from 11 to 8u:
>
> 8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 
> Already Defined Compilation Error
> JBS: https://bugs.openjdk.java.net/browse/JDK-8196882
>
> 11 changeset:
> http://hg.openjdk.java.net/jdk/hs/rev/eebf559c9e0d
>
> 11 review thread:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030252.html 
>
> ...to...
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030279.html 
>
>
>
> 8u webrev: http://cr.openjdk.java.net/~kevinw/8196882/webrev.00/
>
>
> From VS2015, vsnprintf is provided, and is C99 conforming.? This is 
> new, and
> conflicts with the hotspot-provided definition.? 8196882 introduces 
> os::vsnprintf()
> so we can choose what we call in there.
>
> We don't necessarily want to change behaviour in jdk8u, so we call 
> _vsnprintf()
> on Windows to get the old behaviour.
>
> I didn't plan to move everything to a C99 behaviour here for jdk8u as 
> we did in jdk11.
> We just want to solve the symbol clash, so 
> outputStream::do_vsnprintf() does
> not need to change as it does in 11.
>
> In jvm.cpp, the change in jdk11 changes jio_vsnprintf behaviour, but 
> we wouldn't
> normally choose to change the behaviour at this point in 8u.
>
> (But ensuring the buffer is null-terminated looks like a positive 
> change.)
>
> The original has GTests, here in 8u it's a debug-mode test at 
> runtime.? I have edited some of the
> asserts in check_snprintf_result() as not changing jio_vsnprintf.
>
> I've been building and testing with VS2017 and the current default 
> compiler VS2010,
> plus the other platforms.
>
> Many thanks!
> Kevin
>


From gromero at linux.vnet.ibm.com  Thu Jul 26 14:01:39 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 26 Jul 2018 11:01:39 -0300
Subject: RFR: 8208171: PPC64: Enrich SLP support
In-Reply-To: <OFCAFD0563.FF8B85D0-ON002582D6.0019C339-492582D6.0019F896@notes.na.collabserv.com>
References: <OF27BFB560.0558A39A-ON002582D5.000EEFEA-492582D5.001F7E2E@notes.na.collabserv.com>
 <b235720a-353b-c0e4-d494-eb337eba06a7@linux.vnet.ibm.com>
 <OFCAFD0563.FF8B85D0-ON002582D6.0019C339-492582D6.0019F896@notes.na.collabserv.com>
Message-ID: <f9be32d4-556e-5833-1c4c-8fed133f26d8@linux.vnet.ibm.com>

Hi Michi,

On 07/26/2018 01:43 AM, Michihiro Horie wrote:
> I updated webrev:
> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/

Thanks for providing an updated webrev and for fixing indentation and function
order in assembler_ppc.inline.hpp as well. I have no further comments :)


Best Regards,
Gustavo

> 
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo
> 
> Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie wrote:
> 
> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
> To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port-dev at openjdk.java.net, hotspot-dev at openjdk.java.net
> Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" <martin.doerr at sap.com>
> Date: 2018/07/25 23:05
> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> Hi Michi,
> 
> On 07/25/2018 02:43 AM, Michihiro Horie wrote:
>  > Dear all,
>  >
>  > Would you review the following change?
>  > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171
>  > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00
>  >
>  > This change adds support for vectorized arithmetic calculation with SLP.
>  >
>  > The to_vr function is added to convert VSR to VR. Currently, vecX is associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, which are exactly overlapped with VRs. Instruction APIs receiving VRs use the to_vr via vecX. Another thing is the change in sqrtF_reg to enable the matching with SqrtVF. I think the change in sqrtF_reg would be fine due to the ConvD2FNode::Value in convertnode.cpp.
> 
> Looks good. Just a few comments:
> 
> - In vmul4F_reg() would it be reasonable to use xvmulsp instead of vmaddfp in
>    order to avoid the splat?
> 
> - Although all instructions added by your change where introduced in ISA 2.06,
>    so POWER7 and above are OK, as I see probes for PowerArchictecturePPC64=6|5 in
>    vm_version_ppc.cpp (line 64),  I'm wondering if there is any control point to
>    guarantee that these instructions won't be emitted on a CPU that does not
>    support them.
> 
> - I think that in general string in format %{} are in upper case. For instance,
>    this the current output on optoassembly for vmul4F:
> 
> 2941835 5b4     ADDI    R24, R24, #64
> 2941836 5b8     vmaddfp  VSR32,VSR32,VSR36      ! mul packed4F
> 2941837 5c0     STXVD2X     [R17], VSR32        // store 16-byte Vector
> 
>    I think it would be better to be in upper case instead. I also think that if
>    the node match emits more than one instruction all instructions must be listed
>    in format %{}, since it's meant for detailed debugging. Finally I think it
>    would be better to replace \t! by \t// in that string (unless I'm missing any
>    special meaning for that char). So for vmul4F it would be something like:
> 
> 2941835 5b4     ADDI      R24, R24, #64
>                  VSPLTISW  VSR34, 0                 // Splat 0 imm in VSR34
> 2941836 5b8     VMADDFP   VSR32,VSR32,VSR36,VSR34  // Mul packed4F
> 2941837 5c0     STXVD2X   [R17], VSR32             // store 16-byte Vector
> 
> 
> But feel free to change anything just after you get additional reviews :)
> 
> 
>  > I confirmed this change with JTREG. In addition, I used attached micro benchmarks.
>  > /(See attached file: slp_microbench.zip)/
> 
> Thanks for sharing it.
> Btw, another option to host it would be in the CR
> server, in http://cr.openjdk.java.net/~mhorie/8208171
> 
> 
> Best regards,
> Gustavo
> 
>  >
>  > Best regards,
>  > --
>  > Michihiro,
>  > IBM Research - Tokyo
>  >
> 
> 
> 

From rkennke at redhat.com  Thu Jul 26 14:20:29 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 26 Jul 2018 16:20:29 +0200
Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter
In-Reply-To: <5B58800F.1050603@oracle.com>
References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com>
 <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com>
 <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com>
 <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com>
 <A08320C0-A1AF-4EF8-8B2E-05AA4373EE57@redhat.com>
 <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com>
 <a1416699-78f6-b450-50c3-5d4ac2642a1d@oracle.com>
 <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com>
 <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com>
 <5B58800F.1050603@oracle.com>
Message-ID: <e0ce3477-915d-9695-aff8-fd044783c965@redhat.com>

Hi Erik,

thanks for the review. I agree defaulting to READ|WRITE is even better.

Updated webrevs (for other reviewers):
Incremental:
http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/
Full:
http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/

Would you agree that we could/should make this consistent across
runtime/interpreter/c1/c2 ? It certainly would make me happier in
runtime land, and seems required in compiler land.

Andrew: are you ok with this final patch?

Roman

> I gotta say I like this a lot better. With the safe defaults for the
> non-expert, yet allowing you guys to be more precise where you know it
> is okay, I am okay with this.
> Just a small thing though:
> 
> 6290 void MacroAssembler::resolve(DecoratorSet decorators, Register obj) {
> 6291?? // Use stronger ACCESS_WRITE by default.
> 6292?? if ((decorators & ACCESS_READ) == 0) {
> 6293???? decorators |= ACCESS_WRITE;
> 6294?? }
> 6295?? BarrierSetAssembler* bs =
> BarrierSet::barrier_set()->barrier_set_assembler();
> 6296?? return bs->resolve(this, decorators, obj);
> 6297 }
> 
> Just in terms of semantics, I think you should really change these
> defaults to:
> 
> 6292?? if ((decorators & (ACCESS_READ | ACCESS_WRITE)) == 0) {
> 6293???? decorators |= ACCESS_READ | ACCESS_WRITE;
> 6294?? }
> 
> In other words, the default resolve unless specified is for ACCESS_READ
> | ACCESS_WRITE - you may read or write primitives on the resolved oop. I
> don't think it is necesarily intuitive that being allowed to write
> implicitly means that you are allowed to read too; that is just an
> implementation detail of relocating on writes as Shenandoah does things.
> So if you just change that, you have looks good from me. And I don't
> need another webrev for that.
> 
> Thanks,
> /Erik
> 
> On 2018-07-02 13:56, Roman Kennke wrote:
>>>> I am a fan of profile guided optimization. I would definitely not mind
>>>> introducing these concepts in the compilers where they are with no
>>>> doubt
>>>> necessary (and we also have the right tools for dealing with this
>>>> better). In fact, they already have read/write decorators that could be
>>>> used for resolve barriers in our compilers, and can use algorithms to
>>>> safely elide barriers where provably correct, so it makes perfect sense
>>>> for me to use such concepts there.
>>>> I'm just not sure that the interpreter needs to be polluted with this
>>>> conceptual overhead, unless there is at least one benchmark that can
>>>> show that we are solving an actual problem with this. Remember,
>>>> premature optimizations are the root of all evil.
>>> but efficient systems are made from thousands of tiny optimizations,
>>> each
>>> one too small to be measured above the noise on its own.
>>>
>> After some offline discussion with Erik, I want to propose a solution
>> that 1. keeps the API simple to use, even if not sure if it's a read- or
>> write-access (defaulting to stronger write, 2. remains flexible enough
>> to optimize for read-only acces.
>>
>> This changeset introduces an API BarrierSetAssembler::resolve() which
>> takes the 'hint' about read- vs write-access via a Decorator ACCESS_READ
>> and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets
>> ACCESS_WRITE if ACCESS_READ is not explicitely set.
>>
>> Incremental webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/
>> Full webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/
>>
>> If this proposal gets accepted, I'd take this further (in separate RFEs):
>> 1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS
>> and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they
>> are currently passed into Access API that 'knows' what it is, e.g.
>> store_at/load_at, etc).
>> 2. introduce same pattern for resolve() in runtime (and later, c1 and
>> c2).
>>
>> What do you think?
>>
>> Roman
>>
> 



From erik.osterlund at oracle.com  Thu Jul 26 15:00:50 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 26 Jul 2018 17:00:50 +0200
Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter
In-Reply-To: <e0ce3477-915d-9695-aff8-fd044783c965@redhat.com>
References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com>
 <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com>
 <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com>
 <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com>
 <A08320C0-A1AF-4EF8-8B2E-05AA4373EE57@redhat.com>
 <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com>
 <a1416699-78f6-b450-50c3-5d4ac2642a1d@oracle.com>
 <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com>
 <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com>
 <5B58800F.1050603@oracle.com>
 <e0ce3477-915d-9695-aff8-fd044783c965@redhat.com>
Message-ID: <5B59E222.1080208@oracle.com>

Hi Roman,

On 2018-07-26 16:20, Roman Kennke wrote:
> Hi Erik,
>
> thanks for the review. I agree defaulting to READ|WRITE is even better.
>
> Updated webrevs (for other reviewers):
> Incremental:
> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/
> Full:
> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/
>
> Would you agree that we could/should make this consistent across
> runtime/interpreter/c1/c2 ? It certainly would make me happier in
> runtime land, and seems required in compiler land.

Yes, agreed. I only introduced decorators for this in compilers because 
they were not needed in the interpreter and runtime. But now they are 
needed there too, having different decorators for the same thing will 
only be confusing.

Thanks,
/Erik

> Andrew: are you ok with this final patch?
>
> Roman
>
>> I gotta say I like this a lot better. With the safe defaults for the
>> non-expert, yet allowing you guys to be more precise where you know it
>> is okay, I am okay with this.
>> Just a small thing though:
>>
>> 6290 void MacroAssembler::resolve(DecoratorSet decorators, Register obj) {
>> 6291   // Use stronger ACCESS_WRITE by default.
>> 6292   if ((decorators & ACCESS_READ) == 0) {
>> 6293     decorators |= ACCESS_WRITE;
>> 6294   }
>> 6295   BarrierSetAssembler* bs =
>> BarrierSet::barrier_set()->barrier_set_assembler();
>> 6296   return bs->resolve(this, decorators, obj);
>> 6297 }
>>
>> Just in terms of semantics, I think you should really change these
>> defaults to:
>>
>> 6292   if ((decorators & (ACCESS_READ | ACCESS_WRITE)) == 0) {
>> 6293     decorators |= ACCESS_READ | ACCESS_WRITE;
>> 6294   }
>>
>> In other words, the default resolve unless specified is for ACCESS_READ
>> | ACCESS_WRITE - you may read or write primitives on the resolved oop. I
>> don't think it is necesarily intuitive that being allowed to write
>> implicitly means that you are allowed to read too; that is just an
>> implementation detail of relocating on writes as Shenandoah does things.
>> So if you just change that, you have looks good from me. And I don't
>> need another webrev for that.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-07-02 13:56, Roman Kennke wrote:
>>>>> I am a fan of profile guided optimization. I would definitely not mind
>>>>> introducing these concepts in the compilers where they are with no
>>>>> doubt
>>>>> necessary (and we also have the right tools for dealing with this
>>>>> better). In fact, they already have read/write decorators that could be
>>>>> used for resolve barriers in our compilers, and can use algorithms to
>>>>> safely elide barriers where provably correct, so it makes perfect sense
>>>>> for me to use such concepts there.
>>>>> I'm just not sure that the interpreter needs to be polluted with this
>>>>> conceptual overhead, unless there is at least one benchmark that can
>>>>> show that we are solving an actual problem with this. Remember,
>>>>> premature optimizations are the root of all evil.
>>>> but efficient systems are made from thousands of tiny optimizations,
>>>> each
>>>> one too small to be measured above the noise on its own.
>>>>
>>> After some offline discussion with Erik, I want to propose a solution
>>> that 1. keeps the API simple to use, even if not sure if it's a read- or
>>> write-access (defaulting to stronger write, 2. remains flexible enough
>>> to optimize for read-only acces.
>>>
>>> This changeset introduces an API BarrierSetAssembler::resolve() which
>>> takes the 'hint' about read- vs write-access via a Decorator ACCESS_READ
>>> and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets
>>> ACCESS_WRITE if ACCESS_READ is not explicitely set.
>>>
>>> Incremental webrev:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/
>>> Full webrev:
>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/
>>>
>>> If this proposal gets accepted, I'd take this further (in separate RFEs):
>>> 1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS
>>> and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they
>>> are currently passed into Access API that 'knows' what it is, e.g.
>>> store_at/load_at, etc).
>>> 2. introduce same pattern for resolve() in runtime (and later, c1 and
>>> c2).
>>>
>>> What do you think?
>>>
>>> Roman
>>>
>


From david.griffiths at gmail.com  Thu Jul 26 15:28:32 2018
From: david.griffiths at gmail.com (David Griffiths)
Date: Thu, 26 Jul 2018 16:28:32 +0100
Subject: How to access TemplateInterpreter::_active_table via SA in non-debug
 build?
Message-ID: <CAF+hkWqzzeoZYMufgT3kPFOK4xWQy-cGCSKOwHXo7K7u+HyeXg@mail.gmail.com>

Hi, I would like to access _active_table in TemplateInterpreter using SA
code in a non-debug build. The problem is that that symbol is not exported
by the Hotspot type database. Are there any tricks I can do to get round
this? I can get the start addresses of each template codelet via
AbstractInterpreter::_code and at the moment I'm thinking of doing brute
search for the main entry point for a number of bytecodes until I find
something that looks like the _active_table (although if we are at a
safepoint it may point to the safepoint table? ugh) But is there a better
way? (Don't mind a little bit hacky as long as it works).

If I was to become a contributor, would adding a patch to include
TemplateInterpreter::_active_table in the type database likely be accepted?

Reason for doing such weird things: I want to be able to set a breakpoint
in gdb for a particular bytecode in the interpreter and I want to do this
with the non-debug build using only the symbols exported via
gHotSpotVMTypes.

Cheers,

David

From daniel.daugherty at oracle.com  Thu Jul 26 16:25:53 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 26 Jul 2018 12:25:53 -0400
Subject: RFR(XXS): 8208189 put compiler/graalunit/JttThreadsTest.java on the
 ProblemList
Message-ID: <96890325-54e4-0d94-3970-e1eee06eaea7@oracle.com>

Greetings,

I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
I need a single (R)eviewer for the following fix:

 ? JDK-8208305 ProblemList compiler/jvmci/compilerToVM/GetFlagValueTest.java
 ? https://bugs.openjdk.java.net/browse/JDK-8208305

Here's the diff:

$ hg diff
diff -r 9e04723f53c7 test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txt	Wed Jul 25 17:22:25 2018 -0400
+++ b/test/hotspot/jtreg/ProblemList.txt	Thu Jul 26 12:24:06 2018 -0400
@@ -44,6 +44,7 @@
  compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 
generic-all
  compiler/codegen/Test6896617.java 8193479 generic-all
  compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 
8140405 generic-all
+compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all
  compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 
generic-all
  compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 
generic-all
  compiler/tiered/LevelTransitionTest.java 8067651 generic-all

Thanks, in advance, for any questions, comments or suggestions.

Dan

From daniel.daugherty at oracle.com  Thu Jul 26 16:26:50 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 26 Jul 2018 12:26:50 -0400
Subject: RFR(XXS): 8208189 put compiler/graalunit/JttThreadsTest.java on
 the ProblemList
In-Reply-To: <96890325-54e4-0d94-3970-e1eee06eaea7@oracle.com>
References: <96890325-54e4-0d94-3970-e1eee06eaea7@oracle.com>
Message-ID: <5a19aeaf-534f-228d-8246-7fefe9485ad5@oracle.com>

Please ignore this one. Wrong subject line...

Dan



On 7/26/18 12:25 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
> I need a single (R)eviewer for the following fix:
>
> ? JDK-8208305 ProblemList 
> compiler/jvmci/compilerToVM/GetFlagValueTest.java
> ? https://bugs.openjdk.java.net/browse/JDK-8208305
>
> Here's the diff:
>
> $ hg diff
> diff -r 9e04723f53c7 test/hotspot/jtreg/ProblemList.txt
> --- a/test/hotspot/jtreg/ProblemList.txt??? Wed Jul 25 17:22:25 2018 
> -0400
> +++ b/test/hotspot/jtreg/ProblemList.txt??? Thu Jul 26 12:24:06 2018 
> -0400
> @@ -44,6 +44,7 @@
> ?compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 
> generic-all
> ?compiler/codegen/Test6896617.java 8193479 generic-all
> ?compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 
> 8140405 generic-all
> +compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all
> ?compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 
> generic-all
> ?compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 
> generic-all
> ?compiler/tiered/LevelTransitionTest.java 8067651 generic-all
>
> Thanks, in advance, for any questions, comments or suggestions.
>
> Dan


From daniel.daugherty at oracle.com  Thu Jul 26 16:27:20 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 26 Jul 2018 12:27:20 -0400
Subject: RFR(XXS): 8208305 ProblemList
 compiler/jvmci/compilerToVM/GetFlagValueTest.java
Message-ID: <4824f0f7-811d-d31c-515d-4b3a96b8921b@oracle.com>

Greetings,

I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
I need a single (R)eviewer for the following fix:

 ? JDK-8208305 ProblemList compiler/jvmci/compilerToVM/GetFlagValueTest.java
 ? https://bugs.openjdk.java.net/browse/JDK-8208305

Here's the diff:

$ hg diff
diff -r 9e04723f53c7 test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txt	Wed Jul 25 17:22:25 2018 -0400
+++ b/test/hotspot/jtreg/ProblemList.txt	Thu Jul 26 12:24:06 2018 -0400
@@ -44,6 +44,7 @@
  compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 
generic-all
  compiler/codegen/Test6896617.java 8193479 generic-all
  compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 
8140405 generic-all
+compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all
  compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 
generic-all
  compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 
generic-all
  compiler/tiered/LevelTransitionTest.java 8067651 generic-all

Thanks, in advance, for any questions, comments or suggestions.

Dan

From harold.seigel at oracle.com  Thu Jul 26 16:31:48 2018
From: harold.seigel at oracle.com (Harold David Seigel)
Date: Thu, 26 Jul 2018 12:31:48 -0400
Subject: RFR(XXS): 8208305 ProblemList
 compiler/jvmci/compilerToVM/GetFlagValueTest.java
In-Reply-To: <4824f0f7-811d-d31c-515d-4b3a96b8921b@oracle.com>
References: <4824f0f7-811d-d31c-515d-4b3a96b8921b@oracle.com>
Message-ID: <df2f5178-17aa-a97a-c9b5-ebf13801dab3@oracle.com>

It looks good to me.

Thanks, Harold


On 7/26/2018 12:27 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
> I need a single (R)eviewer for the following fix:
>
> ? JDK-8208305 ProblemList 
> compiler/jvmci/compilerToVM/GetFlagValueTest.java
> ? https://bugs.openjdk.java.net/browse/JDK-8208305
>
> Here's the diff:
>
> $ hg diff
> diff -r 9e04723f53c7 test/hotspot/jtreg/ProblemList.txt
> --- a/test/hotspot/jtreg/ProblemList.txt??? Wed Jul 25 17:22:25 2018 
> -0400
> +++ b/test/hotspot/jtreg/ProblemList.txt??? Thu Jul 26 12:24:06 2018 
> -0400
> @@ -44,6 +44,7 @@
> ?compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 
> generic-all
> ?compiler/codegen/Test6896617.java 8193479 generic-all
> ?compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 
> 8140405 generic-all
> +compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all
> ?compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 
> generic-all
> ?compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 
> generic-all
> ?compiler/tiered/LevelTransitionTest.java 8067651 generic-all
>
> Thanks, in advance, for any questions, comments or suggestions.
>
> Dan


From vladimir.kozlov at oracle.com  Thu Jul 26 16:36:37 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 26 Jul 2018 09:36:37 -0700
Subject: RFR(XXS): 8208305 ProblemList
 compiler/jvmci/compilerToVM/GetFlagValueTest.java
In-Reply-To: <df2f5178-17aa-a97a-c9b5-ebf13801dab3@oracle.com>
References: <4824f0f7-811d-d31c-515d-4b3a96b8921b@oracle.com>
 <df2f5178-17aa-a97a-c9b5-ebf13801dab3@oracle.com>
Message-ID: <c4335586-fa23-d265-6c7b-ba384c97cf0f@oracle.com>

+1

Thanks,
Vladimir

On 7/26/18 9:31 AM, Harold David Seigel wrote:
> It looks good to me.
> 
> Thanks, Harold
> 
> 
> On 7/26/2018 12:27 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
>> I need a single (R)eviewer for the following fix:
>>
>> ? JDK-8208305 ProblemList compiler/jvmci/compilerToVM/GetFlagValueTest.java
>> ? https://bugs.openjdk.java.net/browse/JDK-8208305
>>
>> Here's the diff:
>>
>> $ hg diff
>> diff -r 9e04723f53c7 test/hotspot/jtreg/ProblemList.txt
>> --- a/test/hotspot/jtreg/ProblemList.txt??? Wed Jul 25 17:22:25 2018 -0400
>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Thu Jul 26 12:24:06 2018 -0400
>> @@ -44,6 +44,7 @@
>> ?compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 generic-all
>> ?compiler/codegen/Test6896617.java 8193479 generic-all
>> ?compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 8140405 generic-all
>> +compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all
>> ?compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 generic-all
>> ?compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 8163894 generic-all
>> ?compiler/tiered/LevelTransitionTest.java 8067651 generic-all
>>
>> Thanks, in advance, for any questions, comments or suggestions.
>>
>> Dan
> 

From daniel.daugherty at oracle.com  Thu Jul 26 16:38:00 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 26 Jul 2018 12:38:00 -0400
Subject: RFR(XXS): 8208305 ProblemList
 compiler/jvmci/compilerToVM/GetFlagValueTest.java
In-Reply-To: <c4335586-fa23-d265-6c7b-ba384c97cf0f@oracle.com>
References: <4824f0f7-811d-d31c-515d-4b3a96b8921b@oracle.com>
 <df2f5178-17aa-a97a-c9b5-ebf13801dab3@oracle.com>
 <c4335586-fa23-d265-6c7b-ba384c97cf0f@oracle.com>
Message-ID: <a7276117-d8fe-8f69-07ba-8721040a0005@oracle.com>

Harold and Vladimir,

Thanks for the fast reviews!

Dan


On 7/26/18 12:36 PM, Vladimir Kozlov wrote:
> +1
>
> Thanks,
> Vladimir
>
> On 7/26/18 9:31 AM, Harold David Seigel wrote:
>> It looks good to me.
>>
>> Thanks, Harold
>>
>>
>> On 7/26/2018 12:27 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I'm in the process of reducing the noise in the JDK11 and JDK12 CIs so
>>> I need a single (R)eviewer for the following fix:
>>>
>>> ? JDK-8208305 ProblemList 
>>> compiler/jvmci/compilerToVM/GetFlagValueTest.java
>>> ? https://bugs.openjdk.java.net/browse/JDK-8208305
>>>
>>> Here's the diff:
>>>
>>> $ hg diff
>>> diff -r 9e04723f53c7 test/hotspot/jtreg/ProblemList.txt
>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Wed Jul 25 17:22:25 2018 
>>> -0400
>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Thu Jul 26 12:24:06 2018 
>>> -0400
>>> @@ -44,6 +44,7 @@
>>> ?compiler/codecache/stress/OverloadCompileQueueTest.java 8166554 
>>> generic-all
>>> ?compiler/codegen/Test6896617.java 8193479 generic-all
>>> ?compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java 
>>> 8140405 generic-all
>>> +compiler/jvmci/compilerToVM/GetFlagValueTest.java 8204459 generic-all
>>> ?compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java 8158860 
>>> generic-all
>>> ?compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java 
>>> 8163894 generic-all
>>> ?compiler/tiered/LevelTransitionTest.java 8067651 generic-all
>>>
>>> Thanks, in advance, for any questions, comments or suggestions.
>>>
>>> Dan
>>


From kim.barrett at oracle.com  Thu Jul 26 18:28:28 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Jul 2018 14:28:28 -0400
Subject: [8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function
 Causes C2084 Already Defined Compilation Error
In-Reply-To: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com>
References: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com>
Message-ID: <1775028E-BA4E-475C-BB6E-ED19CBF93ED1@oracle.com>

> On Jul 13, 2018, at 3:12 PM, Kevin Walls <kevin.walls at oracle.com> wrote:
> 
> Hi,
> 
> I'd like to request a review of a backport from 11 to 8u:
> 
> 8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error
> JBS: https://bugs.openjdk.java.net/browse/JDK-8196882
> 
> 11 changeset:
> http://hg.openjdk.java.net/jdk/hs/rev/eebf559c9e0d
> 
> 11 review thread:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030252.html
> ...to...
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030279.html
> 
> 
> 8u webrev: http://cr.openjdk.java.net/~kevinw/8196882/webrev.00/
> 
> 
> From VS2015, vsnprintf is provided, and is C99 conforming.  This is new, and
> conflicts with the hotspot-provided definition.  8196882 introduces os::vsnprintf()
> so we can choose what we call in there.
> 
> We don't necessarily want to change behaviour in jdk8u, so we call _vsnprintf()
> on Windows to get the old behaviour.
> 
> I didn't plan to move everything to a C99 behaviour here for jdk8u as we did in jdk11.
> We just want to solve the symbol clash, so outputStream::do_vsnprintf() does
> not need to change as it does in 11.
> 
> In jvm.cpp, the change in jdk11 changes jio_vsnprintf behaviour, but we wouldn't
> normally choose to change the behaviour at this point in 8u.
> 
> (But ensuring the buffer is null-terminated looks like a positive change.)
> 
> The original has GTests, here in 8u it's a debug-mode test at runtime.  I have edited some of the
> asserts in check_snprintf_result() as not changing jio_vsnprintf.
> 
> I've been building and testing with VS2017 and the current default compiler VS2010,
> plus the other platforms.
> 
> Many thanks!
> Kevin

Note that I am not a Reviewer for jdk8.

------------------------------------------------------------------------------
src/os/windows/vm/os_windows.cpp

According to the RFR:

  "We don't necessarily want to change behaviour in jdk8u, so we call
  _vsnprintf() on Windows to get the old behaviour."

Yet this:
1859   if (result < 0) {
1860     result = _vscprintf(fmt, args);
1861   }

doesn't retain the old behavior, which was to return -1 (on Windows
only) if the output would have exceeded the buffer size.

This matters in the call from outputStream::do_vsnprintf.  The old
code there would never report truncation for POSIX, only for Windows.
With this changeset the DEBUG_ONLY truncation warning there is
incorrect / dead, since a negative result only occurs for encoding
errors. 

------------------------------------------------------------------------------
src/share/vm/prims/jvm.cpp
2917 int jio_vsnprintf(char *str, size_t count, const char *fmt, va_list args) {
[...]
2922   int result = os::vsnprintf(str, count, fmt, args);
2923   // Note: on truncation vsnprintf(3) on Unix returns number of
2924   // characters which would have been written had the buffer been large
2925   // enough; on Windows, it returns -1. We handle both cases here and
2926   // always return -1, and perform null termination.
2927   if ((result > 0 && (size_t)result >= count) || result == -1) {
2928     str[count - 1] = '\0';
2929     result = -1;
2930   }

Since os::vsnprintf *does* guarantee null termination of the result,
it's no longer necessary to ensure that here.  I think the jdk11
version of this function should be fine.

------------------------------------------------------------------------------


From igor.ignatyev at oracle.com  Thu Jul 26 22:46:47 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 26 Jul 2018 15:46:47 -0700
Subject: RFR(S) : 8208358 : update bug ids mentioned in tests
Message-ID: <26344BAB-ED84-4483-9A60-0CBA21A48E7D@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8208358/webrev.00/index.html
> 70 lines changed: 0 ins; 0 del; 70 mod;

Hi all,

could you please review this small patch which update bug ids in hotspot tests and problem list?

webrev: http://cr.openjdk.java.net/~iignatyev//8208358/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8208358

Thanks,
-- Igor

From vladimir.kozlov at oracle.com  Fri Jul 27 04:41:53 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 26 Jul 2018 21:41:53 -0700
Subject: RFR(S) : 8208358 : update bug ids mentioned in tests
In-Reply-To: <26344BAB-ED84-4483-9A60-0CBA21A48E7D@oracle.com>
References: <26344BAB-ED84-4483-9A60-0CBA21A48E7D@oracle.com>
Message-ID: <b7ac873d-0738-33a8-8dc4-b5c7c00580ab@oracle.com>

Good.

Thanks,
Vladimir

On 7/26/18 3:46 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8208358/webrev.00/index.html
>> 70 lines changed: 0 ins; 0 del; 70 mod;
> 
> Hi all,
> 
> could you please review this small patch which update bug ids in hotspot tests and problem list?
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8208358/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8208358
> 
> Thanks,
> -- Igor
> 

From david.griffiths at gmail.com  Fri Jul 27 11:00:15 2018
From: david.griffiths at gmail.com (David Griffiths)
Date: Fri, 27 Jul 2018 12:00:15 +0100
Subject: How to access TemplateInterpreter::_active_table via SA in
 non-debug build?
In-Reply-To: <CAF+hkWqzzeoZYMufgT3kPFOK4xWQy-cGCSKOwHXo7K7u+HyeXg@mail.gmail.com>
References: <CAF+hkWqzzeoZYMufgT3kPFOK4xWQy-cGCSKOwHXo7K7u+HyeXg@mail.gmail.com>
Message-ID: <CAF+hkWp7vwOMcCNQuh47+WNf-0-HT7zDwxQu+p2nzVRTybZ+WA@mail.gmail.com>

Appears that on Linux I can obtain the mangled form of the name:
_ZN19TemplateInterpreter13_active_tableE. Not sure how reliable this is
though?

Cheers,

David

On 26 July 2018 at 16:28, David Griffiths <david.griffiths at gmail.com> wrote:

> Hi, I would like to access _active_table in TemplateInterpreter using SA
> code in a non-debug build. The problem is that that symbol is not exported
> by the Hotspot type database. Are there any tricks I can do to get round
> this? I can get the start addresses of each template codelet via
> AbstractInterpreter::_code and at the moment I'm thinking of doing brute
> search for the main entry point for a number of bytecodes until I find
> something that looks like the _active_table (although if we are at a
> safepoint it may point to the safepoint table? ugh) But is there a better
> way? (Don't mind a little bit hacky as long as it works).
>
> If I was to become a contributor, would adding a patch to include
> TemplateInterpreter::_active_table in the type database likely be
> accepted?
>
> Reason for doing such weird things: I want to be able to set a breakpoint
> in gdb for a particular bytecode in the interpreter and I want to do this
> with the non-debug build using only the symbols exported via
> gHotSpotVMTypes.
>
> Cheers,
>
> David
>

From adinn at redhat.com  Fri Jul 27 12:25:54 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 27 Jul 2018 13:25:54 +0100
Subject: How to access TemplateInterpreter::_active_table via SA in
 non-debug build?
In-Reply-To: <CAF+hkWp7vwOMcCNQuh47+WNf-0-HT7zDwxQu+p2nzVRTybZ+WA@mail.gmail.com>
References: <CAF+hkWqzzeoZYMufgT3kPFOK4xWQy-cGCSKOwHXo7K7u+HyeXg@mail.gmail.com>
 <CAF+hkWp7vwOMcCNQuh47+WNf-0-HT7zDwxQu+p2nzVRTybZ+WA@mail.gmail.com>
Message-ID: <5b4fc623-ff9a-510d-30ba-6315ceacdda0@redhat.com>

On 27/07/18 12:00, David Griffiths wrote:
> Appears that on Linux I can obtain the mangled form of the name:
> _ZN19TemplateInterpreter13_active_tableE. Not sure how reliable this is
> though?
I'm surprised that gdb doesn't already know how to unmangle the above
symbol if has found it for you. After all it knows all about which
compiler was used to build the binary so it ought to know how name
mangling and demangling works. Perhaps this indicates something odd in
the way your binary was built?

Anyway, in case it helps, the Red Hat OpenJDK release packages always
come accompanied with a debuginfo package that provides symbol table
information for the product code and data (in so far as such info exists
when you -O3 optimize code). I relied on that to enable my gdb stack
unwinder to unwind java frames on a product build. It provided enough
info to allow me to trawl through code cache, method and frame data. So,
if you are running on RHEL or Fedora you may find that installing the
debuginfo package(s) provides gdb with the info it needs to locate the
interpreter active table.

regards,


Andrew Dinn
-----------


From david.griffiths at gmail.com  Fri Jul 27 13:13:57 2018
From: david.griffiths at gmail.com (David Griffiths)
Date: Fri, 27 Jul 2018 14:13:57 +0100
Subject: How to access TemplateInterpreter::_active_table via SA in
 non-debug build?
In-Reply-To: <5b4fc623-ff9a-510d-30ba-6315ceacdda0@redhat.com>
References: <CAF+hkWqzzeoZYMufgT3kPFOK4xWQy-cGCSKOwHXo7K7u+HyeXg@mail.gmail.com>
 <CAF+hkWp7vwOMcCNQuh47+WNf-0-HT7zDwxQu+p2nzVRTybZ+WA@mail.gmail.com>
 <5b4fc623-ff9a-510d-30ba-6315ceacdda0@redhat.com>
Message-ID: <CAF+hkWrc_syct8ZCd2msK9NQ3Z4wCiJdp_SOvUbUARNLDZwJxg@mail.gmail.com>

Hi Andrew, yes "info address TemplateInterpreter::_active_table" works in
gdb - I got sidetracked by some code in LinuxVtblAccess which manually
creates the mangled name.

Bit surprised the symbol is there in a non-debug build but never mind!

Cheers,

David


On 27 July 2018 at 13:25, Andrew Dinn <adinn at redhat.com> wrote:

> On 27/07/18 12:00, David Griffiths wrote:
> > Appears that on Linux I can obtain the mangled form of the name:
> > _ZN19TemplateInterpreter13_active_tableE. Not sure how reliable this is
> > though?
> I'm surprised that gdb doesn't already know how to unmangle the above
> symbol if has found it for you. After all it knows all about which
> compiler was used to build the binary so it ought to know how name
> mangling and demangling works. Perhaps this indicates something odd in
> the way your binary was built?
>
> Anyway, in case it helps, the Red Hat OpenJDK release packages always
> come accompanied with a debuginfo package that provides symbol table
> information for the product code and data (in so far as such info exists
> when you -O3 optimize code). I relied on that to enable my gdb stack
> unwinder to unwind java frames on a product build. It provided enough
> info to allow me to trawl through code cache, method and frame data. So,
> if you are running on RHEL or Fedora you may find that installing the
> debuginfo package(s) provides gdb with the info it needs to locate the
> interpreter active table.
>
> regards,
>
>
> Andrew Dinn
> -----------
>
>

From kim.barrett at oracle.com  Fri Jul 27 16:22:07 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Jul 2018 12:22:07 -0400
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier
 not found"
In-Reply-To: <d63378a3-e36c-1b92-8c1f-ab6c9dab30be@redhat.com>
References: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
 <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>
 <7cdd5ac4-f9e9-58ea-6a5b-9c13222183e6@oracle.com>
 <d63378a3-e36c-1b92-8c1f-ab6c9dab30be@redhat.com>
Message-ID: <D7F2D74D-7F9F-4C3F-8404-F2CE517CEB99@oracle.com>

> On Jul 24, 2018, at 2:03 AM, Michal Vala <mvala at redhat.com> wrote:
> 
> 
> 
> On 07/23/2018 07:15 PM, Erik Joelsson wrote:
>> Hello,
>> On 2018-07-23 08:27, Kim Barrett wrote:
>>>> On Jul 23, 2018, at 9:38 AM, Michal Vala <mvala at redhat.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> JDK-8208084 introduced build failure on Windows, where `snprintf` function is not implemented by Visual Studio 2013 (currently latest compiler supported by OpenJDK).
>>>> 
>>>> I believe using `sprintf` is safe here. Please see the webrev. If it's ok, I would also need a sponsor for this.
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208084
>>>> webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.00/
>>>> 
>>>> 
>>>> Thanks
>>>> 
>>>> -- 
>>>> Michal Vala
>>>> OpenJDK QE
>>>> Red Hat Czech
>>> It seems there's some documentation that needs to be updated.  JDK 11
>>> supports building with VS2017, and I think with JDK 12 we'll be
>>> requiring it, in preparation for starting to use features from more
>>> recent C++ standards.
>>> 
>> Indeed, that's on me. I just sent out an RFR to correct this.
> 
> Your changeset doesn't update minimal Visual Studio version. It's not buildable with VS2010.

If it?s really necessary to be able to build JDK 12 with earlier versions of Visual Studio for now
(as I said, it might become impossible later for other reasons), the proper fix is to replace the
call to snprintf with os::snprintf, which is what should have been used in the first place.  I missed
that when I was reviewing JDK-8207359.



From mvala at redhat.com  Mon Jul 30 12:00:41 2018
From: mvala at redhat.com (Michal Vala)
Date: Mon, 30 Jul 2018 14:00:41 +0200
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier
 not found"
In-Reply-To: <D7F2D74D-7F9F-4C3F-8404-F2CE517CEB99@oracle.com>
References: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
 <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>
 <7cdd5ac4-f9e9-58ea-6a5b-9c13222183e6@oracle.com>
 <d63378a3-e36c-1b92-8c1f-ab6c9dab30be@redhat.com>
 <D7F2D74D-7F9F-4C3F-8404-F2CE517CEB99@oracle.com>
Message-ID: <2fe2a6a8-e9be-bb61-9835-2335d7771d4f@redhat.com>



On 07/27/2018 06:22 PM, Kim Barrett wrote:
>> On Jul 24, 2018, at 2:03 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>>
>>
>> On 07/23/2018 07:15 PM, Erik Joelsson wrote:
>>> Hello,
>>> On 2018-07-23 08:27, Kim Barrett wrote:
>>>>> On Jul 23, 2018, at 9:38 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> JDK-8208084 introduced build failure on Windows, where `snprintf` function is not implemented by Visual Studio 2013 (currently latest compiler supported by OpenJDK).
>>>>>
>>>>> I believe using `sprintf` is safe here. Please see the webrev. If it's ok, I would also need a sponsor for this.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208084
>>>>> webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.00/
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- 
>>>>> Michal Vala
>>>>> OpenJDK QE
>>>>> Red Hat Czech
>>>> It seems there's some documentation that needs to be updated.  JDK 11
>>>> supports building with VS2017, and I think with JDK 12 we'll be
>>>> requiring it, in preparation for starting to use features from more
>>>> recent C++ standards.
>>>>
>>> Indeed, that's on me. I just sent out an RFR to correct this.
>>
>> Your changeset doesn't update minimal Visual Studio version. It's not buildable with VS2010.
> 
> If it?s really necessary to be able to build JDK 12 with earlier versions of Visual Studio for now
> (as I said, it might become impossible later for other reasons), the proper fix is to replace the
> call to snprintf with os::snprintf, which is what should have been used in the first place.  I missed
> that when I was reviewing JDK-8207359.
> 
> 

You're right. That also solves the issue with VS2013 and is imho proper way to 
implement it anyway. Here's the new webrev: 
http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.01/

-- 
Michal Vala
OpenJDK QE
Red Hat Czech

From kim.barrett at oracle.com  Mon Jul 30 15:29:02 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 30 Jul 2018 11:29:02 -0400
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier
 not found"
In-Reply-To: <2fe2a6a8-e9be-bb61-9835-2335d7771d4f@redhat.com>
References: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
 <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>
 <7cdd5ac4-f9e9-58ea-6a5b-9c13222183e6@oracle.com>
 <d63378a3-e36c-1b92-8c1f-ab6c9dab30be@redhat.com>
 <D7F2D74D-7F9F-4C3F-8404-F2CE517CEB99@oracle.com>
 <2fe2a6a8-e9be-bb61-9835-2335d7771d4f@redhat.com>
Message-ID: <3766478D-799F-47E8-BFEC-6B74DDFB94DF@oracle.com>

> On Jul 30, 2018, at 8:00 AM, Michal Vala <mvala at redhat.com> wrote:
> On 07/27/2018 06:22 PM, Kim Barrett wrote:
>> If it?s really necessary to be able to build JDK 12 with earlier versions of Visual Studio for now
>> (as I said, it might become impossible later for other reasons), the proper fix is to replace the
>> call to snprintf with os::snprintf, which is what should have been used in the first place.  I missed
>> that when I was reviewing JDK-8207359.
> 
> You're right. That also solves the issue with VS2013 and is imho proper way to implement it anyway. Here's the new webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.01/
> 
> -- 
> Michal Vala
> OpenJDK QE
> Red Hat Czech

Looks good.


From coleen.phillimore at oracle.com  Mon Jul 30 18:29:11 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 30 Jul 2018 14:29:11 -0400
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier
 not found"
In-Reply-To: <2fe2a6a8-e9be-bb61-9835-2335d7771d4f@redhat.com>
References: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
 <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>
 <7cdd5ac4-f9e9-58ea-6a5b-9c13222183e6@oracle.com>
 <d63378a3-e36c-1b92-8c1f-ab6c9dab30be@redhat.com>
 <D7F2D74D-7F9F-4C3F-8404-F2CE517CEB99@oracle.com>
 <2fe2a6a8-e9be-bb61-9835-2335d7771d4f@redhat.com>
Message-ID: <ccb441bf-860f-5c0c-c0b7-4d7c54bf6364@oracle.com>


This looks good.??? I will sponsor it.
Coleen

On 7/30/18 8:00 AM, Michal Vala wrote:
>
>
> On 07/27/2018 06:22 PM, Kim Barrett wrote:
>>> On Jul 24, 2018, at 2:03 AM, Michal Vala <mvala at redhat.com> wrote:
>>>
>>>
>>>
>>> On 07/23/2018 07:15 PM, Erik Joelsson wrote:
>>>> Hello,
>>>> On 2018-07-23 08:27, Kim Barrett wrote:
>>>>>> On Jul 23, 2018, at 9:38 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> JDK-8208084 introduced build failure on Windows, where `snprintf` 
>>>>>> function is not implemented by Visual Studio 2013 (currently 
>>>>>> latest compiler supported by OpenJDK).
>>>>>>
>>>>>> I believe using `sprintf` is safe here. Please see the webrev. If 
>>>>>> it's ok, I would also need a sponsor for this.
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208084
>>>>>> webrev: 
>>>>>> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.00/
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -- 
>>>>>> Michal Vala
>>>>>> OpenJDK QE
>>>>>> Red Hat Czech
>>>>> It seems there's some documentation that needs to be updated.? JDK 11
>>>>> supports building with VS2017, and I think with JDK 12 we'll be
>>>>> requiring it, in preparation for starting to use features from more
>>>>> recent C++ standards.
>>>>>
>>>> Indeed, that's on me. I just sent out an RFR to correct this.
>>>
>>> Your changeset doesn't update minimal Visual Studio version. It's 
>>> not buildable with VS2010.
>>
>> If it?s really necessary to be able to build JDK 12 with earlier 
>> versions of Visual Studio for now
>> (as I said, it might become impossible later for other reasons), the 
>> proper fix is to replace the
>> call to snprintf with os::snprintf, which is what should have been 
>> used in the first place.? I missed
>> that when I was reviewing JDK-8207359.
>>
>>
>
> You're right. That also solves the issue with VS2013 and is imho 
> proper way to implement it anyway. Here's the new webrev: 
> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.01/
>


From mvala at redhat.com  Tue Jul 31 06:32:52 2018
From: mvala at redhat.com (Michal Vala)
Date: Tue, 31 Jul 2018 08:32:52 +0200
Subject: RFR: JDK-8208084: Windows build failure - "'snprintf': identifier
 not found"
In-Reply-To: <ccb441bf-860f-5c0c-c0b7-4d7c54bf6364@oracle.com>
References: <cd0e1c3d-28d0-3531-52b6-571bae702314@redhat.com>
 <E8290C7A-8269-49B2-B4F9-C0D01C0FFCC8@oracle.com>
 <7cdd5ac4-f9e9-58ea-6a5b-9c13222183e6@oracle.com>
 <d63378a3-e36c-1b92-8c1f-ab6c9dab30be@redhat.com>
 <D7F2D74D-7F9F-4C3F-8404-F2CE517CEB99@oracle.com>
 <2fe2a6a8-e9be-bb61-9835-2335d7771d4f@redhat.com>
 <ccb441bf-860f-5c0c-c0b7-4d7c54bf6364@oracle.com>
Message-ID: <15e78f2c-0a88-3808-1e05-ae4faa950bb9@redhat.com>

thanks Coleen and Kim!

On 07/30/2018 08:29 PM, coleen.phillimore at oracle.com wrote:
> 
> This looks good.??? I will sponsor it.
> Coleen
> 
> On 7/30/18 8:00 AM, Michal Vala wrote:
>>
>>
>> On 07/27/2018 06:22 PM, Kim Barrett wrote:
>>>> On Jul 24, 2018, at 2:03 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>
>>>>
>>>>
>>>> On 07/23/2018 07:15 PM, Erik Joelsson wrote:
>>>>> Hello,
>>>>> On 2018-07-23 08:27, Kim Barrett wrote:
>>>>>>> On Jul 23, 2018, at 9:38 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> JDK-8208084 introduced build failure on Windows, where `snprintf` 
>>>>>>> function is not implemented by Visual Studio 2013 (currently latest 
>>>>>>> compiler supported by OpenJDK).
>>>>>>>
>>>>>>> I believe using `sprintf` is safe here. Please see the webrev. If it's 
>>>>>>> ok, I would also need a sponsor for this.
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208084
>>>>>>> webrev: http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.00/
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -- 
>>>>>>> Michal Vala
>>>>>>> OpenJDK QE
>>>>>>> Red Hat Czech
>>>>>> It seems there's some documentation that needs to be updated.? JDK 11
>>>>>> supports building with VS2017, and I think with JDK 12 we'll be
>>>>>> requiring it, in preparation for starting to use features from more
>>>>>> recent C++ standards.
>>>>>>
>>>>> Indeed, that's on me. I just sent out an RFR to correct this.
>>>>
>>>> Your changeset doesn't update minimal Visual Studio version. It's not 
>>>> buildable with VS2010.
>>>
>>> If it?s really necessary to be able to build JDK 12 with earlier versions of 
>>> Visual Studio for now
>>> (as I said, it might become impossible later for other reasons), the proper 
>>> fix is to replace the
>>> call to snprintf with os::snprintf, which is what should have been used in 
>>> the first place.? I missed
>>> that when I was reviewing JDK-8207359.
>>>
>>>
>>
>> You're right. That also solves the issue with VS2013 and is imho proper way to 
>> implement it anyway. Here's the new webrev: 
>> http://cr.openjdk.java.net/~mvala/jdk/jdk/JDK-8208084/webrev.01/
>>
> 

-- 
Michal Vala
OpenJDK QE
Red Hat Czech

From adinn at redhat.com  Tue Jul 31 11:10:05 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 31 Jul 2018 12:10:05 +0100
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
 <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
Message-ID: <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>

Hi Zhengyu,

On 12/07/18 14:19, Zhengyu Gu wrote:
> Epsilon just became the first GC to support object pinning!
> (https://bugs.openjdk.java.net/browse/JDK-8207056)
> 
> I added test cases for Epsilon to exercise this patch.
> 
> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.03/index.html
> 
> Test:
> 
> ? gc/epsilon on Linux 64 (fastdebug + release)
The patch itself looks fine to me. I'm not really clear what the test
case is supposed to be doing.

Zhengyu, I think you need to add an explanation of how this test will
catch errors that might arise in pinning and, in doing so, perhaps
comment on a few details of what the test does, viz: What is the point
of allocating the garbage arrays? What is the point of using
THREAD_PER_CASE * 2 threads. Why make the run methods iterate CYCLES times?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From zgu at redhat.com  Tue Jul 31 13:25:38 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 31 Jul 2018 09:25:38 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
 <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
 <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>
Message-ID: <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com>

Hi Andrew,

Thanks for reviewing.


On 07/31/2018 07:10 AM, Andrew Dinn wrote:
> 
> Zhengyu, I think you need to add an explanation of how this test will
> catch errors that might arise in pinning and, in doing so, perhaps
> comment on a few details of what the test does, viz: What is the point
> of allocating the garbage arrays? What is the point of using
> THREAD_PER_CASE * 2 threads. Why make the run methods iterate CYCLES times?

I added comments as you suggested.

Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/

-Zhengyu

> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
> 

From adinn at redhat.com  Tue Jul 31 14:37:25 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 31 Jul 2018 15:37:25 +0100
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
 <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
 <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>
 <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com>
Message-ID: <aab7dcf6-23b0-b5d3-3739-88ce35385886@redhat.com>

Hi Zhengyu,

On 31/07/18 14:25, Zhengyu Gu wrote:
> I added comments as you suggested.
> 
> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/
Ok, thanks.

The above patch is reviewed modulo two misspellings of 'critical' as
'ciritical' in CriticalNativeStress.java.

No need for another webrev.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From erik.osterlund at oracle.com  Tue Jul 31 15:44:41 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Tue, 31 Jul 2018 17:44:41 +0200
Subject: RFR: 8208582: Introduce native oop barriers in C1 for OopHandle
In-Reply-To: <1533049674.local-48cfadc1-4a64-v1.3.0-fd741eb7@getmailspring.com>
References: <1533049674.local-48cfadc1-4a64-v1.3.0-fd741eb7@getmailspring.com>
Message-ID: <B89B98B7-8402-4C3E-A11D-EE93B818D79B@oracle.com>

+hotspot-dev by popular demand

> On 31 Jul 2018, at 17:35, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
> 
> Hi,
> 
> There is currently no way of doing IN_NATIVE accesses in C1 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support concurrent class unloading in ZGC, this support must be added.
> 
> This webrev adds C1 support for this:
> http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/
> Bug URL:
> https://bugs.openjdk.java.net/browse/JDK-8208582
> 
> Thanks,
> /Erik

From daniel.daugherty at oracle.com  Tue Jul 31 19:12:51 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 31 Jul 2018 15:12:51 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <aab7dcf6-23b0-b5d3-3739-88ce35385886@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
 <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
 <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>
 <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com>
 <aab7dcf6-23b0-b5d3-3739-88ce35385886@redhat.com>
Message-ID: <b241866a-6dce-a306-4262-d203536dbe03@oracle.com>

This fix has broken the JDK12 CI tier1 builds:

JDK-8208605 Fix for 8199868 breaks tier1 build
https://bugs.openjdk.java.net/browse/JDK-8208605

Zhengyu, let me know how quickly you can have this fixed or
if you prefer I back out the fix. I'm guessing this was not
tested using jdk-submit...

Dan


On 7/31/18 10:37 AM, Andrew Dinn wrote:
> Hi Zhengyu,
>
> On 31/07/18 14:25, Zhengyu Gu wrote:
>> I added comments as you suggested.
>>
>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/
> Ok, thanks.
>
> The above patch is reviewed modulo two misspellings of 'critical' as
> 'ciritical' in CriticalNativeStress.java.
>
> No need for another webrev.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>


From zgu at redhat.com  Tue Jul 31 20:50:16 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 31 Jul 2018 16:50:16 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <b241866a-6dce-a306-4262-d203536dbe03@oracle.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
 <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
 <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>
 <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com>
 <aab7dcf6-23b0-b5d3-3739-88ce35385886@redhat.com>
 <b241866a-6dce-a306-4262-d203536dbe03@oracle.com>
Message-ID: <1ec11e08-f17c-7ad9-3c23-3b02055fc579@redhat.com>

Hi Dan,

On 07/31/2018 03:12 PM, Daniel D. Daugherty wrote:
> This fix has broken the JDK12 CI tier1 builds:
> 
> JDK-8208605 Fix for 8199868 breaks tier1 build
> https://bugs.openjdk.java.net/browse/JDK-8208605
> 
> Zhengyu, let me know how quickly you can have this fixed or
> if you prefer I back out the fix. I'm guessing this was not
> tested using jdk-submit...

I did run through submit repo.

http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html

And results I got:

Build Details: 2018-07-31-1535425.zgu.source
0 Failed Tests
Mach5 Tasks Results Summary

     PASSED: 75
     FAILED: 0
     KILLED: 0
     NA: 0
     UNABLE_TO_RUN: 0
     EXECUTED_WITH_FAILURE: 0

I will fix this right now.

Thanks,

-Zhengyu



> 
> Dan
> 
> 
> On 7/31/18 10:37 AM, Andrew Dinn wrote:
>> Hi Zhengyu,
>>
>> On 31/07/18 14:25, Zhengyu Gu wrote:
>>> I added comments as you suggested.
>>>
>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/
>> Ok, thanks.
>>
>> The above patch is reviewed modulo two misspellings of 'critical' as
>> 'ciritical' in CriticalNativeStress.java.
>>
>> No need for another webrev.
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>> Senior Principal Software Engineer
>> Red Hat UK Ltd
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>
> 

From daniel.daugherty at oracle.com  Tue Jul 31 20:54:06 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 31 Jul 2018 16:54:06 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <1ec11e08-f17c-7ad9-3c23-3b02055fc579@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
 <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
 <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>
 <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com>
 <aab7dcf6-23b0-b5d3-3739-88ce35385886@redhat.com>
 <b241866a-6dce-a306-4262-d203536dbe03@oracle.com>
 <1ec11e08-f17c-7ad9-3c23-3b02055fc579@redhat.com>
Message-ID: <3c5fd1f4-c55c-43e0-8b79-11ebd75ad762@oracle.com>

On 7/31/18 4:50 PM, Zhengyu Gu wrote:
> Hi Dan,
>
> On 07/31/2018 03:12 PM, Daniel D. Daugherty wrote:
>> This fix has broken the JDK12 CI tier1 builds:
>>
>> JDK-8208605 Fix for 8199868 breaks tier1 build
>> https://bugs.openjdk.java.net/browse/JDK-8208605
>>
>> Zhengyu, let me know how quickly you can have this fixed or
>> if you prefer I back out the fix. I'm guessing this was not
>> tested using jdk-submit...
>
> I did run through submit repo.

Then the submit repo must not be doing Solaris SPARC builds...
Or something else... I dunno...

I have a fix reviewed and I'm waiting for the mach5 tier1
builds to finish...

Dan



>
> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html 
>
>
> And results I got:
>
> Build Details: 2018-07-31-1535425.zgu.source
> 0 Failed Tests
> Mach5 Tasks Results Summary
>
> ??? PASSED: 75
> ??? FAILED: 0
> ??? KILLED: 0
> ??? NA: 0
> ??? UNABLE_TO_RUN: 0
> ??? EXECUTED_WITH_FAILURE: 0
>
> I will fix this right now.
>
> Thanks,
>
> -Zhengyu
>
>
>
>>
>> Dan
>>
>>
>> On 7/31/18 10:37 AM, Andrew Dinn wrote:
>>> Hi Zhengyu,
>>>
>>> On 31/07/18 14:25, Zhengyu Gu wrote:
>>>> I added comments as you suggested.
>>>>
>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/
>>> Ok, thanks.
>>>
>>> The above patch is reviewed modulo two misspellings of 'critical' as
>>> 'ciritical' in CriticalNativeStress.java.
>>>
>>> No need for another webrev.
>>>
>>> regards,
>>>
>>>
>>> Andrew Dinn
>>> -----------
>>> Senior Principal Software Engineer
>>> Red Hat UK Ltd
>>> Registered in England and Wales under Company Registration No. 03798903
>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>>
>>


From zgu at redhat.com  Tue Jul 31 20:56:01 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 31 Jul 2018 16:56:01 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <3c5fd1f4-c55c-43e0-8b79-11ebd75ad762@oracle.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
 <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
 <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>
 <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com>
 <aab7dcf6-23b0-b5d3-3739-88ce35385886@redhat.com>
 <b241866a-6dce-a306-4262-d203536dbe03@oracle.com>
 <1ec11e08-f17c-7ad9-3c23-3b02055fc579@redhat.com>
 <3c5fd1f4-c55c-43e0-8b79-11ebd75ad762@oracle.com>
Message-ID: <c3cbf069-3cf6-de0a-fbec-720d592e00a5@redhat.com>



On 07/31/2018 04:54 PM, Daniel D. Daugherty wrote:
> On 7/31/18 4:50 PM, Zhengyu Gu wrote:
>> Hi Dan,
>>
>> On 07/31/2018 03:12 PM, Daniel D. Daugherty wrote:
>>> This fix has broken the JDK12 CI tier1 builds:
>>>
>>> JDK-8208605 Fix for 8199868 breaks tier1 build
>>> https://bugs.openjdk.java.net/browse/JDK-8208605
>>>
>>> Zhengyu, let me know how quickly you can have this fixed or
>>> if you prefer I back out the fix. I'm guessing this was not
>>> tested using jdk-submit...
>>
>> I did run through submit repo.
> 
> Then the submit repo must not be doing Solaris SPARC builds...
> Or something else... I dunno...
> 
> I have a fix reviewed and I'm waiting for the mach5 tier1
> builds to finish...

Thank you, Dan.

-Zhengyu

> 
> Dan
> 
> 
> 
>>
>> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html 
>>
>>
>> And results I got:
>>
>> Build Details: 2018-07-31-1535425.zgu.source
>> 0 Failed Tests
>> Mach5 Tasks Results Summary
>>
>> ??? PASSED: 75
>> ??? FAILED: 0
>> ??? KILLED: 0
>> ??? NA: 0
>> ??? UNABLE_TO_RUN: 0
>> ??? EXECUTED_WITH_FAILURE: 0
>>
>> I will fix this right now.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>
>>>
>>> Dan
>>>
>>>
>>> On 7/31/18 10:37 AM, Andrew Dinn wrote:
>>>> Hi Zhengyu,
>>>>
>>>> On 31/07/18 14:25, Zhengyu Gu wrote:
>>>>> I added comments as you suggested.
>>>>>
>>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/
>>>> Ok, thanks.
>>>>
>>>> The above patch is reviewed modulo two misspellings of 'critical' as
>>>> 'ciritical' in CriticalNativeStress.java.
>>>>
>>>> No need for another webrev.
>>>>
>>>> regards,
>>>>
>>>>
>>>> Andrew Dinn
>>>> -----------
>>>> Senior Principal Software Engineer
>>>> Red Hat UK Ltd
>>>> Registered in England and Wales under Company Registration No. 03798903
>>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>>>
>>>
> 

From daniel.daugherty at oracle.com  Tue Jul 31 21:10:15 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 31 Jul 2018 17:10:15 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <c3cbf069-3cf6-de0a-fbec-720d592e00a5@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
 <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
 <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
 <b9fba643-81ae-aa9c-7b60-d056bed67699@redhat.com>
 <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com>
 <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com>
 <adbe6b91-2700-b29e-bab6-f0031826fcac@redhat.com>
 <b4d2e1d9-3f30-4191-5ada-e884e0f7ca3c@redhat.com>
 <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com>
 <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com>
 <aab7dcf6-23b0-b5d3-3739-88ce35385886@redhat.com>
 <b241866a-6dce-a306-4262-d203536dbe03@oracle.com>
 <1ec11e08-f17c-7ad9-3c23-3b02055fc579@redhat.com>
 <3c5fd1f4-c55c-43e0-8b79-11ebd75ad762@oracle.com>
 <c3cbf069-3cf6-de0a-fbec-720d592e00a5@redhat.com>
Message-ID: <7d17b6f0-4bc9-111b-ede8-d16f5ac240d3@oracle.com>

On 7/31/18 4:56 PM, Zhengyu Gu wrote:
> On 07/31/2018 04:54 PM, Daniel D. Daugherty wrote:
>> On 7/31/18 4:50 PM, Zhengyu Gu wrote:
>>> Hi Dan,
>>>
>>> On 07/31/2018 03:12 PM, Daniel D. Daugherty wrote:
>>>> This fix has broken the JDK12 CI tier1 builds:
>>>>
>>>> JDK-8208605 Fix for 8199868 breaks tier1 build
>>>> https://bugs.openjdk.java.net/browse/JDK-8208605
>>>>
>>>> Zhengyu, let me know how quickly you can have this fixed or
>>>> if you prefer I back out the fix. I'm guessing this was not
>>>> tested using jdk-submit...
>>>
>>> I did run through submit repo.
>>
>> Then the submit repo must not be doing Solaris SPARC builds...
>> Or something else... I dunno...

Apparently the jdk-submit repo does not do Solaris SPARC builds.
I do not know why not, but I'll rattle some cages on this end.

I apologize for assuming that you did not use that jdk-submit repo.

Dan


>>
>> I have a fix reviewed and I'm waiting for the mach5 tier1
>> builds to finish...
>
> Thank you, Dan.
>
> -Zhengyu
>
>>
>> Dan
>>
>>
>>
>>>
>>> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html 
>>>
>>>
>>> And results I got:
>>>
>>> Build Details: 2018-07-31-1535425.zgu.source
>>> 0 Failed Tests
>>> Mach5 Tasks Results Summary
>>>
>>> ??? PASSED: 75
>>> ??? FAILED: 0
>>> ??? KILLED: 0
>>> ??? NA: 0
>>> ??? UNABLE_TO_RUN: 0
>>> ??? EXECUTED_WITH_FAILURE: 0
>>>
>>> I will fix this right now.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 7/31/18 10:37 AM, Andrew Dinn wrote:
>>>>> Hi Zhengyu,
>>>>>
>>>>> On 31/07/18 14:25, Zhengyu Gu wrote:
>>>>>> I added comments as you suggested.
>>>>>>
>>>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/
>>>>> Ok, thanks.
>>>>>
>>>>> The above patch is reviewed modulo two misspellings of 'critical' as
>>>>> 'ciritical' in CriticalNativeStress.java.
>>>>>
>>>>> No need for another webrev.
>>>>>
>>>>> regards,
>>>>>
>>>>>
>>>>> Andrew Dinn
>>>>> -----------
>>>>> Senior Principal Software Engineer
>>>>> Red Hat UK Ltd
>>>>> Registered in England and Wales under Company Registration No. 
>>>>> 03798903
>>>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>>>>
>>>>
>>


From kevin.walls at oracle.com  Tue Jul 31 21:14:09 2018
From: kevin.walls at oracle.com (Kevin Walls)
Date: Tue, 31 Jul 2018 22:14:09 +0100
Subject: [8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function
 Causes C2084 Already Defined Compilation Error
In-Reply-To: <1775028E-BA4E-475C-BB6E-ED19CBF93ED1@oracle.com>
References: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com>
 <1775028E-BA4E-475C-BB6E-ED19CBF93ED1@oracle.com>
Message-ID: <447ac3cc-68da-d1a5-b58e-35445c642728@oracle.com>

Great, thanks Kim,

Not being an 8 Reviewer is fine, I'm very happy to get your comments 
here, and when we're happy with it I do a specific 8u approval email.

src/os/windows/vm/os_windows.cpp / os::vsnprintf()? oops yes, should not 
check the result and call _vscprintf().

src/share/vm/prims/jvm.cpp / jio_vsnprintf() should not force the 
null-terminator in the result.

Making Windows retain its different behaviour also means the tests need 
to be different for Windows, so in ostream.cpp? in test_snprintf() I 
change the boolean passed to the test depending on the platform.? On 
Windows, expect_count is false.

Updated webrev:

http://cr.openjdk.java.net/~kevinw/8196882/webrev.01/

Thanks
Kevin



On 26/07/2018 19:28, Kim Barrett wrote:
>> On Jul 13, 2018, at 3:12 PM, Kevin Walls <kevin.walls at oracle.com> wrote:
>>
>> Hi,
>>
>> I'd like to request a review of a backport from 11 to 8u:
>>
>> 8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8196882
>>
>> 11 changeset:
>> http://hg.openjdk.java.net/jdk/hs/rev/eebf559c9e0d
>>
>> 11 review thread:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030252.html
>> ...to...
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-February/030279.html
>>
>>
>> 8u webrev: http://cr.openjdk.java.net/~kevinw/8196882/webrev.00/
>>
>>
>>  From VS2015, vsnprintf is provided, and is C99 conforming.  This is new, and
>> conflicts with the hotspot-provided definition.  8196882 introduces os::vsnprintf()
>> so we can choose what we call in there.
>>
>> We don't necessarily want to change behaviour in jdk8u, so we call _vsnprintf()
>> on Windows to get the old behaviour.
>>
>> I didn't plan to move everything to a C99 behaviour here for jdk8u as we did in jdk11.
>> We just want to solve the symbol clash, so outputStream::do_vsnprintf() does
>> not need to change as it does in 11.
>>
>> In jvm.cpp, the change in jdk11 changes jio_vsnprintf behaviour, but we wouldn't
>> normally choose to change the behaviour at this point in 8u.
>>
>> (But ensuring the buffer is null-terminated looks like a positive change.)
>>
>> The original has GTests, here in 8u it's a debug-mode test at runtime.  I have edited some of the
>> asserts in check_snprintf_result() as not changing jio_vsnprintf.
>>
>> I've been building and testing with VS2017 and the current default compiler VS2010,
>> plus the other platforms.
>>
>> Many thanks!
>> Kevin
> Note that I am not a Reviewer for jdk8.
>
> ------------------------------------------------------------------------------
> src/os/windows/vm/os_windows.cpp
>
> According to the RFR:
>
>    "We don't necessarily want to change behaviour in jdk8u, so we call
>    _vsnprintf() on Windows to get the old behaviour."
>
> Yet this:
> 1859   if (result < 0) {
> 1860     result = _vscprintf(fmt, args);
> 1861   }
>
> doesn't retain the old behavior, which was to return -1 (on Windows
> only) if the output would have exceeded the buffer size.
>
> This matters in the call from outputStream::do_vsnprintf.  The old
> code there would never report truncation for POSIX, only for Windows.
> With this changeset the DEBUG_ONLY truncation warning there is
> incorrect / dead, since a negative result only occurs for encoding
> errors.
>
> ------------------------------------------------------------------------------
> src/share/vm/prims/jvm.cpp
> 2917 int jio_vsnprintf(char *str, size_t count, const char *fmt, va_list args) {
> [...]
> 2922   int result = os::vsnprintf(str, count, fmt, args);
> 2923   // Note: on truncation vsnprintf(3) on Unix returns number of
> 2924   // characters which would have been written had the buffer been large
> 2925   // enough; on Windows, it returns -1. We handle both cases here and
> 2926   // always return -1, and perform null termination.
> 2927   if ((result > 0 && (size_t)result >= count) || result == -1) {
> 2928     str[count - 1] = '\0';
> 2929     result = -1;
> 2930   }
>
> Since os::vsnprintf *does* guarantee null termination of the result,
> it's no longer necessary to ensure that here.  I think the jdk11
> version of this function should be fine.
>
> ------------------------------------------------------------------------------
>


From kim.barrett at oracle.com  Tue Jul 31 22:15:29 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 31 Jul 2018 18:15:29 -0400
Subject: [8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function
 Causes C2084 Already Defined Compilation Error
In-Reply-To: <447ac3cc-68da-d1a5-b58e-35445c642728@oracle.com>
References: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com>
 <1775028E-BA4E-475C-BB6E-ED19CBF93ED1@oracle.com>
 <447ac3cc-68da-d1a5-b58e-35445c642728@oracle.com>
Message-ID: <04810989-7A14-4F19-A6DE-AAEA96847278@oracle.com>

> On Jul 31, 2018, at 5:14 PM, Kevin Walls <kevin.walls at oracle.com> wrote:
> 
> Great, thanks Kim, 
> Not being an 8 Reviewer is fine, I'm very happy to get your comments here, and when we're happy with it I do a specific 8u approval email.
> 
> src/os/windows/vm/os_windows.cpp / os::vsnprintf()  oops yes, should not check the result and call _vscprintf().
> src/share/vm/prims/jvm.cpp / jio_vsnprintf() should not force the null-terminator in the result.
> 
> Making Windows retain its different behaviour also means the tests need to be different for Windows, so in ostream.cpp  in test_snprintf() I change the boolean passed to the test depending on the platform.  On Windows, expect_count is false.
> 
> Updated webrev:
> http://cr.openjdk.java.net/~kevinw/8196882/webrev.01/
> Thanks
> Kevin

I think that trying this hard to retain the different Windows behavior is a mistake.

There aren?t that many callers of vsnprint / os::vsnprintf, and most of them don?t care
(don?t examine the return value).  We can see all of them, since this is a function inside
of hotspot, and not something exposed (unlike jio_vsnprintf and friends, which are in
a ?public? header).

We *are* retaining the old behavior for jio_vsnprintf.

One of the few (the only?) other callers that cares is the one in ostream.cpp, and it is
at least arguable that it has always been somewhat wrong, and was fixed by the
jdk11 change.