From tobias.hartmann at oracle.com  Mon Dec  1 05:58:44 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 01 Dec 2014 06:58:44 +0100
Subject: [8u40] Backport RFR: 8007993: hotspot.log w/ enabled LogCompilation
	can be an invalid XML
Message-ID: <547C0394.10902@oracle.com>

Hi,

please review the following backport request for 8u40.

8007993: hotspot.log w/ enabled LogCompilation can be an invalid XML
https://bugs.openjdk.java.net/browse/JDK-8007993
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c13eb14ebf5c
http://cr.openjdk.java.net/~thartmann/8007993/webrev.00/

The changes were pushed to 9 on Wednesday and nightly testing showed no
problems. The patch cleanly applies to 8u40.

Thanks,
Tobias

From david.holmes at oracle.com  Mon Dec  1 06:15:54 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 01 Dec 2014 16:15:54 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <5479E9DE.7070703@gmail.com>
References: <542C8274.3010809@gmail.com>	<54338B70.9080709@oracle.com>	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>	<543B1FD6.3000200@oracle.com>	<543CF553.80601@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com>
Message-ID: <547C079A.9020604@oracle.com>

Hi Yasumasa,

On 30/11/2014 1:44 AM, Yasumasa Suenaga wrote:
> Hi all,
>
>
> Thank you for checking my patch!
> I've uploaded new webrev:
> http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.03/hotspot.patch
>
> David:
>> The change in:
>>   src/os/aix/vm/os_aix.cpp
>>   src/os/solaris/vm/os_solaris.cpp
>>
>>    jio_snprintf(buffer, bufferSize, "%s/core or core.%d",
>> current_process_id());
>>
>> has no argument for the %s - presumably p was intended.
>
> I've fixed.

Thanks. The formatting needs fixing up though, the p should line up with 
buffer.

I'm concerned by the changes in os_linux.cpp and os_posix.cpp to use 
os::malloc. If this is being called from a signal handler there's a real 
risk of deadlock if we try to use malloc/free. I know Thomas suggested 
this (and sorry I didn't notice it then) but I don't think it is a good 
idea for the crash handler.

Thanks,
David

>
> Staffan:
>> src/os/bsd/vm/os_linux.cpp:
>> Could we not simplify this to print a helpful message instead?
>
> Most of case in Linux, I think that core image name is "core.<pid>" .
> In other case which except pipe redirection, I guess that user defines it.
> Thus I print string in kernel.core_pattern directly.
>
>> src/os/bsd/vm/os_bsd.cpp:
>> On OS X cores are by default written to /cores/core.<pid>. This is
>> configureable with the kern.corefile sysctl variable, although it is
>> rare to do so.
>
> Thank you!
> I changed path to "/cores/core.<pid>" .
>
>
> Thomas:
>> - jio_snprintf() returns -1 on truncation. n+=written may walk
>> backwards. I would probably check for (written >= 0) and also, at the
>> start of the loop, for (n < sizeof(core_path)).
>> - code is used in error reporting. I would be hesitant to create
>> larger buffers on the stack. malloc may be better.
>
> I've fixed them.
>
>> - code does not detect truncation of core_path (unlikely but possible)
>
> Do you mean variable name?
> "core_path" in my patch stores /proc/sys/kernel/core_pattern .
> Length of kernel.core_pattern is defined 128 chars in Linux Kernel
> Documentation.
> https://www.kernel.org/doc/Documentation/sysctl/kernel.txt
>
> Thus length of core_path (129 chars) is enough.
>
>> - when reading /proc/sys/kernel/core_uses_pid, using fgetc instead of
>> fgets may be a tiny bit simpler.
>
> I changed to use fgetc() .
>
>
> Thanks,
>
> Yasumasa
>
>
> (2014/11/26 23:12), Thomas St?fe wrote:
>> Hi Yasumasa,
>>
>> I am not a Reviewer. Barring the general decision of the real
>> reviewers, here are some thoughts:
>>
>> os_linux.cpp
>>
>> - jio_snprintf() returns -1 on truncation. n+=written may walk
>> backwards. I would probably check for (written >= 0) and also, at the
>> start of the loop, for (n < sizeof(core_path)).
>> - code is used in error reporting. I would be hesitant to create
>> larger buffers on the stack. malloc may be better.
>> - code does not detect truncation of core_path (unlikely but possible)
>>
>> the rest is more matter of taste:
>> - I would prefer sizeof(core_path) over PATH_MAX at all places where
>> you refer to the size of the buffer. So you could make the buffer very
>> small and test e.g. how your code behaves with truncation.
>> - when reading /proc/sys/kernel/core_uses_pid, using fgetc instead of
>> fgets may be a tiny bit simpler.
>>
>> Kind Regards, Thomas
>>
>>
>>
>> On Wed, Nov 26, 2014 at 4:54 AM, Yasumasa Suenaga <yasuenag at gmail.com
>> <mailto:yasuenag at gmail.com>> wrote:
>>
>>     Hi Staffan,
>>
>>     Thank you for reviewing!
>>
>>     os_linux.cpp:
>>     I want to print coredump location correctly to hs_err. So I want
>> to output
>>     whether coredump is processed in other process or is written to file.
>>     If os::get_core_path() should be more simply, I will print raw
>> string in
>>     core_pattern.
>>
>>     os_bsd.cpp:
>>     I don't have OS X. So I cannot check it.
>>     I am focusing Linux in this enhancement. Could you file it as another
>>     enhancement if it need?
>>
>>     Thanks,
>>
>>     Yasumasa
>>
>>       2014/11/25 18:15 "Staffan Larsen" <staffan.larsen at oracle.com
>> <mailto:staffan.larsen at oracle.com>>:
>>
>>      > src/os/bsd/vm/os_linux.cpp:
>>      > I?m inclined to think this is too complicated and hard to test and
>>      > maintain (and I see no tests in the webrev). Could we not
>> simplify this to
>>      > print a helpful message instead? Something that prints the
>> core_pattern and
>>      > perhaps some of the values that could be used for substitution,
>> but does
>>      > not do the actual substitution? I think that would go a long
>> way but be a
>>      > lot more maintainable.
>>      >
>>      > src/os/bsd/vm/os_bsd.cpp:
>>      > On OS X cores are by default written to /cores/core.<pid>. This is
>>      > configureable with the kern.corefile sysctl variable, although
>> it is rare
>>      > to do so.
>>      >
>>      >  /Staffan
>>      >
>>      > > On 24 nov 2014, at 14:21, Yasumasa Suenaga
>> <yasuenag at gmail.com <mailto:yasuenag at gmail.com>> wrote:
>>      > >
>>      > > Hi all,
>>      > >
>>      > > I've uploaded webrev for this issue about a month ago.
>>      > > Could you review it and sponsor it?
>>      > >
>>      > >
>>      > > Thanks,
>>      > >
>>      > > Yasumasa
>>      > >
>>      > >
>>      > > On 10/15/2014 11:13 PM, Yasumasa Suenaga wrote:
>>      > >> Hi David,
>>      > >>
>>      > >> I've uploaded new webrev:
>>      > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/
>>      > >>
>>      > >>
>>      > >>> I wasn't suggesting that you make such a change though
>> because it is
>>      > large and disruptive.
>>      > >>
>>      > >>> Unfactoring check_or_create_dump is a step backwards in
>> terms of code
>>      > sharing.
>>      > >>
>>      > >> I restored check_or_create_dump() to os_posix.cpp .
>>      > >> And I changed get_core_path() to create message which
>> represents core
>>      > dump path
>>      > >> (including filename) in each OS.
>>      > >>
>>      > >>
>>      > >>> Expanding the get_core_path in os_linux.cpp to handle the
>> core_pattern
>>      > may be okay (but I don't know enough about it to validate
>> everything).
>>      > >>
>>      > >> I implemented all parameters in Linux kernel documentation:
>>      > >> https://www.kernel.org/doc/Documentation/sysctl/kernel.txt
>>      > >>
>>      > >> So I think that parameters which are processed are enough.
>>      > >>
>>      > >>
>>      > >> Thanks,
>>      > >>
>>      > >> Yasumasa
>>      > >>
>>      > >>
>>      > >>
>>      > >> (2014/10/15 9:41), David Holmes wrote:
>>      > >>> On 14/10/2014 8:05 PM, Yasumasa Suenaga wrote:
>>      > >>>> Hi David,
>>      > >>>>
>>      > >>>> Thank you for comments!
>>      > >>>> I've uploaded new webrev. Could you review it again?
>>      > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.01/
>>      > >>>>
>>      > >>>> I am an author of jdk9. So I cannot commit it.
>>      > >>>> Could you be a sponsor for this enhancement?
>>      > >>>>
>>      > >>>>
>>      > >>>>> In which case that should be handled by the linux specific
>>      > >>>>> get_core_path() function.
>>      > >>>>
>>      > >>>> Agree.
>>      > >>>> So I implemented it in os_linux.cpp .
>>      > >>>> But part of format characters (%P: global pid, %s: signal,
>> %t dump
>>      > time)
>>      > >>>> are not processed
>>      > >>>> in this function because I think these parameters are
>> difficult to
>>      > >>>> handle in it.
>>      > >>>>
>>      > >>>>   %P: I could not find API for this.
>>      > >>>>   %s: We have to change arguments of get_core_path() .
>>      > >>>>   %t: This parameter means timestamp of coredump. It is
>> decided in
>>      > Kernel.
>>      > >>>>
>>      > >>>>
>>      > >>>>> Fixing this means changing all the os_posix using
>> platforms. But your
>>      > >>>>> patch is not about this part. :)
>>      > >>>>
>>      > >>>> I moved os::check_or_create_dump() to each OS
>> implementations (AIX,
>>      > BSD,
>>      > >>>> Solaris, Linux) .
>>      > >>>> So I can write Linux specific code to
>> check_or_create_dump() .
>>      > >>>> As a result, I could remove "#ifdef LINUX" from
>> os_posix.cpp :-)
>>      > >>>
>>      > >>> I wasn't suggesting that you make such a change though
>> because it is
>>      > large and disruptive. The simple handling of the | part of
>> core_pattern was
>>      > basically ok. Expanding the get_core_path in os_linux.cpp to
>> handle the
>>      > core_pattern may be okay (but I don't know enough about it to
>> validate
>>      > everything). Unfactoring check_or_create_dump is a step
>> backwards in terms
>>      > of code sharing.
>>      > >>>
>>      > >>> Sorry this has grown too large for me to deal with right now.
>>      > >>>
>>      > >>> David
>>      > >>> -----
>>      > >>>
>>      > >>>>
>>      > >>>>> Though I'm unclear whether it both invokes the program
>> and creates a
>>      > >>>>> core dump file; or just invokes the program?
>>      > >>>>
>>      > >>>> If '|' is set, Linux kernel will just redirect core image
>> to user
>>      > process.
>>      > >>>> Kernel documentation says as below:
>>      > >>>> ------------
>>      > >>>> . If the first character of the pattern is a '|', the
>> kernel will
>>      > treat
>>      > >>>>   the rest of the pattern as a command to run.  The core
>> dump will be
>>      > >>>>   written to the standard input of that program instead of
>> to a file.
>>      > >>>> ------------
>>      > >>>>
>>      > >>>> And implementation of coredump (do_coredump()) follows to it.
>>      > >>>>
>>      >
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/coredump.c
>>
>>      > >>>>
>>      > >>>>
>>      > >>>> In case of ABRT, ABRT dumps core image to default location
>>      > >>>> (<CWD>/core.<PID>)
>>      > >>>> if user set unlimited to resource limit of core (ulimit -c) .
>>      > >>>>
>> https://github.com/abrt/abrt/blob/master/src/hooks/abrt-hook-ccpp.c
>>      > >>>>
>>      > >>>>
>>      > >>>>> A few style nits - you need spaces around keywords and
>> before braces
>>      > >>>>> I also suggest saying "Core dumps may be processed with
>> ..." rather
>>      > >>>>> than "treated".
>>      > >>>>> And as you don't do anything in the non-redirect case I
>> suggest
>>      > >>>>> collapsing this:
>>      > >>>>
>>      > >>>> I've fixed them.
>>      > >>>>
>>      > >>>>
>>      > >>>> Thanks,
>>      > >>>>
>>      > >>>> Yasumasa
>>      > >>>>
>>      > >>>>
>>      > >>>> (2014/10/13 9:41), David Holmes wrote:
>>      > >>>>> Hi Yasumasa,
>>      > >>>>>
>>      > >>>>> On 7/10/2014 8:48 PM, Yasumasa Suenaga wrote:
>>      > >>>>>> Hi David,
>>      > >>>>>>
>>      > >>>>>> Sorry for my English.
>>      > >>>>>>
>>      > >>>>>> I want to propose that JVM should create message
>> according to core
>>      > >>>>>> pattern (/proc/sys/kernel/core_pattern) .
>>      > >>>>>> So I filed it to JBS and created a patch.
>>      > >>>>>
>>      > >>>>> So I've had a quick look at this core_pattern business
>> and it seems
>>      > to
>>      > >>>>> me that there are two aspects to this.
>>      > >>>>>
>>      > >>>>> First, without the leading |, the entry in the
>> core_pattern file is a
>>      > >>>>> naming pattern for the core file. In which case that
>> should be
>>      > handled
>>      > >>>>> by the linux specific get_core_path() function. Though
>> that in itself
>>      > >>>>> can't fully report the expected name, as part of it is
>> provided in
>>      > the
>>      > >>>>> shared code in os::check_or_create_dump. Fixing this
>> means changing
>>      > >>>>> all the os_posix using platforms. But your patch is not
>> about this
>>      > >>>>> part. :)
>>      > >>>>>
>>      > >>>>> Second, with a leading | the core_pattern is actually the
>> name of a
>>      > >>>>> program to execute when the program is about to core
>> dump, and that
>>      > is
>>      > >>>>> what you report with your patch. Though I'm unclear
>> whether it both
>>      > >>>>> invokes the program and creates a core dump file; or just
>> invokes the
>>      > >>>>> program?
>>      > >>>>>
>>      > >>>>> So with regards to this second part your patch seems
>> functionally ok.
>>      > >>>>> I do dislike having a big chunk of linux specific code in
>> this
>>      > "posix"
>>      > >>>>> support file but ...
>>      > >>>>>
>>      > >>>>> A few style nits - you need spaces around keywords and
>> before braces
>>      > eg:
>>      > >>>>>
>>      > >>>>>   if(x){
>>      > >>>>>
>>      > >>>>> should be
>>      > >>>>>
>>      > >>>>>   if (x) {
>>      > >>>>>
>>      > >>>>> I also suggest saying "Core dumps may be processed with
>> ..." rather
>>      > >>>>> than "treated".
>>      > >>>>>
>>      > >>>>> And as you don't do anything in the non-redirect case I
>> suggest
>>      > >>>>> collapsing this:
>>      > >>>>>
>>      > >>>>>   83           is_redirect = core_pattern[0] == '|';
>>      > >>>>>   84         }
>>      > >>>>>   85
>>      > >>>>>   86         if(is_redirect){
>>      > >>>>>   87           jio_snprintf(buffer, bufferSize,
>>      > >>>>>   88                    "Core dumps may be treated with
>> \"%s\"",
>>      > >>>>> &core_pattern[1]);
>>      > >>>>>   89         }
>>      > >>>>>
>>      > >>>>> to just
>>      > >>>>>
>>      > >>>>>   83           if (core_pattern[0] == '|') {  // redirect
>>      > >>>>>   84             jio_snprintf(buffer, bufferSize, "Core
>> dumps may be
>>      > >>>>> processed with \"%s\"", &core_pattern[1]);
>>      > >>>>>   85            }
>>      > >>>>>   86         }
>>      > >>>>>
>>      > >>>>> Comments from other runtime folk appreciated.
>>      > >>>>>
>>      > >>>>> Thanks,
>>      > >>>>> David
>>      > >>>>>
>>      > >>>>>> Thanks,
>>      > >>>>>>
>>      > >>>>>> Yasumasa
>>      > >>>>>>
>>      > >>>>>> 2014/10/07 15:43 "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>>>:
>>      > >>>>>>
>>      > >>>>>>    Hi Yasumasa,
>>      > >>>>>>
>>      > >>>>>>    I'm sorry but I don't understand what you are
>> proposing. When you
>>      > >>>>>> say
>>      > >>>>>>    "treat" do you mean "create"? Otherwise what do you
>> mean by
>>      > >>>>>> "treated"?
>>      > >>>>>>
>>      > >>>>>>    Thanks,
>>      > >>>>>>    David
>>      > >>>>>>
>>      > >>>>>>    On 2/10/2014 8:38 AM, Yasumasa Suenaga wrote:
>>      > >>>>>>     > I'm in Hackergarten @ JavaOne :-)
>>      > >>>>>>     >
>>      > >>>>>>     >
>>      > >>>>>>     > Hi all,
>>      > >>>>>>     >
>>      > >>>>>>     > I would like to enhance the messages in hs_err
>> report.
>>      > >>>>>>     > Modern Linux kernel can treat core dump with user
>> process
>>      > >>>>>> (e.g. ABRT)
>>      > >>>>>>     > However, hs_err report cannot detect it.
>>      > >>>>>>     >
>>      > >>>>>>     > I think that hs_err report should output messages
>> as below:
>>      > >>>>>>     > -------------
>>      > >>>>>>     >     Failed to write core dump. Core dumps may be
>> treated with
>>      > >>>>>>    "/usr/sbin/chroot /proc/%P/root
>> /usr/libexec/abrt-hook-ccpp %s
>>      > %c %p
>>      > >>>>>>    %u %g %t e"
>>      > >>>>>>     > -------------
>>      > >>>>>>     >
>>      > >>>>>>     > I've uploaded webrev of this enhancement.
>>      > >>>>>>     > Could you review it?
>>      > >>>>>>     >
>>      > >>>>>>     >
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.00/
>>      > >>>>>>     >
>>      > >>>>>>     > This patch works fine on Fedora20 x86_64.
>>      > >>>>>>     >
>>      > >>>>>>     >
>>      > >>>>>>     >
>>      > >>>>>>     > Thanks,
>>      > >>>>>>     >
>>      > >>>>>>     > Yasumasa
>>      > >>>>>>     >
>>      > >>>>>>
>>      >
>>      >
>>
>>

From thomas.stuefe at gmail.com  Mon Dec  1 07:18:17 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 1 Dec 2014 08:18:17 +0100
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <547C079A.9020604@oracle.com>
References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com>
	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>
	<543B1FD6.3000200@oracle.com> <543CF553.80601@gmail.com>
	<543DC2BF.9050407@oracle.com> <543E80F8.3080204@gmail.com>
	<547330E5.1050708@gmail.com>
	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>
	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com> <547C079A.9020604@oracle.com>
Message-ID: <CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>

David, Yasumasa,

> Thanks. The formatting needs fixing up though, the p should line up with
> buffer.
>
> I'm concerned by the changes in os_linux.cpp and os_posix.cpp to use
> os::malloc. If this is being called from a signal handler there's a real
> risk of deadlock if we try to use malloc/free. I know Thomas suggested this
> (and sorry I didn't notice it then) but I don't think it is a good idea for
> the crash handler.
>
>
Correct. Sorry, my fault, I was not clear enough. I meant for you to use
the pure malloc(3), not os::malloc.

Using pure malloc is still a risk if the C-Heap is corrupted, but sometimes
it makes sense for larger buffers. The risk of running into a corrupted
C-Heap is sometimes offset by the risk of running out of stack space.

Kind Regards, Thomas


> Thanks,
> David
>
>

From david.holmes at oracle.com  Mon Dec  1 07:26:13 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 01 Dec 2014 17:26:13 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
References: <542C8274.3010809@gmail.com>	<54338B70.9080709@oracle.com>	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>	<543B1FD6.3000200@oracle.com>	<543CF553.80601@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>
	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
Message-ID: <547C1815.6050900@oracle.com>

On 1/12/2014 5:18 PM, Thomas St?fe wrote:
> David, Yasumasa,
>
>     Thanks. The formatting needs fixing up though, the p should line up
>     with buffer.
>
>     I'm concerned by the changes in os_linux.cpp and os_posix.cpp to use
>     os::malloc. If this is being called from a signal handler there's a
>     real risk of deadlock if we try to use malloc/free. I know Thomas
>     suggested this (and sorry I didn't notice it then) but I don't think
>     it is a good idea for the crash handler.
>
>
> Correct. Sorry, my fault, I was not clear enough. I meant for you to use
> the pure malloc(3), not os::malloc.

I was thinking both may be undesirable. I think my conservatism dial is 
up higher than yours :) Let's see what Staffan (or others) thinks. 
Perhaps a static buffer rather than either malloc or stack based?

Cheers,
David



> Using pure malloc is still a risk if the C-Heap is corrupted, but
> sometimes it makes sense for larger buffers. The risk of running into a
> corrupted C-Heap is sometimes offset by the risk of running out of stack
> space.
>
> Kind Regards, Thomas
>
>     Thanks,
>     David
>

From thomas.stuefe at gmail.com  Mon Dec  1 07:53:59 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 1 Dec 2014 08:53:59 +0100
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <547C1815.6050900@oracle.com>
References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com>
	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>
	<543B1FD6.3000200@oracle.com> <543CF553.80601@gmail.com>
	<543DC2BF.9050407@oracle.com> <543E80F8.3080204@gmail.com>
	<547330E5.1050708@gmail.com>
	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>
	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com> <547C079A.9020604@oracle.com>
	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
	<547C1815.6050900@oracle.com>
Message-ID: <CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>

On Mon, Dec 1, 2014 at 8:26 AM, David Holmes <david.holmes at oracle.com>
wrote:

> On 1/12/2014 5:18 PM, Thomas St?fe wrote:
>
>> David, Yasumasa,
>>
>>     Thanks. The formatting needs fixing up though, the p should line up
>>     with buffer.
>>
>>     I'm concerned by the changes in os_linux.cpp and os_posix.cpp to use
>>     os::malloc. If this is being called from a signal handler there's a
>>     real risk of deadlock if we try to use malloc/free. I know Thomas
>>     suggested this (and sorry I didn't notice it then) but I don't think
>>     it is a good idea for the crash handler.
>>
>>
>> Correct. Sorry, my fault, I was not clear enough. I meant for you to use
>> the pure malloc(3), not os::malloc.
>>
>
> I was thinking both may be undesirable. I think my conservatism dial is up
> higher than yours :) Let's see what Staffan (or others) thinks. Perhaps a
> static buffer rather than either malloc or stack based?
>
>
That would work, VmError::report_and_die() is singlethreaded. At least the
part which dumps out the core file name.

Another way would be to pre-calc the path at startup, in os::init() maybe.
You run the risk of the pattern changing during the lifetime of the process
though, but I guess that does not happen often.

But lets others decide. Too many ways to do this :)

Kind Regards, Thomas

From yasuenag at gmail.com  Mon Dec  1 09:45:17 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 01 Dec 2014 18:45:17 +0900
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>
References: <542C8274.3010809@gmail.com>	<54338B70.9080709@oracle.com>	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>	<543B1FD6.3000200@oracle.com>	<543CF553.80601@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>
	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>
Message-ID: <547C38AD.6050703@gmail.com>

Hi Thomas, David,

Sorry, I didn't think about async signal safety.

> That would work, VmError::report_and_die() is singlethreaded. At least the part which dumps out the core file name.

I think that signal handler (in this case) may run concurrency with
other thread.
If another thread calls malloc(3) in JNI, C Heap corruption may occur.

I want to rewrite a patch as below:

  - Use async signal safety functions.
    fopen -> open, fgets -> read, etc.

  - Use O_BUFLEN for buffer size.
    O_BUFLEN is defined to 2000 in ostream.hpp .
    This macro is used in various points. VMError::coredump_message is
    also defined with this value.

What do you think about this plan?


Thanks,

Yasumasa


(2014/12/01 16:53), Thomas St?fe wrote:
>
>
> On Mon, Dec 1, 2014 at 8:26 AM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>     On 1/12/2014 5:18 PM, Thomas St?fe wrote:
>
>         David, Yasumasa,
>
>              Thanks. The formatting needs fixing up though, the p should line up
>              with buffer.
>
>              I'm concerned by the changes in os_linux.cpp and os_posix.cpp to use
>              os::malloc. If this is being called from a signal handler there's a
>              real risk of deadlock if we try to use malloc/free. I know Thomas
>              suggested this (and sorry I didn't notice it then) but I don't think
>              it is a good idea for the crash handler.
>
>
>         Correct. Sorry, my fault, I was not clear enough. I meant for you to use
>         the pure malloc(3), not os::malloc.
>
>
>     I was thinking both may be undesirable. I think my conservatism dial is up higher than yours :) Let's see what Staffan (or others) thinks. Perhaps a static buffer rather than either malloc or stack based?
>
>
> That would work, VmError::report_and_die() is singlethreaded. At least the part which dumps out the core file name.
>
> Another way would be to pre-calc the path at startup, in os::init() maybe. You run the risk of the pattern changing during the lifetime of the process though, but I guess that does not happen often.
>
> But lets others decide. Too many ways to do this :)
>
> Kind Regards, Thomas
>

From thomas.stuefe at gmail.com  Mon Dec  1 12:57:44 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 1 Dec 2014 13:57:44 +0100
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <547C38AD.6050703@gmail.com>
References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com>
	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>
	<543B1FD6.3000200@oracle.com> <543CF553.80601@gmail.com>
	<543DC2BF.9050407@oracle.com> <543E80F8.3080204@gmail.com>
	<547330E5.1050708@gmail.com>
	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>
	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com> <547C079A.9020604@oracle.com>
	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
	<547C1815.6050900@oracle.com>
	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>
	<547C38AD.6050703@gmail.com>
Message-ID: <CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>

Hi Yasumasa,

On Mon, Dec 1, 2014 at 10:45 AM, Yasumasa Suenaga <yasuenag at gmail.com>
wrote:

> Hi Thomas, David,
>
> Sorry, I didn't think about async signal safety.
>
>  That would work, VmError::report_and_die() is singlethreaded. At least
>> the part which dumps out the core file name.
>>
>
> I think that signal handler (in this case) may run concurrency with
> other thread.
> If another thread calls malloc(3) in JNI, C Heap corruption may occur.
>
>
No, malloc(3) should be thread safe on our platforms. But this was not the
point. If I understood David right, he suggested using a static buffer
inside get_core_path() for assembling the core path, which would make
get_core_path() thread-unsafe (multiple threads calling it would get
garbled results). But as get_core_path() is only called from within
VmError::report_and_die() and that section is only ever executed by one
thread, Davids suggestion would still work.



> I want to rewrite a patch as below:
>
>  - Use async signal safety functions.
>    fopen -> open, fgets -> read, etc.
>
>  - Use O_BUFLEN for buffer size.
>    O_BUFLEN is defined to 2000 in ostream.hpp .
>    This macro is used in various points. VMError::coredump_message is
>    also defined with this value.
>
>
I think PATH_MAX is fine. I think O_BUFLEN was originally used as a max.
length of temporary buffers to assemble an output line. And then it spread
a bit. But your intend is to hold a path and using PATH_MAX clearly
documents this.
And, to really nitpick, right now you do not handle ERANGE with
get_current_path() (if the provided buffer is too small), which is probably
fine because it is improbable that a path is larger than PATH_MAX. But if
you change the size of the buffer to something which may be smaller than
PATH_MAX (O_BUFLEN), get_current_directory() may fail.

I like your patch, I think it could be a nice time safer when core_pattern
is something unusual. But I also see Staffans point of too-much-complexity.
So I will keep out of this discussion until the real Reviewers decided what
to do :)

Kind Regards, Thomas

From erik.joelsson at oracle.com  Mon Dec  1 13:27:10 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 01 Dec 2014 14:27:10 +0100
Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to
	better detect build errors
In-Reply-To: <54766066.9060206@oracle.com>
References: <5475EA0E.6040405@oracle.com> <54766066.9060206@oracle.com>
Message-ID: <547C6CAE.40600@oracle.com>

Hello,

New webrev, which addresses Magnus' concern below, and various fixes in 
Hotspot for incompatibilities with errexit.

Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8065576

For the LOG=trace issue Magnus described below, it was enough to just 
replace $$(BASH) with $$(SHELL) and things worked as expected for me.

In Hotspot there were several instances of run command X, followed by 
"if test $? = 0" (or something similar). I changed this to "if X; then" 
as errexit ignores commands that are part of if-statement tests.

Since this is now touching Hotspot makefiles, it will need to go in 
through a Hotspot group forest.

/Erik

On 2014-11-27 00:21, Magnus Ihse Bursie wrote:
>
> On 2014-11-26 15:56, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this build reliability fix. In JDK-8065138, we would 
>> have caught the error much faster if the build had failed instead of 
>> silently generating bad output. To avoid this in the future, this 
>> patch activates pipefail and errexit in the shell, when available. 
>> This means that long command lines, consisting of multiple commands, 
>> chained together either by pipes or ';', will fail the build 
>> regardless of which of the sub commands that failed. Currently, all 
>> but the last command would be ignored.
>>
>> Since these features my not always be available in all versions of 
>> bash, I added a check to configure for each of them and only enable 
>> them if they are available. I also had to fix some instances where we 
>> have 'grep' and 'find' returning non zero without it being an error.
>>
>> Thanks to Martin who suggested this in the first place.
>
> Thank you for fixing this so quickly!
>
> The webrev looks good as such, but I think you have missed how this 
> interact with common/bin/shell-tracer.sh. Which, unfortunately, is 
> non-trivial. :-(
>
> First of all, I realize that the existing line in MakeBase:
>     WRAPPER_SHELL:=$$(BASH) $$(SRC_ROOT)/common/bin/shell-tracer.sh 
> $$(if $$(findstring yes,$$(IS_GNU_TIME)),$$(TIME),-) 
> $$(OUTPUT_ROOT)/build-trace-time.log $$(BASH)
> is incorrect. (It's my bad...) The last $$(BASH) is supposed to be the 
> old value of $(SHELL), according to shell-tracer.sh. So, even before 
> your fix, it should have been $$(SHELL), not $$(BASH).
>
> However, even if you fix that, I'm not sure how this will work with a 
> $(SHELL) that has spaces in it. I think you can get it working it by 
> sending "$$(SHELL)" as last argument in WRAPPER_SHELL, and updating 
> shell-tracer.sh, so that the assignment to OLD_SHELL keeps the "" 
> around $3, but the calls to "$OLD_SHELL" (note, two places) removes 
> the "". But you'll have to verify that.
>
> /Magnus


From tim.bell at oracle.com  Mon Dec  1 15:38:46 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 01 Dec 2014 07:38:46 -0800
Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to
	better detect build errors
In-Reply-To: <547C6CAE.40600@oracle.com>
References: <5475EA0E.6040405@oracle.com> <54766066.9060206@oracle.com>
	<547C6CAE.40600@oracle.com>
Message-ID: <547C8B86.9090501@oracle.com>

Erik:

> New webrev, which addresses Magnus' concern below, and various fixes 
> in Hotspot for incompatibilities with errexit.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8065576

Looks good to me.

/Tim


> For the LOG=trace issue Magnus described below, it was enough to just 
> replace $$(BASH) with $$(SHELL) and things worked as expected for me.
>
> In Hotspot there were several instances of run command X, followed by 
> "if test $? = 0" (or something similar). I changed this to "if X; 
> then" as errexit ignores commands that are part of if-statement tests.
>
> Since this is now touching Hotspot makefiles, it will need to go in 
> through a Hotspot group forest.
>
> /Erik
>
> On 2014-11-27 00:21, Magnus Ihse Bursie wrote:
>>
>> On 2014-11-26 15:56, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Please review this build reliability fix. In JDK-8065138, we would 
>>> have caught the error much faster if the build had failed instead of 
>>> silently generating bad output. To avoid this in the future, this 
>>> patch activates pipefail and errexit in the shell, when available. 
>>> This means that long command lines, consisting of multiple commands, 
>>> chained together either by pipes or ';', will fail the build 
>>> regardless of which of the sub commands that failed. Currently, all 
>>> but the last command would be ignored.
>>>
>>> Since these features my not always be available in all versions of 
>>> bash, I added a check to configure for each of them and only enable 
>>> them if they are available. I also had to fix some instances where 
>>> we have 'grep' and 'find' returning non zero without it being an error.
>>>
>>> Thanks to Martin who suggested this in the first place.
>>
>> Thank you for fixing this so quickly!
>>
>> The webrev looks good as such, but I think you have missed how this 
>> interact with common/bin/shell-tracer.sh. Which, unfortunately, is 
>> non-trivial. :-(
>>
>> First of all, I realize that the existing line in MakeBase:
>>     WRAPPER_SHELL:=$$(BASH) $$(SRC_ROOT)/common/bin/shell-tracer.sh 
>> $$(if $$(findstring yes,$$(IS_GNU_TIME)),$$(TIME),-) 
>> $$(OUTPUT_ROOT)/build-trace-time.log $$(BASH)
>> is incorrect. (It's my bad...) The last $$(BASH) is supposed to be 
>> the old value of $(SHELL), according to shell-tracer.sh. So, even 
>> before your fix, it should have been $$(SHELL), not $$(BASH).
>>
>> However, even if you fix that, I'm not sure how this will work with a 
>> $(SHELL) that has spaces in it. I think you can get it working it by 
>> sending "$$(SHELL)" as last argument in WRAPPER_SHELL, and updating 
>> shell-tracer.sh, so that the assignment to OLD_SHELL keeps the "" 
>> around $3, but the calls to "$OLD_SHELL" (note, two places) removes 
>> the "". But you'll have to verify that.
>>
>> /Magnus
>


From coleen.phillimore at oracle.com  Mon Dec  1 15:48:33 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 01 Dec 2014 10:48:33 -0500
Subject: [8u-hs-dev] Backport RFR: 8057043: Type annotations not retained
	during class redefine / retransform
In-Reply-To: <545A1CCD.5080008@oracle.com>
References: <545A1CCD.5080008@oracle.com>
Message-ID: <547C8DD1.3080101@oracle.com>


Looks good Andreas.
Coleen

On 11/5/14, 7:49 AM, Andreas Eriksson wrote:
> Hi,
>
> This backport of JDK-8057043 
> <https://bugs.openjdk.java.net/browse/JDK-8057043> imported cleanly 
> from the jdk9 changeset:
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/06de05da6f2b
>
> Thanks,
> Andreas


From vladimir.kozlov at oracle.com  Mon Dec  1 17:17:08 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 01 Dec 2014 09:17:08 -0800
Subject: [8u40] Backport RFR: 8007993: hotspot.log w/ enabled
	LogCompilation can be an invalid XML
In-Reply-To: <547C0394.10902@oracle.com>
References: <547C0394.10902@oracle.com>
Message-ID: <547CA294.5040604@oracle.com>

Looks good.

Thanks,
Vladimir

On 11/30/14 9:58 PM, Tobias Hartmann wrote:
> Hi,
>
> please review the following backport request for 8u40.
>
> 8007993: hotspot.log w/ enabled LogCompilation can be an invalid XML
> https://bugs.openjdk.java.net/browse/JDK-8007993
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c13eb14ebf5c
> http://cr.openjdk.java.net/~thartmann/8007993/webrev.00/
>
> The changes were pushed to 9 on Wednesday and nightly testing showed no
> problems. The patch cleanly applies to 8u40.
>
> Thanks,
> Tobias
>

From igor.ignatyev at oracle.com  Mon Dec  1 20:52:59 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 01 Dec 2014 23:52:59 +0300
Subject: RFR (XS) : JDK-8066290 : Port JDK-8066191 into hotspot
Message-ID: <547CD52B.7040505@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8066290/webrev.00/
86 lines changed: 86 ins; 0 del; 0 mod;

Hi all,

please review porting TimeLimitedRunner from jdk testlibrary to hotspot.

bug: https://bugs.openjdk.java.net/browse/JDK-8066290
review: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029928.html

-- 
Thanks,
Igor

From roland.westrelin at oracle.com  Mon Dec  1 21:44:44 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 1 Dec 2014 22:44:44 +0100
Subject: [8u] backport of 8054478 and 8066045
Message-ID: <57CC8934-5CE9-4D60-930B-C53730D9909D@oracle.com>

8u backport request. 8054478 was pushed to jdk9 last week. 8066045 is a trivial fix because of a few failures 8054478 caused during nightly testing.

8054478 doesn?t apply cleanly to 8u.
https://bugs.openjdk.java.net/browse/JDK-8054478
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/49dd956bc8c0

Webrev with the change merged into 8u:
http://cr.openjdk.java.net/~roland/8054478/webrev.8u/

(castnode.[ch]pp don?t exist in 8u, allocation of node with new needs to be passed Compile object)

8066045 applies cleanly
https://bugs.openjdk.java.net/browse/JDK-8066045
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8394c315d83a

Note: 8054478 causes a performance regression:
https://bugs.openjdk.java.net/browse/JDK-8065965

Roland.

From vladimir.kozlov at oracle.com  Mon Dec  1 22:19:05 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 01 Dec 2014 14:19:05 -0800
Subject: RFR (XS) : JDK-8066290 : Port JDK-8066191 into hotspot
In-Reply-To: <547CD52B.7040505@oracle.com>
References: <547CD52B.7040505@oracle.com>
Message-ID: <547CE959.7030102@oracle.com>

Looks good.

Thanks,
Vladimir

On 12/1/14 12:52 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8066290/webrev.00/
> 86 lines changed: 86 ins; 0 del; 0 mod;
>
> Hi all,
>
> please review porting TimeLimitedRunner from jdk testlibrary to hotspot.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8066290
> review:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029928.html
>
>

From alejandro.murillo at oracle.com  Mon Dec  1 22:59:44 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Mon, 01 Dec 2014 15:59:44 -0700
Subject: [8u40] Backport RFR: 8058448: Disable JPRT submissions from the
	hotspot repo
Message-ID: <547CF2E0.1020100@oracle.com>


We need to disable JPRT submissions from the hotspot repo
on 8u releases, Can I get a quick review for this backport?

8058448: Disable JPRT submissions from the hotspot repo

http://cr.openjdk.java.net/~amurillo/8u40/8058448/

-- 
Alejandro


From vladimir.kozlov at oracle.com  Mon Dec  1 23:05:48 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 01 Dec 2014 15:05:48 -0800
Subject: [8u] backport of 8054478 and 8066045
In-Reply-To: <57CC8934-5CE9-4D60-930B-C53730D9909D@oracle.com>
References: <57CC8934-5CE9-4D60-930B-C53730D9909D@oracle.com>
Message-ID: <547CF44C.201@oracle.com>

Good. Create backport CR (8u60) for 8065965.

Thanks,
Vladimir

On 12/1/14 1:44 PM, Roland Westrelin wrote:
> 8u backport request. 8054478 was pushed to jdk9 last week. 8066045 is a trivial fix because of a few failures 8054478 caused during nightly testing.
>
> 8054478 doesn?t apply cleanly to 8u.
> https://bugs.openjdk.java.net/browse/JDK-8054478
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/49dd956bc8c0
>
> Webrev with the change merged into 8u:
> http://cr.openjdk.java.net/~roland/8054478/webrev.8u/
>
> (castnode.[ch]pp don?t exist in 8u, allocation of node with new needs to be passed Compile object)
>
> 8066045 applies cleanly
> https://bugs.openjdk.java.net/browse/JDK-8066045
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8394c315d83a
>
> Note: 8054478 causes a performance regression:
> https://bugs.openjdk.java.net/browse/JDK-8065965
>
> Roland.
>

From pointo1d at gmail.com  Mon Dec  1 16:01:06 2014
From: pointo1d at gmail.com (Dave Pointon)
Date: Mon, 1 Dec 2014 16:01:06 +0000
Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to
	better detect build errors
In-Reply-To: <547C6CAE.40600@oracle.com>
References: <5475EA0E.6040405@oracle.com> <54766066.9060206@oracle.com>
	<547C6CAE.40600@oracle.com>
Message-ID: <CACONdhKmHxyTA6Rvij7h2-D1jSFYJeyY8zMOe+WuZQSUOo+9dg@mail.gmail.com>

Hiya Erik ,

In every make recipe that I've ever written, I've yet to use the '... run
command ; if test $/; then ...' structure since I always run the shell with
'-e' option enabled and if the command returns a non-zero error status,
then shell picks it up - which explains why the majority of make(1) recipes
that I write utilise a case statement since the case "var in ... does not
return a non-zero error status for the shell to pick up on i.e. the shell
picks up on and fails the recipe if $VAR is unset in the command '... test
"x$$VAR" ...', whereas the same does not hold for the command '... case
"x$$VAR" ...' - the command result is left entirely for the recipe to deal
with as it sees fit.

Best rgds ,
--
Dave Pointon FIAP MBCS

Now I saw, tho' too late, the folly of beginning a work before we count the
cost and before we we judge rightly of our strength to go thro' with it -
Robinson Crusoe

On 1 December 2014 at 13:27, Erik Joelsson <erik.joelsson at oracle.com> wrote:

> Hello,
>
> New webrev, which addresses Magnus' concern below, and various fixes in
> Hotspot for incompatibilities with errexit.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8065576
>
> For the LOG=trace issue Magnus described below, it was enough to just
> replace $$(BASH) with $$(SHELL) and things worked as expected for me.
>
> In Hotspot there were several instances of run command X, followed by "if
> test $? = 0" (or something similar). I changed this to "if X; then" as
> errexit ignores commands that are part of if-statement tests.
>
> Since this is now touching Hotspot makefiles, it will need to go in
> through a Hotspot group forest.
>
> /Erik
>
> ?<snip>?
>

From david.holmes at oracle.com  Tue Dec  2 02:45:55 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 02 Dec 2014 12:45:55 +1000
Subject: [8u40] Backport RFR: 8058448: Disable JPRT submissions from the
	hotspot repo
In-Reply-To: <547CF2E0.1020100@oracle.com>
References: <547CF2E0.1020100@oracle.com>
Message-ID: <547D27E3.7070506@oracle.com>

Reviewed.

David

On 2/12/2014 8:59 AM, Alejandro E Murillo wrote:
>
> We need to disable JPRT submissions from the hotspot repo
> on 8u releases, Can I get a quick review for this backport?
>
> 8058448: Disable JPRT submissions from the hotspot repo
>
> http://cr.openjdk.java.net/~amurillo/8u40/8058448/
>

From tobias.hartmann at oracle.com  Tue Dec  2 08:51:15 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 02 Dec 2014 09:51:15 +0100
Subject: [8u40] Backport RFR: 8007993: hotspot.log w/ enabled
	LogCompilation can be an invalid XML
In-Reply-To: <547CA294.5040604@oracle.com>
References: <547C0394.10902@oracle.com> <547CA294.5040604@oracle.com>
Message-ID: <547D7D83.5040802@oracle.com>

Thanks, Vladimir.

Best,
Tobias

On 01.12.2014 18:17, Vladimir Kozlov wrote:
> Looks good.
> 
> Thanks,
> Vladimir
> 
> On 11/30/14 9:58 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following backport request for 8u40.
>>
>> 8007993: hotspot.log w/ enabled LogCompilation can be an invalid XML
>> https://bugs.openjdk.java.net/browse/JDK-8007993
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c13eb14ebf5c
>> http://cr.openjdk.java.net/~thartmann/8007993/webrev.00/
>>
>> The changes were pushed to 9 on Wednesday and nightly testing showed no
>> problems. The patch cleanly applies to 8u40.
>>
>> Thanks,
>> Tobias
>>

From roland.westrelin at oracle.com  Tue Dec  2 09:23:43 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 2 Dec 2014 10:23:43 +0100
Subject: [8u] backport of 8054478 and 8066045
In-Reply-To: <547CF44C.201@oracle.com>
References: <57CC8934-5CE9-4D60-930B-C53730D9909D@oracle.com>
	<547CF44C.201@oracle.com>
Message-ID: <104A37C5-56E4-40C7-92AC-DF7B5A23AFC5@oracle.com>

Thanks for the review, Vladimir.

Roland.

> On Dec 2, 2014, at 12:05 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Good. Create backport CR (8u60) for 8065965.
> 
> Thanks,
> Vladimir
> 
> On 12/1/14 1:44 PM, Roland Westrelin wrote:
>> 8u backport request. 8054478 was pushed to jdk9 last week. 8066045 is a trivial fix because of a few failures 8054478 caused during nightly testing.
>> 
>> 8054478 doesn?t apply cleanly to 8u.
>> https://bugs.openjdk.java.net/browse/JDK-8054478
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/49dd956bc8c0
>> 
>> Webrev with the change merged into 8u:
>> http://cr.openjdk.java.net/~roland/8054478/webrev.8u/
>> 
>> (castnode.[ch]pp don?t exist in 8u, allocation of node with new needs to be passed Compile object)
>> 
>> 8066045 applies cleanly
>> https://bugs.openjdk.java.net/browse/JDK-8066045
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8394c315d83a
>> 
>> Note: 8054478 causes a performance regression:
>> https://bugs.openjdk.java.net/browse/JDK-8065965
>> 
>> Roland.
>> 


From david.holmes at oracle.com  Tue Dec  2 09:40:45 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 02 Dec 2014 19:40:45 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
References: <542C8274.3010809@gmail.com>	<54338B70.9080709@oracle.com>	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>	<543B1FD6.3000200@oracle.com>	<543CF553.80601@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>
	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
Message-ID: <547D891D.7010809@oracle.com>

On 1/12/2014 10:57 PM, Thomas St?fe wrote:
> Hi Yasumasa,
>
> On Mon, Dec 1, 2014 at 10:45 AM, Yasumasa Suenaga <yasuenag at gmail.com
> <mailto:yasuenag at gmail.com>> wrote:
>
>     Hi Thomas, David,
>
>     Sorry, I didn't think about async signal safety.
>
>         That would work, VmError::report_and_die() is singlethreaded. At
>         least the part which dumps out the core file name.
>
>
>     I think that signal handler (in this case) may run concurrency with
>     other thread.
>     If another thread calls malloc(3) in JNI, C Heap corruption may occur.
>
>
> No, malloc(3) should be thread safe on our platforms. But this was not
> the point. If I understood David right, he suggested using a static
> buffer inside get_core_path() for assembling the core path, which would
> make get_core_path() thread-unsafe (multiple threads calling it would
> get garbled results). But as get_core_path() is only called from within
> VmError::report_and_die() and that section is only ever executed by one
> thread, Davids suggestion would still work.

Yes that is what I was suggesting.

>     I want to rewrite a patch as below:
>
>       - Use async signal safety functions.
>         fopen -> open, fgets -> read, etc.

This is commendable if it is practical, but error reporting already does 
many, many things that are not async-signal safe, so there is no need to 
go to extreme measures here.

>       - Use O_BUFLEN for buffer size.
>         O_BUFLEN is defined to 2000 in ostream.hpp .
>         This macro is used in various points. VMError::coredump_message is
>         also defined with this value.
>
>
> I think PATH_MAX is fine. I think O_BUFLEN was originally used as a max.
> length of temporary buffers to assemble an output line. And then it
> spread a bit. But your intend is to hold a path and using PATH_MAX
> clearly documents this.
> And, to really nitpick, right now you do not handle ERANGE with
> get_current_path() (if the provided buffer is too small), which is
> probably fine because it is improbable that a path is larger than
> PATH_MAX. But if you change the size of the buffer to something which
> may be smaller than PATH_MAX (O_BUFLEN), get_current_directory() may fail.
>
> I like your patch, I think it could be a nice time safer when
> core_pattern is something unusual. But I also see Staffans point of
> too-much-complexity. So I will keep out of this discussion until the
> real Reviewers decided what to do :)

I have a hard time evaluating the merits of the patch as I don't work in 
an environment where this extra info is needed. But I take it on good 
faith that it is useful for the context Yasumasa describes.

David

> Kind Regards, Thomas
>

From tatiana.pivovarova at oracle.com  Tue Dec  2 13:14:11 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Tue, 02 Dec 2014 16:14:11 +0300
Subject: [8u40] Request for approval: backports of 8062742(XS):
	compiler/EliminateAutoBox/UnsignedLoads.java fails with client vm
Message-ID: <547DBB23.3060503@oracle.com>

Hi all,

I would like to request a backport of the fix for JDK-8062742[1-4] to 
8u40. The original patch applied except changes in test/TEST.groups 
because this file doesn't contain such group "hotspot_compiler_2".

testing: jprt

[1] https://bugs.openjdk.java.net/browse/JDK-8062742
[2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/140f3e405a8a
[3] http://cr.openjdk.java.net/~iignatyev/tpivovarova/8062742/webrev.01/
[4] 
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016166.html

Thanks,
Tatiana

From yasuenag at gmail.com  Tue Dec  2 14:30:19 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 02 Dec 2014 23:30:19 +0900
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <547D891D.7010809@oracle.com>
References: <542C8274.3010809@gmail.com>	<54338B70.9080709@oracle.com>	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>	<543B1FD6.3000200@oracle.com>	<543CF553.80601@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>
	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
	<547D891D.7010809@oracle.com>
Message-ID: <547DCCFB.3050209@gmail.com>

Hi David, Thomas,

I've uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.04/

>>     I want to rewrite a patch as below:
>>
>>       - Use async signal safety functions.
>>         fopen -> open, fgets -> read, etc.
>
> This is commendable if it is practical, but error reporting already does many, many things that are not async-signal safe, so there is no need to go to extreme measures here.

I've used async-signal safe functions as possible.


>>       - Use O_BUFLEN for buffer size.
>>         O_BUFLEN is defined to 2000 in ostream.hpp .
>>         This macro is used in various points. VMError::coredump_message is
>>         also defined with this value.
>>
>>
>> I think PATH_MAX is fine. I think O_BUFLEN was originally used as a max.
>> length of temporary buffers to assemble an output line. And then it
>> spread a bit. But your intend is to hold a path and using PATH_MAX
>> clearly documents this.

I've used PATH_MAX again.


>> And, to really nitpick, right now you do not handle ERANGE with
>> get_current_path() (if the provided buffer is too small), which is
>> probably fine because it is improbable that a path is larger than
>> PATH_MAX. But if you change the size of the buffer to something which
>> may be smaller than PATH_MAX (O_BUFLEN), get_current_directory() may fail.

If get_current_path() call is failed in get_core_path(), get_core_path()
returns immediately with 0.
Caller (check_or_create_dump()) handles this result as illegal state.

get_current_path() calls getcwd() only and redirects result to caller.
So result of this function is NULL, we can judge getcwd() was finished with
error.
I think it is enough.


>> I like your patch, I think it could be a nice time safer when
>> core_pattern is something unusual. But I also see Staffans point of
>> too-much-complexity. So I will keep out of this discussion until the
>> real Reviewers decided what to do :)
>
> I have a hard time evaluating the merits of the patch as I don't work in an environment where this extra info is needed. But I take it on good faith that it is useful for the context Yasumasa describes.

I want to suggest to Java user where coredump is.
Modern Linux distribution(s) contains ABRT.
OS can dump corefile automatically despite a lack of setting coredump
resource by user.

I'm support engineer of Java. My customer says "coredump does not found.",
but coredump is saved by ABRT.
Thus I want them to know "coredump is available" through stderr and hs_err immediately.
I belive it is first step of troubleshoot.


Thanks,

Yasumasa


(2014/12/02 18:40), David Holmes wrote:
> On 1/12/2014 10:57 PM, Thomas St?fe wrote:
>> Hi Yasumasa,
>>
>> On Mon, Dec 1, 2014 at 10:45 AM, Yasumasa Suenaga <yasuenag at gmail.com
>> <mailto:yasuenag at gmail.com>> wrote:
>>
>>     Hi Thomas, David,
>>
>>     Sorry, I didn't think about async signal safety.
>>
>>         That would work, VmError::report_and_die() is singlethreaded. At
>>         least the part which dumps out the core file name.
>>
>>
>>     I think that signal handler (in this case) may run concurrency with
>>     other thread.
>>     If another thread calls malloc(3) in JNI, C Heap corruption may occur.
>>
>>
>> No, malloc(3) should be thread safe on our platforms. But this was not
>> the point. If I understood David right, he suggested using a static
>> buffer inside get_core_path() for assembling the core path, which would
>> make get_core_path() thread-unsafe (multiple threads calling it would
>> get garbled results). But as get_core_path() is only called from within
>> VmError::report_and_die() and that section is only ever executed by one
>> thread, Davids suggestion would still work.
>
> Yes that is what I was suggesting.
>
>>     I want to rewrite a patch as below:
>>
>>       - Use async signal safety functions.
>>         fopen -> open, fgets -> read, etc.
>
> This is commendable if it is practical, but error reporting already does many, many things that are not async-signal safe, so there is no need to go to extreme measures here.
>
>>       - Use O_BUFLEN for buffer size.
>>         O_BUFLEN is defined to 2000 in ostream.hpp .
>>         This macro is used in various points. VMError::coredump_message is
>>         also defined with this value.
>>
>>
>> I think PATH_MAX is fine. I think O_BUFLEN was originally used as a max.
>> length of temporary buffers to assemble an output line. And then it
>> spread a bit. But your intend is to hold a path and using PATH_MAX
>> clearly documents this.
>> And, to really nitpick, right now you do not handle ERANGE with
>> get_current_path() (if the provided buffer is too small), which is
>> probably fine because it is improbable that a path is larger than
>> PATH_MAX. But if you change the size of the buffer to something which
>> may be smaller than PATH_MAX (O_BUFLEN), get_current_directory() may fail.
>>
>> I like your patch, I think it could be a nice time safer when
>> core_pattern is something unusual. But I also see Staffans point of
>> too-much-complexity. So I will keep out of this discussion until the
>> real Reviewers decided what to do :)
>
> I have a hard time evaluating the merits of the patch as I don't work in an environment where this extra info is needed. But I take it on good faith that it is useful for the context Yasumasa describes.
>
> David
>
>> Kind Regards, Thomas
>>

From tobias.hartmann at oracle.com  Tue Dec  2 14:40:07 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 02 Dec 2014 15:40:07 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
Message-ID: <547DCF47.9000608@oracle.com>

Hi,

please review the following patch that copies the Whitebox testlibrary to
/jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).

The change leads to code duplication but in my opinion we should favour stable
tests over code duplication here. Hopefully, there is a solution to share the
library in the future.

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

Thanks,
Tobias

From vladimir.kozlov at oracle.com  Tue Dec  2 17:08:44 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 02 Dec 2014 09:08:44 -0800
Subject: [8u40] Request for approval: backports of 8062742(XS):
	compiler/EliminateAutoBox/UnsignedLoads.java fails with client vm
In-Reply-To: <547DBB23.3060503@oracle.com>
References: <547DBB23.3060503@oracle.com>
Message-ID: <547DF21C.1010003@oracle.com>

Looks good.

Thanks,
Vladimir

On 12/2/14 5:14 AM, Tatiana Pivovarova wrote:
> Hi all,
>
> I would like to request a backport of the fix for JDK-8062742[1-4] to 8u40. The original patch applied except changes in
> test/TEST.groups because this file doesn't contain such group "hotspot_compiler_2".
>
> testing: jprt
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8062742
> [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/140f3e405a8a
> [3] http://cr.openjdk.java.net/~iignatyev/tpivovarova/8062742/webrev.01/
> [4] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016166.html
>
> Thanks,
> Tatiana

From david.r.chase at oracle.com  Tue Dec  2 17:11:06 2014
From: david.r.chase at oracle.com (David Chase)
Date: Tue, 2 Dec 2014 12:11:06 -0500
Subject: [8u40] Request for approval: backports of 8062742(XS):
	compiler/EliminateAutoBox/UnsignedLoads.java fails with client vm
In-Reply-To: <547DBB23.3060503@oracle.com>
References: <547DBB23.3060503@oracle.com>
Message-ID: <053B111D-845C-4CD5-9DA8-D83D68716A76@oracle.com>

I am not a Reviewer, but I approve of this change.  It looks simple and safe.
(I think you still need one capital-R Reviewer)

David

On 2014-12-02, at 8:14 AM, Tatiana Pivovarova <tatiana.pivovarova at oracle.com> wrote:

> Hi all,
> 
> I would like to request a backport of the fix for JDK-8062742[1-4] to 8u40. The original patch applied except changes in test/TEST.groups because this file doesn't contain such group "hotspot_compiler_2".
> 
> testing: jprt
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8062742
> [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/140f3e405a8a
> [3] http://cr.openjdk.java.net/~iignatyev/tpivovarova/8062742/webrev.01/
> [4] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016166.html
> 
> Thanks,
> Tatiana


From mikael.vidstedt at oracle.com  Tue Dec  2 17:22:43 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Tue, 02 Dec 2014 09:22:43 -0800
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <547DCF47.9000608@oracle.com>
References: <547DCF47.9000608@oracle.com>
Message-ID: <547DF563.8080509@oracle.com>


Tobias,

Have you looked at what it would take to move the testlibrary somewhere 
where it can actually be shared instead? I think it would be extremely 
unfortunate to copy the code. I can't stress that enough.

Cheers,
Mikael

On 2014-12-02 06:40, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch that copies the Whitebox testlibrary to
> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>
> The change leads to code duplication but in my opinion we should favour stable
> tests over code duplication here. Hopefully, there is a solution to share the
> library in the future.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>
> Thanks,
> Tobias


From tatiana.pivovarova at oracle.com  Tue Dec  2 17:30:32 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Tue, 02 Dec 2014 20:30:32 +0300
Subject: [8u40] Request for approval: backports of 8062742(XS):
	compiler/EliminateAutoBox/UnsignedLoads.java fails with client vm
In-Reply-To: <547DF21C.1010003@oracle.com>
References: <547DBB23.3060503@oracle.com> <547DF21C.1010003@oracle.com>
Message-ID: <547DF738.6030909@oracle.com>

Hi Vladimir, David,

Thank for you reviews and quick approval!

Tatiana

On 12/02/2014 08:08 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 12/2/14 5:14 AM, Tatiana Pivovarova wrote:
>> Hi all,
>>
>> I would like to request a backport of the fix for JDK-8062742[1-4] to 
>> 8u40. The original patch applied except changes in
>> test/TEST.groups because this file doesn't contain such group 
>> "hotspot_compiler_2".
>>
>> testing: jprt
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8062742
>> [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/140f3e405a8a
>> [3] http://cr.openjdk.java.net/~iignatyev/tpivovarova/8062742/webrev.01/
>> [4] 
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-November/016166.html
>>
>> Thanks,
>> Tatiana


From tobias.hartmann at oracle.com  Tue Dec  2 17:37:28 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 02 Dec 2014 18:37:28 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <547DF563.8080509@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
Message-ID: <547DF8D8.8080601@oracle.com>

Hi Mikael,

On 02.12.2014 18:22, Mikael Vidstedt wrote:
> 
> Tobias,
> 
> Have you looked at what it would take to move the testlibrary somewhere where it
> can actually be shared instead? I think it would be extremely unfortunate to
> copy the code. I can't stress that enough.

I agree that having the testlibrary in a shared location is definitely the best
solution. Unfortunately, I don't know how to do that since we have to access the
library from different repositories and I don't think we want to have path
dependencies between the repositories.

Any suggestions?

Thanks,
Tobias

> 
> Cheers,
> Mikael
> 
> On 2014-12-02 06:40, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch that copies the Whitebox testlibrary to
>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>
>> The change leads to code duplication but in my opinion we should favour stable
>> tests over code duplication here. Hopefully, there is a solution to share the
>> library in the future.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>
>> Thanks,
>> Tobias
> 

From staffan.larsen at oracle.com  Tue Dec  2 19:25:17 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 2 Dec 2014 20:25:17 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <547DF8D8.8080601@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
Message-ID: <A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>


> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
> 
> Hi Mikael,
> 
> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>> 
>> Tobias,
>> 
>> Have you looked at what it would take to move the testlibrary somewhere where it
>> can actually be shared instead? I think it would be extremely unfortunate to
>> copy the code. I can't stress that enough.
> 
> I agree that having the testlibrary in a shared location is definitely the best
> solution. Unfortunately, I don't know how to do that since we have to access the
> library from different repositories and I don't think we want to have path
> dependencies between the repositories.
> 
> Any suggestions?

jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.

/Staffan

> 
> Thanks,
> Tobias
> 
>> 
>> Cheers,
>> Mikael
>> 
>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>> Hi,
>>> 
>>> please review the following patch that copies the Whitebox testlibrary to
>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>> 
>>> The change leads to code duplication but in my opinion we should favour stable
>>> tests over code duplication here. Hopefully, there is a solution to share the
>>> library in the future.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>> 
>>> Thanks,
>>> Tobias
>> 


From staffan.larsen at oracle.com  Tue Dec  2 19:45:34 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 2 Dec 2014 20:45:34 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
Message-ID: <B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>


> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> 
>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>> 
>> Hi Mikael,
>> 
>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>> 
>>> Tobias,
>>> 
>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>> can actually be shared instead? I think it would be extremely unfortunate to
>>> copy the code. I can't stress that enough.
>> 
>> I agree that having the testlibrary in a shared location is definitely the best
>> solution. Unfortunately, I don't know how to do that since we have to access the
>> library from different repositories and I don't think we want to have path
>> dependencies between the repositories.
>> 
>> Any suggestions?
> 
> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.

I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:

   @library /../../test/testlibrary

I don?t think that is what we want to do?

/Staffan


> 
> /Staffan
> 
>> 
>> Thanks,
>> Tobias
>> 
>>> 
>>> Cheers,
>>> Mikael
>>> 
>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>> Hi,
>>>> 
>>>> please review the following patch that copies the Whitebox testlibrary to
>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>> 
>>>> The change leads to code duplication but in my opinion we should favour stable
>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>> library in the future.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>> 
>>>> Thanks,
>>>> Tobias
>>> 
> 


From vladimir.kozlov at oracle.com  Tue Dec  2 19:53:55 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 02 Dec 2014 11:53:55 -0800
Subject: [8u40] backport RFR(S) 8065618: C2 RA incorrectly removes kill
	projections
Message-ID: <547E18D3.4020506@oracle.com>

8u40 backport request.  Changes were pushed into jdk9 more then week 
ago, no problems were found since then. Changes are NOT applied to 8u 
cleanly because of RA code refactoring in jdk9.

http://cr.openjdk.java.net/~kvn/8065618_8u/webrev/

jdk9:

http://cr.openjdk.java.net/~kvn/8065618/webrev/
https://bugs.openjdk.java.net/browse/JDK-8065618
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2aa1a6c41461

Thanks,
Vladimir

From roland.westrelin at oracle.com  Tue Dec  2 19:54:47 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 2 Dec 2014 20:54:47 +0100
Subject: [8u40] backport RFR(S) 8065618: C2 RA incorrectly removes kill
	projections
In-Reply-To: <547E18D3.4020506@oracle.com>
References: <547E18D3.4020506@oracle.com>
Message-ID: <4E0F6C49-1180-44E8-8919-B52D7A891DB5@oracle.com>

Good.

Roland.

> On Dec 2, 2014, at 8:53 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> 8u40 backport request.  Changes were pushed into jdk9 more then week ago, no problems were found since then. Changes are NOT applied to 8u cleanly because of RA code refactoring in jdk9.
> 
> http://cr.openjdk.java.net/~kvn/8065618_8u/webrev/
> 
> jdk9:
> 
> http://cr.openjdk.java.net/~kvn/8065618/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8065618
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2aa1a6c41461
> 
> Thanks,
> Vladimir


From tobias.hartmann at oracle.com  Tue Dec  2 19:54:55 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 02 Dec 2014 20:54:55 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
Message-ID: <547E190F.1090407@oracle.com>

Hi Staffan,

thanks for the feedback.

On 02.12.2014 20:45, Staffan Larsen wrote:
> 
>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>
>>
>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>
>>> Hi Mikael,
>>>
>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>
>>>> Tobias,
>>>>
>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>> copy the code. I can't stress that enough.
>>>
>>> I agree that having the testlibrary in a shared location is definitely the best
>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>> library from different repositories and I don't think we want to have path
>>> dependencies between the repositories.
>>>
>>> Any suggestions?
>>
>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
> 
> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
> 
>    @library /../../test/testlibrary
> 
> I don?t think that is what we want to do?

Yes, that's what I meant with "path dependencies between repositories". I don't
think this is a very robust solution.

Best,
Tobias

> 
> /Staffan
> 
> 
>>
>> /Staffan
>>
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>> Hi,
>>>>>
>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>
>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>> library in the future.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>
>>
> 

From vladimir.kozlov at oracle.com  Tue Dec  2 20:03:47 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 02 Dec 2014 12:03:47 -0800
Subject: [8u40] backport RFR(S) 8065618: C2 RA incorrectly removes kill
	projections
In-Reply-To: <4E0F6C49-1180-44E8-8919-B52D7A891DB5@oracle.com>
References: <547E18D3.4020506@oracle.com>
	<4E0F6C49-1180-44E8-8919-B52D7A891DB5@oracle.com>
Message-ID: <547E1B23.6080207@oracle.com>

Thank you, Roland

Vladimir

On 12/2/14 11:54 AM, Roland Westrelin wrote:
> Good.
>
> Roland.
>
>> On Dec 2, 2014, at 8:53 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> 8u40 backport request.  Changes were pushed into jdk9 more then week ago, no problems were found since then. Changes are NOT applied to 8u cleanly because of RA code refactoring in jdk9.
>>
>> http://cr.openjdk.java.net/~kvn/8065618_8u/webrev/
>>
>> jdk9:
>>
>> http://cr.openjdk.java.net/~kvn/8065618/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8065618
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2aa1a6c41461
>>
>> Thanks,
>> Vladimir
>

From vladimir.kozlov at oracle.com  Tue Dec  2 23:46:03 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 02 Dec 2014 15:46:03 -0800
Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base"
	and improve compressed heap handling.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap>	<5466A656.40707@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>
Message-ID: <547E4F3B.2090501@oracle.com>

This looks good to me. Someone in runtime/gc have to look on it too.

universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode"

we have:

java.vm.info=mixed mode, sharing

so we can have:

java.vm.compressedOopsMode=...

I am not expert in properties names but I don't want to have 'com.sap' 
in VM's property name.

virtualspace.cpp:

Could you fix release() - it does not reset _alignment?

In try_reserve_heap(), please, use (base == NULL) instead of (!base). 
And you don't need 'return;' in alignment check at the end of method.

In initialize_compressed_heap() again (!_base). You don't stop (check 
(base == NULL)) after successful unscaled, zerobased, disjointbase 
allocations. You need to separate them with the check:

+
+    }
+  }
+  if (_base == NULL) {
+
+    if (PrintCompressedOopsMode && Verbose) {
+      tty->print(" == Z E R O B A S E D ==\n");
+    }

and so on.

num_attempts calculation and while() loop are similar in unscaled and 
zerobased cases. Could you move it into a separate method?

In disjointbase while() condition no need for _base second check:

+           (_base == NULL ||
+            ((_base + size > (char *)OopEncodingHeapMax) &&

Thanks,
Vladimir

On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I prepared a new webrev trying to cover all the issues mentioned below.
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/
>
> I moved functionality from os.cpp and universe.cpp into
> ReservedHeapSpace::initialize_compressed_heap().
> This class offers to save _base and _special, which I would have to reimplement
> if I had improved the methods I had added to os.cpp to also allocate large page
> heaps.
> Anyways, I think this class is the right place to gather code trying to reserve
> the heap.
> Also, I get along without setting the shift, base, implicit_null_check etc. fields
> of Universe, so there is no unnecessary calling back and forth between the two
> classes.
> Universe gets the heap back, and then sets the properties it needs to configure
> the compressed oops.
> All code handling the noaccess prefix is in a single method, too.
>
> Best regards,
>    Goetz.
>
> Btw, I had to workaround a SS12u1 problem: it wouldn't compile
> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode.
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> Sent: Montag, 17. November 2014 09:33
> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>
> Hi Vladimir,
>
>> It is very significant rewriting and it takes time to evaluate it.
> Yes, I know ... and I don't want to push, but nevertheless a ping
> can be useful sometimes. Thanks a lot for looking at it.
>
>> And I would not say it is simpler then before :)
> If I fix what you propose it's gonna get even more simple ;)
>> These is what I found so far.
>
>> The idea to try to allocate in a range instead of just below
>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do
>> several attempts (3?) on non_PPC64 platforms too.
> Set to 3.
>
>> It is matter of preference but I am not comfortable with switch in loop.
>> For me sequential 'if (addr == 0)' checks is simpler.
> I'll fix this.
>
>> One thing worries me that you release found space and try to get it
>> again with ReservedHeapSpace. Is it possible to add new
>> ReservedHeapSpace ctor which simple use already allocated space?
> This was to keep diff's small, but I also think a new constructor is good.
> I'll fix this.
>
>> The next code in ReservedHeapSpace() is hard to understand ():
>> (UseCompressedOops && (requested_address == NULL ||
> requested_address+size > (char*)OopEncodingHeapMax) ?
>> may be move all this into noaccess_prefix_size() and add comments.
> I have to redo this anyways if I make new constructors.
>
>> Why you need prefix when requested_address == NULL?
> If we allocate with NULL, we most probably will get a heap where
> base != NULL and thus need a noaccess prefix.
>
>> Remove next comment in universe.cpp:
>> // SAPJVM GL 2014-09-22
> Removed.
>
>> Again you will release space so why bother to include space for classes?:
>> +          // For small heaps, save some space for compressed class pointer
>> +          // space so it can be decoded with no base.
> This was done like this before.  We must assure the upper bound of the
> heap is low enough that the compressed class space still fits in there.
>
> virtualspace.cpp
>
>> With new code size+noaccess_prefix could be requested. But later it is
>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty
>> non-protected page below heap.
> There's several points to this:
>   * Also if not protectable, the heap base has to be below the real start of the
>      heap.  Else the first object in the heap will be compressed to 'null'
>      and decompression will fail.
>   * If we don't reserve the memory other stuff can end up in this space. On
>      errors, if would be quite unexpected to find memory there.
>   * To get a heap for the new disjoint mode I must control the size of this.
>       Requesting a heap starting at (aligned base + prefix) is more likely to fail.
>   * The size for the prefix must anyways be considered when deciding whether the
>       heap is small enough to run with compressed oops.
> So distinguishing the case where we really can omit this would require
> quite some additional checks everywhere, and I thought it's not worth it.
>
> matcher.hpp
>
>> Universe::narrow_oop_use_implicit_null_checks() should be true for such
>> case too. So you can add new condition with || to existing ones. The
>> only condition you relax is base != NULL. Right?
> Yes, that's how it's intended.
>
> arguments.* files
>
>> Why you need PropertyList_add changes.
> Oh, the code using it got lost.  I commented on this in the description in the webrev.
> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode."
> When I know about the heap I do
>      Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode",
>                                                     narrow_oop_mode_to_string(narrow_oop_mode()),
>                                                     false));
> in universe.cpp.
> On some OSes it's deterministic which modes work, there we don't start such tests.
> Others, as you mentioned OSX,  are very indeterministic.  Here we save testruntime with this.
> But it's not that important.
> We can still parse the PrintCompresseOopsMode output after the test and discard the
> run.
>
>> Do you have platform specific changes?
> Yes, for ppc and aix.  I'll submit them once this is in.
>
>  From your other mail:
>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match
>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range.
> Good point.  I'll fix that in os::attempt_reserve_memory_in_range.
>
> I'll ping again once a new webrev is done!
>
> Best regards,
>    Goetz.
>
>
> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I need to improve a row of things around compressed oops heap handling
>> to achieve good performance on ppc.
>> I prepared a first webrev for review:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>>
>> A detailed technical description of the change is in the webrev and according bug.
>>
>> If requested, I will split the change into parts with more respective less impact on
>> non-ppc platforms.
>>
>> The change is derived from well-tested code in our VM.  Originally it was
>> crafted to require the least changes of  VM coding, I changed it to be better
>> streamlined with the VM.
>> I tested this change to deliver heaps at about the same addresses as before.
>> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
>> in a better compressed oops mode is found, though.
>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>>
>> Best regards,
>>     Goetz.
>>
>>

From volker.simonis at gmail.com  Wed Dec  3 11:06:53 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 3 Dec 2014 12:06:53 +0100
Subject: RFR(xs): 8065788: os::reserve_memory() on Windows should not
	assert that allocation size is aligned to OS allocation granularity.
In-Reply-To: <CAA-vtUxVPSSuC=s1s6_XWK8dd2n9PRFKCJpHAKmmS3r3vvSgRA@mail.gmail.com>
References: <CAA-vtUzbWWqynvha1B84vUx3V1e5CYRsBZaQ77RjL4x40BK29Q@mail.gmail.com>
	<c30ef566-9706-486b-8222-3d987076232e@default>
	<CAA-vtUxVPSSuC=s1s6_XWK8dd2n9PRFKCJpHAKmmS3r3vvSgRA@mail.gmail.com>
Message-ID: <CA+3eh135XT3DbCCgUjLfnc4avxwzb0khyHD=up1app6MwWPDaA@mail.gmail.com>

Hi Thomas,

I think your change is good although I'd prefer if you would assert
that the allocation size is aligned to page size (as you've already
proposed in your first mail). Callers of os::pd_reserve_memory() can
then be cleaned up to only "align_size_up" up to page size because
that's what gets reserved by the OS anyway.

Thank you and best regards,
Volker

PS: I'm only a reviewer but not a sponsor so any volunteers are still welcome:)


On Wed, Nov 26, 2014 at 12:50 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Thank you Markus!
>
> Could I have another Reviewer, and maybe someone who sponsors the change?
>
> Please note that this bug is not purely theoretical, but prevents us from
> reserving just one page on windows, which then leads to everyone aligning
> the reserve size up to vm_allocation_granularity() just to make the assert
> go away. Actually, I see a lot of "align_size_up()"s with
> vm_allocation_granularity() which may be unnecessary and could probably get
> cleaned up.
>
> Kind Regards, Thomas
>
> On Tue, Nov 25, 2014 at 11:21 AM, Markus Gr?nlund <
> markus.gronlund at oracle.com> wrote:
>
>> Hi Thomas,
>>
>> Thanks for finding and addressing this - looks good.
>>
>> Cheers
>> Markus
>>
>> -----Original Message-----
>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> Sent: den 24 november 2014 18:32
>> To: HotSpot Open Source Developers
>> Subject: RFR(xs): 8065788: os::reserve_memory() on Windows should not
>> assert that allocation size is aligned to OS allocation granularity.
>>
>> Hi,
>>
>> a very small change:
>>
>> Bug Report: https://bugs.openjdk.java.net/browse/JDK-8065788
>> WebRev:     http://cr.openjdk.java.net/~simonis/webrevs/8065788/
>>
>> os::reserve_memory() on Windows asserts that allocation size is allocated
>> to os::vm_allocation_granularity(). This assert is wrong and should be
>> removed.
>>
>> Allocation granularity affects the alignment of attach addresses, not of
>> the allocated size. The latter is aligned to page size, but asserting that
>> would be unnecessarily strict, as VirtualAlloc() will just quietly align
>> size up to page size.
>>
>> For details see MSDN on VirtualAlloc():
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx
>>
>>
>> Kind Regards,
>>
>> Thomas St?fe
>>

From goetz.lindenmaier at sap.com  Wed Dec  3 13:49:30 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 3 Dec 2014 13:49:30 +0000
Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base"
	and improve compressed heap handling.
In-Reply-To: <547E4F3B.2090501@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap>
	<5466A656.40707@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>
	<547E4F3B.2090501@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap>

Hi Vladimir,

thanks for looking at the change!  See my comments inline below.

I made a new webrev: 
http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
Incremental changes:
http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs.patch 

Best regards,
  Goetz.

> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
> Sent: Mittwoch, 3. Dezember 2014 00:46
> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>
> This looks good to me. Someone in runtime/gc have to look on it too.
>
> universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode"
> we have:
> java.vm.info=mixed mode, sharing
> so we can have:
>java.vm.compressedOopsMode=...
Yes, that's good for me. Fixed.

> I am not expert in properties names but I don't want to have 'com.sap' 
> in VM's property name.

> virtualspace.cpp:
>Could you fix release() - it does not reset _alignment?
Fixed.

> In try_reserve_heap(), please, use (base == NULL) instead of (!base). 
> And you don't need 'return;' in alignment check at the end of method.
Fixed.

> In initialize_compressed_heap() again (!_base). 
Fixed.

> You don't stop (check 
> (base == NULL)) after successful unscaled, zerobased, disjointbase 
> allocations. You need to separate them with the check:
>
> +
> +    }
> +  }
> +  if (_base == NULL) {
> +
> +    if (PrintCompressedOopsMode && Verbose) {
> +      tty->print(" == Z E R O B A S E D ==\n");
> +    }
> and so on.
No, I can't and don't want to check for _base != NULL.
I always keep the result of the last try, also if it didn't fulfil the required properties.
So I take that result and go into the next check.  That check might succeed 
with the heap allocated before.
This allows me to separate allocation and placement criteria, and to have the 
placement criteria checked in only one place (per mode).
Only for HeapBaseMinAddress I don't do it that way, I explicitly call release().
This way I can enforce mode heapbased.

> num_attempts calculation and while() loop are similar in unscaled and 
> zerobased cases. Could you move it into a separate method?
I can do that, but I don't like it as I have to pass in 7 parameters.
That makes the code not much more readable.  The function will look like this:

void ReserveHeapSpace::try_reserve_range(char *const highest_start, char *lowest_start, size_t attach_point_alignment,
                                         char *aligned_HBMA, size_t size, size_t alignment, bool large) {  
  guarantee(HeapSearchSteps > 0, "Don't set HeapSearchSteps to 0");
  
  const size_t attach_range = highest_start - lowest_start;  
  // Cap num_attempts at possible number. 
  // At least one is possible even for 0 sized attach range.
  const uint64_t num_attempts_possible = (attach_range / attach_point_alignment) + 1;
  const uint64_t num_attempts_to_try   = MIN2(HeapSearchSteps, num_attempts_possible);
  
  const size_t stepsize = align_size_up(attach_range / num_attempts_to_try, attach_point_alignment);
  
  // Try attach points from top to bottom.
  char* attach_point = highest_start;
  while (attach_point >= lowest_start  &&
         attach_point <= highest_start &&  // Avoid wrap around.
         (!_base || _base < aligned_HBMA || _base + size > (char *)UnscaledOopHeapMax)) {
    try_reserve_heap(size, alignment, large, attach_point);
    attach_point -= stepsize;
  }
}


> In disjointbase while() condition no need for _base second check:
> +           (_base == NULL ||
> +            ((_base + size > (char *)OopEncodingHeapMax) &&
I need this for the same reason as above:  This is the check for successful allocation.



Thanks,
Vladimir

On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I prepared a new webrev trying to cover all the issues mentioned below.
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/
>
> I moved functionality from os.cpp and universe.cpp into
> ReservedHeapSpace::initialize_compressed_heap().
> This class offers to save _base and _special, which I would have to reimplement
> if I had improved the methods I had added to os.cpp to also allocate large page
> heaps.
> Anyways, I think this class is the right place to gather code trying to reserve
> the heap.
> Also, I get along without setting the shift, base, implicit_null_check etc. fields
> of Universe, so there is no unnecessary calling back and forth between the two
> classes.
> Universe gets the heap back, and then sets the properties it needs to configure
> the compressed oops.
> All code handling the noaccess prefix is in a single method, too.
>
> Best regards,
>    Goetz.
>
> Btw, I had to workaround a SS12u1 problem: it wouldn't compile
> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode.
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> Sent: Montag, 17. November 2014 09:33
> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>
> Hi Vladimir,
>
>> It is very significant rewriting and it takes time to evaluate it.
> Yes, I know ... and I don't want to push, but nevertheless a ping
> can be useful sometimes. Thanks a lot for looking at it.
>
>> And I would not say it is simpler then before :)
> If I fix what you propose it's gonna get even more simple ;)
>> These is what I found so far.
>
>> The idea to try to allocate in a range instead of just below
>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do
>> several attempts (3?) on non_PPC64 platforms too.
> Set to 3.
>
>> It is matter of preference but I am not comfortable with switch in loop.
>> For me sequential 'if (addr == 0)' checks is simpler.
> I'll fix this.
>
>> One thing worries me that you release found space and try to get it
>> again with ReservedHeapSpace. Is it possible to add new
>> ReservedHeapSpace ctor which simple use already allocated space?
> This was to keep diff's small, but I also think a new constructor is good.
> I'll fix this.
>
>> The next code in ReservedHeapSpace() is hard to understand ():
>> (UseCompressedOops && (requested_address == NULL ||
> requested_address+size > (char*)OopEncodingHeapMax) ?
>> may be move all this into noaccess_prefix_size() and add comments.
> I have to redo this anyways if I make new constructors.
>
>> Why you need prefix when requested_address == NULL?
> If we allocate with NULL, we most probably will get a heap where
> base != NULL and thus need a noaccess prefix.
>
>> Remove next comment in universe.cpp:
>> // SAPJVM GL 2014-09-22
> Removed.
>
>> Again you will release space so why bother to include space for classes?:
>> +          // For small heaps, save some space for compressed class pointer
>> +          // space so it can be decoded with no base.
> This was done like this before.  We must assure the upper bound of the
> heap is low enough that the compressed class space still fits in there.
>
> virtualspace.cpp
>
>> With new code size+noaccess_prefix could be requested. But later it is
>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty
>> non-protected page below heap.
> There's several points to this:
>   * Also if not protectable, the heap base has to be below the real start of the
>      heap.  Else the first object in the heap will be compressed to 'null'
>      and decompression will fail.
>   * If we don't reserve the memory other stuff can end up in this space. On
>      errors, if would be quite unexpected to find memory there.
>   * To get a heap for the new disjoint mode I must control the size of this.
>       Requesting a heap starting at (aligned base + prefix) is more likely to fail.
>   * The size for the prefix must anyways be considered when deciding whether the
>       heap is small enough to run with compressed oops.
> So distinguishing the case where we really can omit this would require
> quite some additional checks everywhere, and I thought it's not worth it.
>
> matcher.hpp
>
>> Universe::narrow_oop_use_implicit_null_checks() should be true for such
>> case too. So you can add new condition with || to existing ones. The
>> only condition you relax is base != NULL. Right?
> Yes, that's how it's intended.
>
> arguments.* files
>
>> Why you need PropertyList_add changes.
> Oh, the code using it got lost.  I commented on this in the description in the webrev.
> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode."
> When I know about the heap I do
>      Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode",
>                                                     narrow_oop_mode_to_string(narrow_oop_mode()),
>                                                     false));
> in universe.cpp.
> On some OSes it's deterministic which modes work, there we don't start such tests.
> Others, as you mentioned OSX,  are very indeterministic.  Here we save testruntime with this.
> But it's not that important.
> We can still parse the PrintCompresseOopsMode output after the test and discard the
> run.
>
>> Do you have platform specific changes?
> Yes, for ppc and aix.  I'll submit them once this is in.
>
>  From your other mail:
>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match
>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range.
> Good point.  I'll fix that in os::attempt_reserve_memory_in_range.
>
> I'll ping again once a new webrev is done!
>
> Best regards,
>    Goetz.
>
>
> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I need to improve a row of things around compressed oops heap handling
>> to achieve good performance on ppc.
>> I prepared a first webrev for review:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>>
>> A detailed technical description of the change is in the webrev and according bug.
>>
>> If requested, I will split the change into parts with more respective less impact on
>> non-ppc platforms.
>>
>> The change is derived from well-tested code in our VM.  Originally it was
>> crafted to require the least changes of  VM coding, I changed it to be better
>> streamlined with the VM.
>> I tested this change to deliver heaps at about the same addresses as before.
>> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
>> in a better compressed oops mode is found, though.
>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>>
>> Best regards,
>>     Goetz.
>>
>>

From stefan.karlsson at oracle.com  Wed Dec  3 14:21:34 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 03 Dec 2014 09:21:34 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when _method
	is NULL
Message-ID: <547F1C6E.1070701@oracle.com>

Hi all,

Please, review this patch to fix an issue where the GC encounters an 
InstanceKlass before it has come far enough in the class loading process.

Some background to the fix:

When the JVM loads classes it has to keep track of the allocated 
Metadata, and in the event of an exception deallocate the Metadata. The 
ClassFileParser saves the Metadata pointers so that it knows what needs 
to be deallocated. When the class loading has come far enough there's a 
point were the GC can take over the ownership of the Metadata and do 
deallocation of the both the InstanceKlass and the Metadata, if needed. 
At that point the Metadata pointers in the ClassFileParser are cleared 
and transfered over to the InstanceKlass.

Most Metadata allocations happen before the InstanceKlass is allocated, 
but the Annotations are allocated after the InstanceKlass but before the 
transferal and clearing of the Metadata pointers in the ClassFileParser. 
If the GC stops when allocating the Annotations, it will likely find 
this InstanceKlass and assume that the Metadata are correctly setup. 
This is exactly what's happening in the bug report. The GC finds that 
the _methods array, unexpectedly, points to NULL.

The proposed solution to this problem is to allocate the Annotations 
before the InstanceKlass is allocated.

http://cr.openjdk.java.net/~stefank/8065634/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8065634

Testing:
JPRT, parallel_class_loading testlist, Aurora adhoc run

Thanks,
StefanK

From thomas.stuefe at gmail.com  Wed Dec  3 16:18:46 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 3 Dec 2014 17:18:46 +0100
Subject: RFR(xs): 8065788: os::reserve_memory() on Windows should not
	assert that allocation size is aligned to OS allocation granularity.
In-Reply-To: <CA+3eh135XT3DbCCgUjLfnc4avxwzb0khyHD=up1app6MwWPDaA@mail.gmail.com>
References: <CAA-vtUzbWWqynvha1B84vUx3V1e5CYRsBZaQ77RjL4x40BK29Q@mail.gmail.com>
	<c30ef566-9706-486b-8222-3d987076232e@default>
	<CAA-vtUxVPSSuC=s1s6_XWK8dd2n9PRFKCJpHAKmmS3r3vvSgRA@mail.gmail.com>
	<CA+3eh135XT3DbCCgUjLfnc4avxwzb0khyHD=up1app6MwWPDaA@mail.gmail.com>
Message-ID: <CAA-vtUz5q3iEEUbtq1rbbHUSp6g5WgA+UVPDiEr7WG=fm2j=ZA@mail.gmail.com>

Hi Volker, thanks for looking into this!

http://cr.openjdk.java.net/~stuefe/webrevs/8065788/webrev.02/webrev/

According to your proposal I changed the code to assert for pagesize.

This also should not cause any issues, because before we enforced alignment
to allocation granularity, which is a multiple of the page size.

Still looking for a sponsor :)

Kind Regards, Thomas

On Wed, Dec 3, 2014 at 12:06 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Thomas,
>
> I think your change is good although I'd prefer if you would assert
> that the allocation size is aligned to page size (as you've already
> proposed in your first mail). Callers of os::pd_reserve_memory() can
> then be cleaned up to only "align_size_up" up to page size because
> that's what gets reserved by the OS anyway.
>
> Thank you and best regards,
> Volker
>
> PS: I'm only a reviewer but not a sponsor so any volunteers are still
> welcome:)
>
>
> On Wed, Nov 26, 2014 at 12:50 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> > Thank you Markus!
> >
> > Could I have another Reviewer, and maybe someone who sponsors the change?
> >
> > Please note that this bug is not purely theoretical, but prevents us from
> > reserving just one page on windows, which then leads to everyone aligning
> > the reserve size up to vm_allocation_granularity() just to make the
> assert
> > go away. Actually, I see a lot of "align_size_up()"s with
> > vm_allocation_granularity() which may be unnecessary and could probably
> get
> > cleaned up.
> >
> > Kind Regards, Thomas
> >
> > On Tue, Nov 25, 2014 at 11:21 AM, Markus Gr?nlund <
> > markus.gronlund at oracle.com> wrote:
> >
> >> Hi Thomas,
> >>
> >> Thanks for finding and addressing this - looks good.
> >>
> >> Cheers
> >> Markus
> >>
> >> -----Original Message-----
> >> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> >> Sent: den 24 november 2014 18:32
> >> To: HotSpot Open Source Developers
> >> Subject: RFR(xs): 8065788: os::reserve_memory() on Windows should not
> >> assert that allocation size is aligned to OS allocation granularity.
> >>
> >> Hi,
> >>
> >> a very small change:
> >>
> >> Bug Report: https://bugs.openjdk.java.net/browse/JDK-8065788
> >> WebRev:     http://cr.openjdk.java.net/~simonis/webrevs/8065788/
> >>
> >> os::reserve_memory() on Windows asserts that allocation size is
> allocated
> >> to os::vm_allocation_granularity(). This assert is wrong and should be
> >> removed.
> >>
> >> Allocation granularity affects the alignment of attach addresses, not of
> >> the allocated size. The latter is aligned to page size, but asserting
> that
> >> would be unnecessarily strict, as VirtualAlloc() will just quietly align
> >> size up to page size.
> >>
> >> For details see MSDN on VirtualAlloc():
> >>
> >>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx
> >>
> >>
> >> Kind Regards,
> >>
> >> Thomas St?fe
> >>
>

From coleen.phillimore at oracle.com  Wed Dec  3 16:59:58 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 03 Dec 2014 11:59:58 -0500
Subject: RFR 8066171: Out of order with Metaspace allocation lock
Message-ID: <547F418E.6010301@oracle.com>

Summary: Lock resolved_references instead.

When I took out the constant pool mutex, I thought I could use the 
metaspace to synchronize this code sequence, but the metaspace_lock is 
out of order with the DirtyCardQ_CBL_mon lock that can sometimes be 
taken with obj_at_put() in an object array.   Since there is always a 
resolved_reference objArrayOop attached to this class, we can lock this 
for this cpCache entry.  John and the JSR292 guys tell me that this code 
sequence needs to be locked against multiple setters.

Tested with jdk/test/java/lang/invoke tests, nsk.quick.testlist.

open webrev at http://cr.openjdk.java.net/~coleenp/8066171/
bug link https://bugs.openjdk.java.net/browse/JDK-8066171

Thanks,
Coleen

From coleen.phillimore at oracle.com  Wed Dec  3 17:29:16 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 03 Dec 2014 12:29:16 -0500
Subject: RFR 8066171: Out of order with Metaspace allocation lock
In-Reply-To: <547F418E.6010301@oracle.com>
References: <547F418E.6010301@oracle.com>
Message-ID: <547F486C.7000005@oracle.com>


I forgot to mention I tested by locking the DirtyCardQ_CBL_mon lock 
unconditionally in ConstantPoolCacheEntry::set_method_handle_common.
thanks,
Coleen

On 12/3/14, 11:59 AM, Coleen Phillimore wrote:
> Summary: Lock resolved_references instead.
>
> When I took out the constant pool mutex, I thought I could use the 
> metaspace to synchronize this code sequence, but the metaspace_lock is 
> out of order with the DirtyCardQ_CBL_mon lock that can sometimes be 
> taken with obj_at_put() in an object array.   Since there is always a 
> resolved_reference objArrayOop attached to this class, we can lock 
> this for this cpCache entry. John and the JSR292 guys tell me that 
> this code sequence needs to be locked against multiple setters.
>
> Tested with jdk/test/java/lang/invoke tests, nsk.quick.testlist.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8066171/
> bug link https://bugs.openjdk.java.net/browse/JDK-8066171
>
> Thanks,
> Coleen


From vladimir.kozlov at oracle.com  Wed Dec  3 17:32:04 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 03 Dec 2014 09:32:04 -0800
Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base"
	and improve compressed heap handling.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap>	<5466A656.40707@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>
	<547E4F3B.2090501@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap>
Message-ID: <547F4914.1030904@oracle.com>

Comments are below.

On 12/3/14 5:49 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
> thanks for looking at the change!  See my comments inline below.
>
> I made a new webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
> Incremental changes:
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs.patch
>
> Best regards,
>    Goetz.
>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Mittwoch, 3. Dezember 2014 00:46
>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>
>> This looks good to me. Someone in runtime/gc have to look on it too.
>>
>> universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode"
>> we have:
>> java.vm.info=mixed mode, sharing
>> so we can have:
>> java.vm.compressedOopsMode=...
> Yes, that's good for me. Fixed.
>
>> I am not expert in properties names but I don't want to have 'com.sap'
>> in VM's property name.
>
>> virtualspace.cpp:
>> Could you fix release() - it does not reset _alignment?
> Fixed.
>
>> In try_reserve_heap(), please, use (base == NULL) instead of (!base).
>> And you don't need 'return;' in alignment check at the end of method.
> Fixed.
>
>> In initialize_compressed_heap() again (!_base).
> Fixed.
>
>> You don't stop (check
>> (base == NULL)) after successful unscaled, zerobased, disjointbase
>> allocations. You need to separate them with the check:
>>
>> +
>> +    }
>> +  }
>> +  if (_base == NULL) {
>> +
>> +    if (PrintCompressedOopsMode && Verbose) {
>> +      tty->print(" == Z E R O B A S E D ==\n");
>> +    }
>> and so on.
> No, I can't and don't want to check for _base != NULL.
> I always keep the result of the last try, also if it didn't fulfil the required properties.
> So I take that result and go into the next check.  That check might succeed
> with the heap allocated before.
> This allows me to separate allocation and placement criteria, and to have the
> placement criteria checked in only one place (per mode).
> Only for HeapBaseMinAddress I don't do it that way, I explicitly call release().
> This way I can enforce mode heapbased.

I see what you are saying. It was not clear from comments what is going on.
Add more extending comment explaining that.

>
>> num_attempts calculation and while() loop are similar in unscaled and
>> zerobased cases. Could you move it into a separate method?
> I can do that, but I don't like it as I have to pass in 7 parameters.

You need an other parameter to pass UnscaledOopHeapMax or zerobased_max.

> That makes the code not much more readable.  The function will look like this:

I think initialize_compressed_heap() is more readable now.

>
> void ReserveHeapSpace::try_reserve_range(char *const highest_start, char *lowest_start, size_t attach_point_alignment,
>                                           char *aligned_HBMA, size_t size, size_t alignment, bool large) {
>    guarantee(HeapSearchSteps > 0, "Don't set HeapSearchSteps to 0");
>
>    const size_t attach_range = highest_start - lowest_start;
>    // Cap num_attempts at possible number.
>    // At least one is possible even for 0 sized attach range.
>    const uint64_t num_attempts_possible = (attach_range / attach_point_alignment) + 1;
>    const uint64_t num_attempts_to_try   = MIN2(HeapSearchSteps, num_attempts_possible);
>
>    const size_t stepsize = align_size_up(attach_range / num_attempts_to_try, attach_point_alignment);
>
>    // Try attach points from top to bottom.
>    char* attach_point = highest_start;
>    while (attach_point >= lowest_start  &&
>           attach_point <= highest_start &&  // Avoid wrap around.
>           (!_base || _base < aligned_HBMA || _base + size > (char *)UnscaledOopHeapMax)) {
>      try_reserve_heap(size, alignment, large, attach_point);
>      attach_point -= stepsize;
>    }
> }
>
>
>> In disjointbase while() condition no need for _base second check:
>> +           (_base == NULL ||
>> +            ((_base + size > (char *)OopEncodingHeapMax) &&
> I need this for the same reason as above:  This is the check for successful allocation.

I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?

Thanks,
Vladimir

>
>
>
> Thanks,
> Vladimir
>
> On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> I prepared a new webrev trying to cover all the issues mentioned below.
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/
>>
>> I moved functionality from os.cpp and universe.cpp into
>> ReservedHeapSpace::initialize_compressed_heap().
>> This class offers to save _base and _special, which I would have to reimplement
>> if I had improved the methods I had added to os.cpp to also allocate large page
>> heaps.
>> Anyways, I think this class is the right place to gather code trying to reserve
>> the heap.
>> Also, I get along without setting the shift, base, implicit_null_check etc. fields
>> of Universe, so there is no unnecessary calling back and forth between the two
>> classes.
>> Universe gets the heap back, and then sets the properties it needs to configure
>> the compressed oops.
>> All code handling the noaccess prefix is in a single method, too.
>>
>> Best regards,
>>     Goetz.
>>
>> Btw, I had to workaround a SS12u1 problem: it wouldn't compile
>> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode.
>>
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>> Sent: Montag, 17. November 2014 09:33
>> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
>> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>
>> Hi Vladimir,
>>
>>> It is very significant rewriting and it takes time to evaluate it.
>> Yes, I know ... and I don't want to push, but nevertheless a ping
>> can be useful sometimes. Thanks a lot for looking at it.
>>
>>> And I would not say it is simpler then before :)
>> If I fix what you propose it's gonna get even more simple ;)
>>> These is what I found so far.
>>
>>> The idea to try to allocate in a range instead of just below
>>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do
>>> several attempts (3?) on non_PPC64 platforms too.
>> Set to 3.
>>
>>> It is matter of preference but I am not comfortable with switch in loop.
>>> For me sequential 'if (addr == 0)' checks is simpler.
>> I'll fix this.
>>
>>> One thing worries me that you release found space and try to get it
>>> again with ReservedHeapSpace. Is it possible to add new
>>> ReservedHeapSpace ctor which simple use already allocated space?
>> This was to keep diff's small, but I also think a new constructor is good.
>> I'll fix this.
>>
>>> The next code in ReservedHeapSpace() is hard to understand ():
>>> (UseCompressedOops && (requested_address == NULL ||
>> requested_address+size > (char*)OopEncodingHeapMax) ?
>>> may be move all this into noaccess_prefix_size() and add comments.
>> I have to redo this anyways if I make new constructors.
>>
>>> Why you need prefix when requested_address == NULL?
>> If we allocate with NULL, we most probably will get a heap where
>> base != NULL and thus need a noaccess prefix.
>>
>>> Remove next comment in universe.cpp:
>>> // SAPJVM GL 2014-09-22
>> Removed.
>>
>>> Again you will release space so why bother to include space for classes?:
>>> +          // For small heaps, save some space for compressed class pointer
>>> +          // space so it can be decoded with no base.
>> This was done like this before.  We must assure the upper bound of the
>> heap is low enough that the compressed class space still fits in there.
>>
>> virtualspace.cpp
>>
>>> With new code size+noaccess_prefix could be requested. But later it is
>>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty
>>> non-protected page below heap.
>> There's several points to this:
>>    * Also if not protectable, the heap base has to be below the real start of the
>>       heap.  Else the first object in the heap will be compressed to 'null'
>>       and decompression will fail.
>>    * If we don't reserve the memory other stuff can end up in this space. On
>>       errors, if would be quite unexpected to find memory there.
>>    * To get a heap for the new disjoint mode I must control the size of this.
>>        Requesting a heap starting at (aligned base + prefix) is more likely to fail.
>>    * The size for the prefix must anyways be considered when deciding whether the
>>        heap is small enough to run with compressed oops.
>> So distinguishing the case where we really can omit this would require
>> quite some additional checks everywhere, and I thought it's not worth it.
>>
>> matcher.hpp
>>
>>> Universe::narrow_oop_use_implicit_null_checks() should be true for such
>>> case too. So you can add new condition with || to existing ones. The
>>> only condition you relax is base != NULL. Right?
>> Yes, that's how it's intended.
>>
>> arguments.* files
>>
>>> Why you need PropertyList_add changes.
>> Oh, the code using it got lost.  I commented on this in the description in the webrev.
>> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode."
>> When I know about the heap I do
>>       Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode",
>>                                                      narrow_oop_mode_to_string(narrow_oop_mode()),
>>                                                      false));
>> in universe.cpp.
>> On some OSes it's deterministic which modes work, there we don't start such tests.
>> Others, as you mentioned OSX,  are very indeterministic.  Here we save testruntime with this.
>> But it's not that important.
>> We can still parse the PrintCompresseOopsMode output after the test and discard the
>> run.
>>
>>> Do you have platform specific changes?
>> Yes, for ppc and aix.  I'll submit them once this is in.
>>
>>   From your other mail:
>>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match
>>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range.
>> Good point.  I'll fix that in os::attempt_reserve_memory_in_range.
>>
>> I'll ping again once a new webrev is done!
>>
>> Best regards,
>>     Goetz.
>>
>>
>> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I need to improve a row of things around compressed oops heap handling
>>> to achieve good performance on ppc.
>>> I prepared a first webrev for review:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>>>
>>> A detailed technical description of the change is in the webrev and according bug.
>>>
>>> If requested, I will split the change into parts with more respective less impact on
>>> non-ppc platforms.
>>>
>>> The change is derived from well-tested code in our VM.  Originally it was
>>> crafted to require the least changes of  VM coding, I changed it to be better
>>> streamlined with the VM.
>>> I tested this change to deliver heaps at about the same addresses as before.
>>> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
>>> in a better compressed oops mode is found, though.
>>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>

From christian.thalinger at oracle.com  Wed Dec  3 18:16:23 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 3 Dec 2014 10:16:23 -0800
Subject: RFR 8066171: Out of order with Metaspace allocation lock
In-Reply-To: <547F486C.7000005@oracle.com>
References: <547F418E.6010301@oracle.com> <547F486C.7000005@oracle.com>
Message-ID: <D6BFEBBC-4CAF-4889-A60F-2EED361B6669@oracle.com>

Looks good.

> On Dec 3, 2014, at 9:29 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> I forgot to mention I tested by locking the DirtyCardQ_CBL_mon lock unconditionally in ConstantPoolCacheEntry::set_method_handle_common.
> thanks,
> Coleen
> 
> On 12/3/14, 11:59 AM, Coleen Phillimore wrote:
>> Summary: Lock resolved_references instead.
>> 
>> When I took out the constant pool mutex, I thought I could use the metaspace to synchronize this code sequence, but the metaspace_lock is out of order with the DirtyCardQ_CBL_mon lock that can sometimes be taken with obj_at_put() in an object array.   Since there is always a resolved_reference objArrayOop attached to this class, we can lock this for this cpCache entry. John and the JSR292 guys tell me that this code sequence needs to be locked against multiple setters.
>> 
>> Tested with jdk/test/java/lang/invoke tests, nsk.quick.testlist.
>> 
>> open webrev at http://cr.openjdk.java.net/~coleenp/8066171/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8066171
>> 
>> Thanks,
>> Coleen
> 


From coleen.phillimore at oracle.com  Wed Dec  3 19:12:08 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 03 Dec 2014 14:12:08 -0500
Subject: RFR 8066171: Out of order with Metaspace allocation lock
In-Reply-To: <D6BFEBBC-4CAF-4889-A60F-2EED361B6669@oracle.com>
References: <547F418E.6010301@oracle.com> <547F486C.7000005@oracle.com>
	<D6BFEBBC-4CAF-4889-A60F-2EED361B6669@oracle.com>
Message-ID: <547F6088.7030303@oracle.com>


Thanks!
Coleen

On 12/3/14, 1:16 PM, Christian Thalinger wrote:
> Looks good.
>
>> On Dec 3, 2014, at 9:29 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>>
>>
>> I forgot to mention I tested by locking the DirtyCardQ_CBL_mon lock unconditionally in ConstantPoolCacheEntry::set_method_handle_common.
>> thanks,
>> Coleen
>>
>> On 12/3/14, 11:59 AM, Coleen Phillimore wrote:
>>> Summary: Lock resolved_references instead.
>>>
>>> When I took out the constant pool mutex, I thought I could use the metaspace to synchronize this code sequence, but the metaspace_lock is out of order with the DirtyCardQ_CBL_mon lock that can sometimes be taken with obj_at_put() in an object array.   Since there is always a resolved_reference objArrayOop attached to this class, we can lock this for this cpCache entry. John and the JSR292 guys tell me that this code sequence needs to be locked against multiple setters.
>>>
>>> Tested with jdk/test/java/lang/invoke tests, nsk.quick.testlist.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8066171/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8066171
>>>
>>> Thanks,
>>> Coleen


From harold.seigel at oracle.com  Wed Dec  3 19:31:02 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Wed, 03 Dec 2014 14:31:02 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <547F1C6E.1070701@oracle.com>
References: <547F1C6E.1070701@oracle.com>
Message-ID: <547F64F6.7010001@oracle.com>

Hi Stefan,

The change looks good but I have a couple of questions.

1. Why does the call to create_combined_annotations(), in 
parseClassFile(), use CHECK_NULL when other calls use CHECK_(nullHandle) ?

4021     ClassAnnotationCollector parsed_annotations;
4022     parse_classfile_attributes(&parsed_annotations, CHECK_(nullHandle));
4023
4024     // Finalize the Annotations metadata object,
4025     // now that all annotation arrays have been created.
4026     create_combined_annotations(CHECK_NULL);
4027
4028     // Make sure this is the end of class file stream
4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end of class file %s", CHECK_(nullHandle));


2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
Annotations::free_contents() need to be called if the *_annotation 
fields are NULL?


Thanks, Harold

On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
> Hi all,
>
> Please, review this patch to fix an issue where the GC encounters an 
> InstanceKlass before it has come far enough in the class loading process.
>
> Some background to the fix:
>
> When the JVM loads classes it has to keep track of the allocated 
> Metadata, and in the event of an exception deallocate the Metadata. 
> The ClassFileParser saves the Metadata pointers so that it knows what 
> needs to be deallocated. When the class loading has come far enough 
> there's a point were the GC can take over the ownership of the 
> Metadata and do deallocation of the both the InstanceKlass and the 
> Metadata, if needed. At that point the Metadata pointers in the 
> ClassFileParser are cleared and transfered over to the InstanceKlass.
>
> Most Metadata allocations happen before the InstanceKlass is 
> allocated, but the Annotations are allocated after the InstanceKlass 
> but before the transferal and clearing of the Metadata pointers in the 
> ClassFileParser. If the GC stops when allocating the Annotations, it 
> will likely find this InstanceKlass and assume that the Metadata are 
> correctly setup. This is exactly what's happening in the bug report. 
> The GC finds that the _methods array, unexpectedly, points to NULL.
>
> The proposed solution to this problem is to allocate the Annotations 
> before the InstanceKlass is allocated.
>
> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8065634
>
> Testing:
> JPRT, parallel_class_loading testlist, Aurora adhoc run
>
> Thanks,
> StefanK


From serguei.spitsyn at oracle.com  Wed Dec  3 21:29:22 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 03 Dec 2014 13:29:22 -0800
Subject: RFR 8066171: Out of order with Metaspace allocation lock
In-Reply-To: <547F418E.6010301@oracle.com>
References: <547F418E.6010301@oracle.com>
Message-ID: <547F80B2.1060608@oracle.com>


It looks good to me.

Thanks,
Serguei


On 12/3/14 8:59 AM, Coleen Phillimore wrote:
> Summary: Lock resolved_references instead.
>
> When I took out the constant pool mutex, I thought I could use the 
> metaspace to synchronize this code sequence, but the metaspace_lock is 
> out of order with the DirtyCardQ_CBL_mon lock that can sometimes be 
> taken with obj_at_put() in an object array.   Since there is always a 
> resolved_reference objArrayOop attached to this class, we can lock 
> this for this cpCache entry. John and the JSR292 guys tell me that 
> this code sequence needs to be locked against multiple setters.
>
> Tested with jdk/test/java/lang/invoke tests, nsk.quick.testlist.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8066171/
> bug link https://bugs.openjdk.java.net/browse/JDK-8066171
>
> Thanks,
> Coleen


From coleen.phillimore at oracle.com  Wed Dec  3 21:36:54 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 03 Dec 2014 16:36:54 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <547F64F6.7010001@oracle.com>
References: <547F1C6E.1070701@oracle.com> <547F64F6.7010001@oracle.com>
Message-ID: <547F8276.8090205@oracle.com>


On 12/3/14, 2:31 PM, harold seigel wrote:
> Hi Stefan,
>
> The change looks good but I have a couple of questions.
>
> 1. Why does the call to create_combined_annotations(), in 
> parseClassFile(), use CHECK_NULL when other calls use 
> CHECK_(nullHandle) ?
>
> 4021     ClassAnnotationCollector parsed_annotations;
> 4022     parse_classfile_attributes(&parsed_annotations, 
> CHECK_(nullHandle));
> 4023
> 4024     // Finalize the Annotations metadata object,
> 4025     // now that all annotation arrays have been created.
> 4026     create_combined_annotations(CHECK_NULL);
> 4027
> 4028     // Make sure this is the end of class file stream
> 4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end of 
> class file %s", CHECK_(nullHandle));

Oh, this is my fault. https://bugs.openjdk.java.net/browse/JDK-8066624
If it looks inconsistent, maybe it can be changed to CHECK_(nullHandle);
>
>
> 2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
> Annotations::free_contents() need to be called if the *_annotation 
> fields are NULL?

free_array() checks for null and is inlined so there isn't another need 
for checking if the Array is null first.

This change looks good to me.

Coleen
>
>
> Thanks, Harold
>
> On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please, review this patch to fix an issue where the GC encounters an 
>> InstanceKlass before it has come far enough in the class loading 
>> process.
>>
>> Some background to the fix:
>>
>> When the JVM loads classes it has to keep track of the allocated 
>> Metadata, and in the event of an exception deallocate the Metadata. 
>> The ClassFileParser saves the Metadata pointers so that it knows what 
>> needs to be deallocated. When the class loading has come far enough 
>> there's a point were the GC can take over the ownership of the 
>> Metadata and do deallocation of the both the InstanceKlass and the 
>> Metadata, if needed. At that point the Metadata pointers in the 
>> ClassFileParser are cleared and transfered over to the InstanceKlass.
>>
>> Most Metadata allocations happen before the InstanceKlass is 
>> allocated, but the Annotations are allocated after the InstanceKlass 
>> but before the transferal and clearing of the Metadata pointers in 
>> the ClassFileParser. If the GC stops when allocating the Annotations, 
>> it will likely find this InstanceKlass and assume that the Metadata 
>> are correctly setup. This is exactly what's happening in the bug 
>> report. The GC finds that the _methods array, unexpectedly, points to 
>> NULL.
>>
>> The proposed solution to this problem is to allocate the Annotations 
>> before the InstanceKlass is allocated.
>>
>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>
>> Testing:
>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>
>> Thanks,
>> StefanK
>


From markus.gronlund at oracle.com  Wed Dec  3 22:47:21 2014
From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=)
Date: Wed, 3 Dec 2014 14:47:21 -0800 (PST)
Subject: RFR(xs): 8065788: os::reserve_memory() on Windows should not
	assert that allocation size is aligned to OS allocation granularity.
In-Reply-To: <CA+3eh135XT3DbCCgUjLfnc4avxwzb0khyHD=up1app6MwWPDaA@mail.gmail.com>
References: <CAA-vtUzbWWqynvha1B84vUx3V1e5CYRsBZaQ77RjL4x40BK29Q@mail.gmail.com>
	<c30ef566-9706-486b-8222-3d987076232e@default>
	<CAA-vtUxVPSSuC=s1s6_XWK8dd2n9PRFKCJpHAKmmS3r3vvSgRA@mail.gmail.com>
	<CA+3eh135XT3DbCCgUjLfnc4avxwzb0khyHD=up1app6MwWPDaA@mail.gmail.com>
Message-ID: <2b981f71-6f1d-48fa-ad4d-1e7268aadcf3@default>

Volker and Thomas,

I can sponsor this change.

Thanks
Markus

-----Original Message-----
From: Volker Simonis [mailto:volker.simonis at gmail.com] 
Sent: den 3 december 2014 12:07
To: Thomas St?fe
Cc: Markus Gr?nlund; HotSpot Open Source Developers
Subject: Re: RFR(xs): 8065788: os::reserve_memory() on Windows should not assert that allocation size is aligned to OS allocation granularity.

Hi Thomas,

I think your change is good although I'd prefer if you would assert that the allocation size is aligned to page size (as you've already proposed in your first mail). Callers of os::pd_reserve_memory() can then be cleaned up to only "align_size_up" up to page size because that's what gets reserved by the OS anyway.

Thank you and best regards,
Volker

PS: I'm only a reviewer but not a sponsor so any volunteers are still welcome:)


On Wed, Nov 26, 2014 at 12:50 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Thank you Markus!
>
> Could I have another Reviewer, and maybe someone who sponsors the change?
>
> Please note that this bug is not purely theoretical, but prevents us 
> from reserving just one page on windows, which then leads to everyone 
> aligning the reserve size up to vm_allocation_granularity() just to 
> make the assert go away. Actually, I see a lot of "align_size_up()"s 
> with
> vm_allocation_granularity() which may be unnecessary and could 
> probably get cleaned up.
>
> Kind Regards, Thomas
>
> On Tue, Nov 25, 2014 at 11:21 AM, Markus Gr?nlund < 
> markus.gronlund at oracle.com> wrote:
>
>> Hi Thomas,
>>
>> Thanks for finding and addressing this - looks good.
>>
>> Cheers
>> Markus
>>
>> -----Original Message-----
>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> Sent: den 24 november 2014 18:32
>> To: HotSpot Open Source Developers
>> Subject: RFR(xs): 8065788: os::reserve_memory() on Windows should not 
>> assert that allocation size is aligned to OS allocation granularity.
>>
>> Hi,
>>
>> a very small change:
>>
>> Bug Report: https://bugs.openjdk.java.net/browse/JDK-8065788
>> WebRev:     http://cr.openjdk.java.net/~simonis/webrevs/8065788/
>>
>> os::reserve_memory() on Windows asserts that allocation size is 
>> allocated to os::vm_allocation_granularity(). This assert is wrong 
>> and should be removed.
>>
>> Allocation granularity affects the alignment of attach addresses, not 
>> of the allocated size. The latter is aligned to page size, but 
>> asserting that would be unnecessarily strict, as VirtualAlloc() will 
>> just quietly align size up to page size.
>>
>> For details see MSDN on VirtualAlloc():
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=
>> vs.85%29.aspx
>>
>>
>> Kind Regards,
>>
>> Thomas St?fe
>>

From vladimir.kozlov at oracle.com  Thu Dec  4 00:43:56 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 03 Dec 2014 16:43:56 -0800
Subject: [8u40] backport RFR (XS) 8066199: C2 escape analysis prevents VM
	from exiting quickly
Message-ID: <547FAE4C.6020900@oracle.com>

8u40 backport request.  Changes were pushed into jdk9 yesterday, no 
problems were found since then. Changes are applied to 8u cleanly.

http://cr.openjdk.java.net/~kvn/8066199/webrev/
https://bugs.openjdk.java.net/browse/JDK-8066199
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1266b02f32fe

Thanks,
Vladimir

From igor.veresov at oracle.com  Thu Dec  4 01:26:45 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 3 Dec 2014 17:26:45 -0800
Subject: [8u40] backport RFR (XS) 8066199: C2 escape analysis prevents VM
	from exiting quickly
In-Reply-To: <547FAE4C.6020900@oracle.com>
References: <547FAE4C.6020900@oracle.com>
Message-ID: <602DA5FF-9B66-45DE-B922-EE65119FB51E@oracle.com>

Good.

igor

> On Dec 3, 2014, at 4:43 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> 8u40 backport request.  Changes were pushed into jdk9 yesterday, no problems were found since then. Changes are applied to 8u cleanly.
> 
> http://cr.openjdk.java.net/~kvn/8066199/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8066199
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1266b02f32fe
> 
> Thanks,
> Vladimir


From vladimir.kozlov at oracle.com  Thu Dec  4 01:30:48 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 03 Dec 2014 17:30:48 -0800
Subject: [8u40] backport RFR (XS) 8066199: C2 escape analysis prevents
	VM from exiting quickly
In-Reply-To: <602DA5FF-9B66-45DE-B922-EE65119FB51E@oracle.com>
References: <547FAE4C.6020900@oracle.com>
	<602DA5FF-9B66-45DE-B922-EE65119FB51E@oracle.com>
Message-ID: <547FB948.8050301@oracle.com>

Thank you, Igor

Vladimir

On 12/3/14 5:26 PM, Igor Veresov wrote:
> Good.
>
> igor
>
>> On Dec 3, 2014, at 4:43 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> 8u40 backport request.  Changes were pushed into jdk9 yesterday, no problems were found since then. Changes are applied to 8u cleanly.
>>
>> http://cr.openjdk.java.net/~kvn/8066199/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8066199
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1266b02f32fe
>>
>> Thanks,
>> Vladimir
>

From tobias.hartmann at oracle.com  Thu Dec  4 07:32:49 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 04 Dec 2014 08:32:49 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <547E190F.1090407@oracle.com>
References: <547DCF47.9000608@oracle.com>
	<547DF563.8080509@oracle.com>	<547DF8D8.8080601@oracle.com>	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com>
Message-ID: <54800E21.2050700@oracle.com>

Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
the library at the moment. What do you think about having the duplication as an
intermediate solution until we get the necessary support from jtreg / jprt to
share the library?

There are also other JDK tests that would benefit from having the Whitebox API
available. For example, JDK-8057707 [1].

Thanks,
Tobias

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html

On 02.12.2014 20:54, Tobias Hartmann wrote:
> Hi Staffan,
> 
> thanks for the feedback.
> 
> On 02.12.2014 20:45, Staffan Larsen wrote:
>>
>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>
>>>
>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>
>>>> Hi Mikael,
>>>>
>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>
>>>>> Tobias,
>>>>>
>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>> copy the code. I can't stress that enough.
>>>>
>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>> library from different repositories and I don't think we want to have path
>>>> dependencies between the repositories.
>>>>
>>>> Any suggestions?
>>>
>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>
>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>
>>    @library /../../test/testlibrary
>>
>> I don?t think that is what we want to do?
> 
> Yes, that's what I meant with "path dependencies between repositories". I don't
> think this is a very robust solution.
> 
> Best,
> Tobias
> 
>>
>> /Staffan
>>
>>
>>>
>>> /Staffan
>>>
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>
>>>>> Cheers,
>>>>> Mikael
>>>>>
>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>
>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>> library in the future.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>
>>>
>>

From staffan.larsen at oracle.com  Thu Dec  4 10:29:27 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 4 Dec 2014 11:29:27 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <54800E21.2050700@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com>
Message-ID: <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>

I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code.

/Staffan

> On 4 dec 2014, at 08:32, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
> 
> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
> the library at the moment. What do you think about having the duplication as an
> intermediate solution until we get the necessary support from jtreg / jprt to
> share the library?
> 
> There are also other JDK tests that would benefit from having the Whitebox API
> available. For example, JDK-8057707 [1].
> 
> Thanks,
> Tobias
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
> 
> On 02.12.2014 20:54, Tobias Hartmann wrote:
>> Hi Staffan,
>> 
>> thanks for the feedback.
>> 
>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>> 
>>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>> 
>>>> 
>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>> 
>>>>> Hi Mikael,
>>>>> 
>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>> 
>>>>>> Tobias,
>>>>>> 
>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>>> copy the code. I can't stress that enough.
>>>>> 
>>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>>> library from different repositories and I don't think we want to have path
>>>>> dependencies between the repositories.
>>>>> 
>>>>> Any suggestions?
>>>> 
>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>> 
>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>> 
>>>   @library /../../test/testlibrary
>>> 
>>> I don?t think that is what we want to do?
>> 
>> Yes, that's what I meant with "path dependencies between repositories". I don't
>> think this is a very robust solution.
>> 
>> Best,
>> Tobias
>> 
>>> 
>>> /Staffan
>>> 
>>> 
>>>> 
>>>> /Staffan
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Tobias
>>>>> 
>>>>>> 
>>>>>> Cheers,
>>>>>> Mikael
>>>>>> 
>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>> 
>>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>>> library in the future.
>>>>>>> 
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>> 
>>>> 
>>> 


From tobias.hartmann at oracle.com  Thu Dec  4 11:18:14 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 04 Dec 2014 12:18:14 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com>
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
Message-ID: <548042F6.8070706@oracle.com>


On 04.12.2014 11:29, Staffan Larsen wrote:
> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code.

I mostly need the Whitebox API to fix JDK-8064875. I'm fine with moving the test
to the hotspot repo although we don't have related tests there.

Any objections?

Thanks,
Tobias

> 
> /Staffan
> 
>> On 4 dec 2014, at 08:32, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>
>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
>> the library at the moment. What do you think about having the duplication as an
>> intermediate solution until we get the necessary support from jtreg / jprt to
>> share the library?
>>
>> There are also other JDK tests that would benefit from having the Whitebox API
>> available. For example, JDK-8057707 [1].
>>
>> Thanks,
>> Tobias
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
>>
>> On 02.12.2014 20:54, Tobias Hartmann wrote:
>>> Hi Staffan,
>>>
>>> thanks for the feedback.
>>>
>>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>>>
>>>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>>>
>>>>>
>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>>
>>>>>> Hi Mikael,
>>>>>>
>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>>>
>>>>>>> Tobias,
>>>>>>>
>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>>>> copy the code. I can't stress that enough.
>>>>>>
>>>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>>>> library from different repositories and I don't think we want to have path
>>>>>> dependencies between the repositories.
>>>>>>
>>>>>> Any suggestions?
>>>>>
>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>>>
>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>>>
>>>>   @library /../../test/testlibrary
>>>>
>>>> I don?t think that is what we want to do?
>>>
>>> Yes, that's what I meant with "path dependencies between repositories". I don't
>>> think this is a very robust solution.
>>>
>>> Best,
>>> Tobias
>>>
>>>>
>>>> /Staffan
>>>>
>>>>
>>>>>
>>>>> /Staffan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mikael
>>>>>>>
>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>>>
>>>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>>>> library in the future.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>
>>>>>
>>>>
> 

From tobias.hartmann at oracle.com  Thu Dec  4 11:44:22 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 04 Dec 2014 12:44:22 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <548042F6.8070706@oracle.com>
References: <547DCF47.9000608@oracle.com>
	<547DF563.8080509@oracle.com>	<547DF8D8.8080601@oracle.com>	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>	<547E190F.1090407@oracle.com>
	<54800E21.2050700@oracle.com>	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
	<548042F6.8070706@oracle.com>
Message-ID: <54804916.7030101@oracle.com>

Okay, as Igor Ignatyev pointed out off-thread, we cannot move the test to the
hotspot repo because it is depend on another testlibrary that is only available
in the jdk repo. It all boils down to copying testlibraries.

Thanks,
Tobias

On 04.12.2014 12:18, Tobias Hartmann wrote:
> 
> On 04.12.2014 11:29, Staffan Larsen wrote:
>> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code.
> 
> I mostly need the Whitebox API to fix JDK-8064875. I'm fine with moving the test
> to the hotspot repo although we don't have related tests there.
> 
> Any objections?
> 
> Thanks,
> Tobias
> 
>>
>> /Staffan
>>
>>> On 4 dec 2014, at 08:32, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>
>>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
>>> the library at the moment. What do you think about having the duplication as an
>>> intermediate solution until we get the necessary support from jtreg / jprt to
>>> share the library?
>>>
>>> There are also other JDK tests that would benefit from having the Whitebox API
>>> available. For example, JDK-8057707 [1].
>>>
>>> Thanks,
>>> Tobias
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
>>>
>>> On 02.12.2014 20:54, Tobias Hartmann wrote:
>>>> Hi Staffan,
>>>>
>>>> thanks for the feedback.
>>>>
>>>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>>>>
>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Mikael,
>>>>>>>
>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>>>>
>>>>>>>> Tobias,
>>>>>>>>
>>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>>>>> copy the code. I can't stress that enough.
>>>>>>>
>>>>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>>>>> library from different repositories and I don't think we want to have path
>>>>>>> dependencies between the repositories.
>>>>>>>
>>>>>>> Any suggestions?
>>>>>>
>>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>>>>
>>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>>>>
>>>>>   @library /../../test/testlibrary
>>>>>
>>>>> I don?t think that is what we want to do?
>>>>
>>>> Yes, that's what I meant with "path dependencies between repositories". I don't
>>>> think this is a very robust solution.
>>>>
>>>> Best,
>>>> Tobias
>>>>
>>>>>
>>>>> /Staffan
>>>>>
>>>>>
>>>>>>
>>>>>> /Staffan
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Mikael
>>>>>>>>
>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>>>>
>>>>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>>>>> library in the future.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Tobias
>>>>>>>>
>>>>>>
>>>>>
>>

From harold.seigel at oracle.com  Thu Dec  4 13:25:32 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 04 Dec 2014 08:25:32 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <547F8276.8090205@oracle.com>
References: <547F1C6E.1070701@oracle.com> <547F64F6.7010001@oracle.com>
	<547F8276.8090205@oracle.com>
Message-ID: <548060CC.9010405@oracle.com>

Hi,

How about adding an 'else' statement at line 4342?  That would make the 
code consistent with the comments at lines 4329-4330 and 4343-4344.

4328   if (_combined_annotations != NULL) {
4329     // After all annotations arrays have been created, they are installed into the
4330     // Annotations object that will be assigned to the InstanceKlass being created.
4331
4332     // Deallocate the Annotations object and the installed annotations arrays.
4333     _combined_annotations->deallocate_contents(_loader_data);
4334
4335     // If the _combined_annotations pointer is non-NULL,
4336     // then the other annotations fields should have been cleared.
4337     assert(_annotations             == NULL, "Should have been cleared");
4338     assert(_type_annotations        == NULL, "Should have been cleared");
4339     assert(_fields_annotations      == NULL, "Should have been cleared");
4340     assert(_fields_type_annotations == NULL, "Should have been cleared");
4341   }
4342
4343   // If the annotations arrays were not installed into the Annotations object,
4344   // then they have to be deallocated explicitly.
4345   MetadataFactory::free_array<u1>(_loader_data, _annotations);
4346   MetadataFactory::free_array<u1>(_loader_data, _type_annotations);
4347   Annotations::free_contents(_loader_data, _fields_annotations);
4348   Annotations::free_contents(_loader_data, _fields_type_annotations);

Thanks, Harold

On 12/3/2014 4:36 PM, Coleen Phillimore wrote:
>
> On 12/3/14, 2:31 PM, harold seigel wrote:
>> Hi Stefan,
>>
>> The change looks good but I have a couple of questions.
>>
>> 1. Why does the call to create_combined_annotations(), in 
>> parseClassFile(), use CHECK_NULL when other calls use 
>> CHECK_(nullHandle) ?
>>
>> 4021     ClassAnnotationCollector parsed_annotations;
>> 4022     parse_classfile_attributes(&parsed_annotations, 
>> CHECK_(nullHandle));
>> 4023
>> 4024     // Finalize the Annotations metadata object,
>> 4025     // now that all annotation arrays have been created.
>> 4026     create_combined_annotations(CHECK_NULL);
>> 4027
>> 4028     // Make sure this is the end of class file stream
>> 4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end of 
>> class file %s", CHECK_(nullHandle));
>
> Oh, this is my fault. https://bugs.openjdk.java.net/browse/JDK-8066624
> If it looks inconsistent, maybe it can be changed to CHECK_(nullHandle);
>>
>>
>> 2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
>> Annotations::free_contents() need to be called if the *_annotation 
>> fields are NULL?
>
> free_array() checks for null and is inlined so there isn't another 
> need for checking if the Array is null first.
>
> This change looks good to me.
>
> Coleen
>>
>>
>> Thanks, Harold
>>
>> On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please, review this patch to fix an issue where the GC encounters an 
>>> InstanceKlass before it has come far enough in the class loading 
>>> process.
>>>
>>> Some background to the fix:
>>>
>>> When the JVM loads classes it has to keep track of the allocated 
>>> Metadata, and in the event of an exception deallocate the Metadata. 
>>> The ClassFileParser saves the Metadata pointers so that it knows 
>>> what needs to be deallocated. When the class loading has come far 
>>> enough there's a point were the GC can take over the ownership of 
>>> the Metadata and do deallocation of the both the InstanceKlass and 
>>> the Metadata, if needed. At that point the Metadata pointers in the 
>>> ClassFileParser are cleared and transfered over to the InstanceKlass.
>>>
>>> Most Metadata allocations happen before the InstanceKlass is 
>>> allocated, but the Annotations are allocated after the InstanceKlass 
>>> but before the transferal and clearing of the Metadata pointers in 
>>> the ClassFileParser. If the GC stops when allocating the 
>>> Annotations, it will likely find this InstanceKlass and assume that 
>>> the Metadata are correctly setup. This is exactly what's happening 
>>> in the bug report. The GC finds that the _methods array, 
>>> unexpectedly, points to NULL.
>>>
>>> The proposed solution to this problem is to allocate the Annotations 
>>> before the InstanceKlass is allocated.
>>>
>>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>>
>>> Testing:
>>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>>
>>> Thanks,
>>> StefanK
>>
>


From tatiana.pivovarova at oracle.com  Thu Dec  4 14:30:55 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Thu, 04 Dec 2014 17:30:55 +0300
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method
	to be implemented
Message-ID: <5480701F.1060202@oracle.com>

Hi all,

please review this small patch

bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
webrev: http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/webrev.00

Problem:
Need WhiteBox::allocateCodeBlob(long, int), currently only 
WhiteBox::allocateCodeBlob(int, int) exist.

Solution:
Just change function signature WhiteBox::allocateCodeBlob(int, int) -> 
WhiteBox::allocateCodeBlob(long, int)

Test: jprt

Thanks,
Tatiana

From vladimir.kozlov at oracle.com  Thu Dec  4 16:53:42 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 04 Dec 2014 08:53:42 -0800
Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base"
	and improve compressed heap handling.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF36139@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap>	<5466A656.40707@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>
	<547E4F3B.2090501@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap>
	<547F4914.1030904@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF36139@DEWDFEMB12A.global.corp.sap>
Message-ID: <54809196.7030306@oracle.com>

I spotted an other bug.
You replaced !_base with _base != NULL when moved code to try_reserve_range() - it should be _base == NULL.
The same problem in asserts:

+  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(_base)->decode_pointer() == _base,
+         "area must be distinguishable from marks for mark-sweep");
+  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(&_base[size])->decode_pointer() == &_base[size],
+         "area must be distinguishable from marks for mark-sweep");


Also you did not remove  _base && in next place:

+         (_base && _base + size > zerobased_max))) {  // Unscaled delivered an arbitrary address.

New comment is good.

Thanks,
Vladimri

On 12/4/14 1:45 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
>> Add more extending comment explaining that.
> The comment for try_reserve_heap was meant to explain that.
> I further added a comment in initialize_compressed_heap().
>
>> You need another parameter to pass UnscaledOopHeapMax or zerobased_max.
> Oh, thanks a lot!  That's important. Fixed.
>
>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
> Sorry, now I got it.  Removed.
>
> I updated the webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
> Increment on top of the increment :)
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs2.patch
>
> Thanks,
>    Goetz.
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Mittwoch, 3. Dezember 2014 18:32
> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>
> Comments are below.
>
> On 12/3/14 5:49 AM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>>
>> thanks for looking at the change!  See my comments inline below.
>>
>> I made a new webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
>> Incremental changes:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs.patch
>>
>> Best regards,
>>     Goetz.
>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>> Sent: Mittwoch, 3. Dezember 2014 00:46
>>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>
>>> This looks good to me. Someone in runtime/gc have to look on it too.
>>>
>>> universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode"
>>> we have:
>>> java.vm.info=mixed mode, sharing
>>> so we can have:
>>> java.vm.compressedOopsMode=...
>> Yes, that's good for me. Fixed.
>>
>>> I am not expert in properties names but I don't want to have 'com.sap'
>>> in VM's property name.
>>
>>> virtualspace.cpp:
>>> Could you fix release() - it does not reset _alignment?
>> Fixed.
>>
>>> In try_reserve_heap(), please, use (base == NULL) instead of (!base).
>>> And you don't need 'return;' in alignment check at the end of method.
>> Fixed.
>>
>>> In initialize_compressed_heap() again (!_base).
>> Fixed.
>>
>>> You don't stop (check
>>> (base == NULL)) after successful unscaled, zerobased, disjointbase
>>> allocations. You need to separate them with the check:
>>>
>>> +
>>> +    }
>>> +  }
>>> +  if (_base == NULL) {
>>> +
>>> +    if (PrintCompressedOopsMode && Verbose) {
>>> +      tty->print(" == Z E R O B A S E D ==\n");
>>> +    }
>>> and so on.
>> No, I can't and don't want to check for _base != NULL.
>> I always keep the result of the last try, also if it didn't fulfil the required properties.
>> So I take that result and go into the next check.  That check might succeed
>> with the heap allocated before.
>> This allows me to separate allocation and placement criteria, and to have the
>> placement criteria checked in only one place (per mode).
>> Only for HeapBaseMinAddress I don't do it that way, I explicitly call release().
>> This way I can enforce mode heapbased.
>
> I see what you are saying. It was not clear from comments what is going on.
> Add more extending comment explaining that.
>
>>
>>> num_attempts calculation and while() loop are similar in unscaled and
>>> zerobased cases. Could you move it into a separate method?
>> I can do that, but I don't like it as I have to pass in 7 parameters.
>
> You need an other parameter to pass UnscaledOopHeapMax or zerobased_max.
>
>> That makes the code not much more readable.  The function will look like this:
>
> I think initialize_compressed_heap() is more readable now.
>
>>
>> void ReserveHeapSpace::try_reserve_range(char *const highest_start, char *lowest_start, size_t attach_point_alignment,
>>                                            char *aligned_HBMA, size_t size, size_t alignment, bool large) {
>>     guarantee(HeapSearchSteps > 0, "Don't set HeapSearchSteps to 0");
>>
>>     const size_t attach_range = highest_start - lowest_start;
>>     // Cap num_attempts at possible number.
>>     // At least one is possible even for 0 sized attach range.
>>     const uint64_t num_attempts_possible = (attach_range / attach_point_alignment) + 1;
>>     const uint64_t num_attempts_to_try   = MIN2(HeapSearchSteps, num_attempts_possible);
>>
>>     const size_t stepsize = align_size_up(attach_range / num_attempts_to_try, attach_point_alignment);
>>
>>     // Try attach points from top to bottom.
>>     char* attach_point = highest_start;
>>     while (attach_point >= lowest_start  &&
>>            attach_point <= highest_start &&  // Avoid wrap around.
>>            (!_base || _base < aligned_HBMA || _base + size > (char *)UnscaledOopHeapMax)) {
>>       try_reserve_heap(size, alignment, large, attach_point);
>>       attach_point -= stepsize;
>>     }
>> }
>>
>>
>>> In disjointbase while() condition no need for _base second check:
>>> +           (_base == NULL ||
>>> +            ((_base + size > (char *)OopEncodingHeapMax) &&
>> I need this for the same reason as above:  This is the check for successful allocation.
>
> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
>
> Thanks,
> Vladimir
>
>>
>>
>>
>> Thanks,
>> Vladimir
>>
>> On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I prepared a new webrev trying to cover all the issues mentioned below.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/
>>>
>>> I moved functionality from os.cpp and universe.cpp into
>>> ReservedHeapSpace::initialize_compressed_heap().
>>> This class offers to save _base and _special, which I would have to reimplement
>>> if I had improved the methods I had added to os.cpp to also allocate large page
>>> heaps.
>>> Anyways, I think this class is the right place to gather code trying to reserve
>>> the heap.
>>> Also, I get along without setting the shift, base, implicit_null_check etc. fields
>>> of Universe, so there is no unnecessary calling back and forth between the two
>>> classes.
>>> Universe gets the heap back, and then sets the properties it needs to configure
>>> the compressed oops.
>>> All code handling the noaccess prefix is in a single method, too.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>> Btw, I had to workaround a SS12u1 problem: it wouldn't compile
>>> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode.
>>>
>>>
>>> -----Original Message-----
>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>>> Sent: Montag, 17. November 2014 09:33
>>> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
>>> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>
>>> Hi Vladimir,
>>>
>>>> It is very significant rewriting and it takes time to evaluate it.
>>> Yes, I know ... and I don't want to push, but nevertheless a ping
>>> can be useful sometimes. Thanks a lot for looking at it.
>>>
>>>> And I would not say it is simpler then before :)
>>> If I fix what you propose it's gonna get even more simple ;)
>>>> These is what I found so far.
>>>
>>>> The idea to try to allocate in a range instead of just below
>>>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do
>>>> several attempts (3?) on non_PPC64 platforms too.
>>> Set to 3.
>>>
>>>> It is matter of preference but I am not comfortable with switch in loop.
>>>> For me sequential 'if (addr == 0)' checks is simpler.
>>> I'll fix this.
>>>
>>>> One thing worries me that you release found space and try to get it
>>>> again with ReservedHeapSpace. Is it possible to add new
>>>> ReservedHeapSpace ctor which simple use already allocated space?
>>> This was to keep diff's small, but I also think a new constructor is good.
>>> I'll fix this.
>>>
>>>> The next code in ReservedHeapSpace() is hard to understand ():
>>>> (UseCompressedOops && (requested_address == NULL ||
>>> requested_address+size > (char*)OopEncodingHeapMax) ?
>>>> may be move all this into noaccess_prefix_size() and add comments.
>>> I have to redo this anyways if I make new constructors.
>>>
>>>> Why you need prefix when requested_address == NULL?
>>> If we allocate with NULL, we most probably will get a heap where
>>> base != NULL and thus need a noaccess prefix.
>>>
>>>> Remove next comment in universe.cpp:
>>>> // SAPJVM GL 2014-09-22
>>> Removed.
>>>
>>>> Again you will release space so why bother to include space for classes?:
>>>> +          // For small heaps, save some space for compressed class pointer
>>>> +          // space so it can be decoded with no base.
>>> This was done like this before.  We must assure the upper bound of the
>>> heap is low enough that the compressed class space still fits in there.
>>>
>>> virtualspace.cpp
>>>
>>>> With new code size+noaccess_prefix could be requested. But later it is
>>>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty
>>>> non-protected page below heap.
>>> There's several points to this:
>>>     * Also if not protectable, the heap base has to be below the real start of the
>>>        heap.  Else the first object in the heap will be compressed to 'null'
>>>        and decompression will fail.
>>>     * If we don't reserve the memory other stuff can end up in this space. On
>>>        errors, if would be quite unexpected to find memory there.
>>>     * To get a heap for the new disjoint mode I must control the size of this.
>>>         Requesting a heap starting at (aligned base + prefix) is more likely to fail.
>>>     * The size for the prefix must anyways be considered when deciding whether the
>>>         heap is small enough to run with compressed oops.
>>> So distinguishing the case where we really can omit this would require
>>> quite some additional checks everywhere, and I thought it's not worth it.
>>>
>>> matcher.hpp
>>>
>>>> Universe::narrow_oop_use_implicit_null_checks() should be true for such
>>>> case too. So you can add new condition with || to existing ones. The
>>>> only condition you relax is base != NULL. Right?
>>> Yes, that's how it's intended.
>>>
>>> arguments.* files
>>>
>>>> Why you need PropertyList_add changes.
>>> Oh, the code using it got lost.  I commented on this in the description in the webrev.
>>> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode."
>>> When I know about the heap I do
>>>        Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode",
>>>                                                       narrow_oop_mode_to_string(narrow_oop_mode()),
>>>                                                       false));
>>> in universe.cpp.
>>> On some OSes it's deterministic which modes work, there we don't start such tests.
>>> Others, as you mentioned OSX,  are very indeterministic.  Here we save testruntime with this.
>>> But it's not that important.
>>> We can still parse the PrintCompresseOopsMode output after the test and discard the
>>> run.
>>>
>>>> Do you have platform specific changes?
>>> Yes, for ppc and aix.  I'll submit them once this is in.
>>>
>>>    From your other mail:
>>>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match
>>>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range.
>>> Good point.  I'll fix that in os::attempt_reserve_memory_in_range.
>>>
>>> I'll ping again once a new webrev is done!
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I need to improve a row of things around compressed oops heap handling
>>>> to achieve good performance on ppc.
>>>> I prepared a first webrev for review:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>>>>
>>>> A detailed technical description of the change is in the webrev and according bug.
>>>>
>>>> If requested, I will split the change into parts with more respective less impact on
>>>> non-ppc platforms.
>>>>
>>>> The change is derived from well-tested code in our VM.  Originally it was
>>>> crafted to require the least changes of  VM coding, I changed it to be better
>>>> streamlined with the VM.
>>>> I tested this change to deliver heaps at about the same addresses as before.
>>>> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
>>>> in a better compressed oops mode is found, though.
>>>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>

From goetz.lindenmaier at sap.com  Thu Dec  4 18:27:12 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 4 Dec 2014 18:27:12 +0000
Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base"
	and improve compressed heap handling.
In-Reply-To: <54809196.7030306@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap>
	<5466A656.40707@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>
	<547E4F3B.2090501@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap>
	<547F4914.1030904@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF36139@DEWDFEMB12A.global.corp.sap>
	<54809196.7030306@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF39BA5@DEWDFEMB12A.global.corp.sap>

Hi Vladimir.

Sorry.  I updated the webrev once more.  Hope it's fine now.
At least I can write comments :)

Best regards,
  Goetz

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Thursday, December 04, 2014 5:54 PM
To: Lindenmaier, Goetz
Cc: 'hotspot-dev developers'
Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.

I spotted an other bug.
You replaced !_base with _base != NULL when moved code to try_reserve_range() - it should be _base == NULL.
The same problem in asserts:

+  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(_base)->decode_pointer() == _base,
+         "area must be distinguishable from marks for mark-sweep");
+  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(&_base[size])->decode_pointer() == &_base[size],
+         "area must be distinguishable from marks for mark-sweep");


Also you did not remove  _base && in next place:

+         (_base && _base + size > zerobased_max))) {  // Unscaled delivered an arbitrary address.

New comment is good.

Thanks,
Vladimri

On 12/4/14 1:45 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir,
>
>> Add more extending comment explaining that.
> The comment for try_reserve_heap was meant to explain that.
> I further added a comment in initialize_compressed_heap().
>
>> You need another parameter to pass UnscaledOopHeapMax or zerobased_max.
> Oh, thanks a lot!  That's important. Fixed.
>
>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
> Sorry, now I got it.  Removed.
>
> I updated the webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
> Increment on top of the increment :)
> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs2.patch
>
> Thanks,
>    Goetz.
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Mittwoch, 3. Dezember 2014 18:32
> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>
> Comments are below.
>
> On 12/3/14 5:49 AM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>>
>> thanks for looking at the change!  See my comments inline below.
>>
>> I made a new webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
>> Incremental changes:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs.patch
>>
>> Best regards,
>>     Goetz.
>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>> Sent: Mittwoch, 3. Dezember 2014 00:46
>>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>
>>> This looks good to me. Someone in runtime/gc have to look on it too.
>>>
>>> universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode"
>>> we have:
>>> java.vm.info=mixed mode, sharing
>>> so we can have:
>>> java.vm.compressedOopsMode=...
>> Yes, that's good for me. Fixed.
>>
>>> I am not expert in properties names but I don't want to have 'com.sap'
>>> in VM's property name.
>>
>>> virtualspace.cpp:
>>> Could you fix release() - it does not reset _alignment?
>> Fixed.
>>
>>> In try_reserve_heap(), please, use (base == NULL) instead of (!base).
>>> And you don't need 'return;' in alignment check at the end of method.
>> Fixed.
>>
>>> In initialize_compressed_heap() again (!_base).
>> Fixed.
>>
>>> You don't stop (check
>>> (base == NULL)) after successful unscaled, zerobased, disjointbase
>>> allocations. You need to separate them with the check:
>>>
>>> +
>>> +    }
>>> +  }
>>> +  if (_base == NULL) {
>>> +
>>> +    if (PrintCompressedOopsMode && Verbose) {
>>> +      tty->print(" == Z E R O B A S E D ==\n");
>>> +    }
>>> and so on.
>> No, I can't and don't want to check for _base != NULL.
>> I always keep the result of the last try, also if it didn't fulfil the required properties.
>> So I take that result and go into the next check.  That check might succeed
>> with the heap allocated before.
>> This allows me to separate allocation and placement criteria, and to have the
>> placement criteria checked in only one place (per mode).
>> Only for HeapBaseMinAddress I don't do it that way, I explicitly call release().
>> This way I can enforce mode heapbased.
>
> I see what you are saying. It was not clear from comments what is going on.
> Add more extending comment explaining that.
>
>>
>>> num_attempts calculation and while() loop are similar in unscaled and
>>> zerobased cases. Could you move it into a separate method?
>> I can do that, but I don't like it as I have to pass in 7 parameters.
>
> You need an other parameter to pass UnscaledOopHeapMax or zerobased_max.
>
>> That makes the code not much more readable.  The function will look like this:
>
> I think initialize_compressed_heap() is more readable now.
>
>>
>> void ReserveHeapSpace::try_reserve_range(char *const highest_start, char *lowest_start, size_t attach_point_alignment,
>>                                            char *aligned_HBMA, size_t size, size_t alignment, bool large) {
>>     guarantee(HeapSearchSteps > 0, "Don't set HeapSearchSteps to 0");
>>
>>     const size_t attach_range = highest_start - lowest_start;
>>     // Cap num_attempts at possible number.
>>     // At least one is possible even for 0 sized attach range.
>>     const uint64_t num_attempts_possible = (attach_range / attach_point_alignment) + 1;
>>     const uint64_t num_attempts_to_try   = MIN2(HeapSearchSteps, num_attempts_possible);
>>
>>     const size_t stepsize = align_size_up(attach_range / num_attempts_to_try, attach_point_alignment);
>>
>>     // Try attach points from top to bottom.
>>     char* attach_point = highest_start;
>>     while (attach_point >= lowest_start  &&
>>            attach_point <= highest_start &&  // Avoid wrap around.
>>            (!_base || _base < aligned_HBMA || _base + size > (char *)UnscaledOopHeapMax)) {
>>       try_reserve_heap(size, alignment, large, attach_point);
>>       attach_point -= stepsize;
>>     }
>> }
>>
>>
>>> In disjointbase while() condition no need for _base second check:
>>> +           (_base == NULL ||
>>> +            ((_base + size > (char *)OopEncodingHeapMax) &&
>> I need this for the same reason as above:  This is the check for successful allocation.
>
> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
>
> Thanks,
> Vladimir
>
>>
>>
>>
>> Thanks,
>> Vladimir
>>
>> On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote:
>>> Hi,
>>>
>>> I prepared a new webrev trying to cover all the issues mentioned below.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/
>>>
>>> I moved functionality from os.cpp and universe.cpp into
>>> ReservedHeapSpace::initialize_compressed_heap().
>>> This class offers to save _base and _special, which I would have to reimplement
>>> if I had improved the methods I had added to os.cpp to also allocate large page
>>> heaps.
>>> Anyways, I think this class is the right place to gather code trying to reserve
>>> the heap.
>>> Also, I get along without setting the shift, base, implicit_null_check etc. fields
>>> of Universe, so there is no unnecessary calling back and forth between the two
>>> classes.
>>> Universe gets the heap back, and then sets the properties it needs to configure
>>> the compressed oops.
>>> All code handling the noaccess prefix is in a single method, too.
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>> Btw, I had to workaround a SS12u1 problem: it wouldn't compile
>>> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode.
>>>
>>>
>>> -----Original Message-----
>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>>> Sent: Montag, 17. November 2014 09:33
>>> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
>>> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>
>>> Hi Vladimir,
>>>
>>>> It is very significant rewriting and it takes time to evaluate it.
>>> Yes, I know ... and I don't want to push, but nevertheless a ping
>>> can be useful sometimes. Thanks a lot for looking at it.
>>>
>>>> And I would not say it is simpler then before :)
>>> If I fix what you propose it's gonna get even more simple ;)
>>>> These is what I found so far.
>>>
>>>> The idea to try to allocate in a range instead of just below
>>>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do
>>>> several attempts (3?) on non_PPC64 platforms too.
>>> Set to 3.
>>>
>>>> It is matter of preference but I am not comfortable with switch in loop.
>>>> For me sequential 'if (addr == 0)' checks is simpler.
>>> I'll fix this.
>>>
>>>> One thing worries me that you release found space and try to get it
>>>> again with ReservedHeapSpace. Is it possible to add new
>>>> ReservedHeapSpace ctor which simple use already allocated space?
>>> This was to keep diff's small, but I also think a new constructor is good.
>>> I'll fix this.
>>>
>>>> The next code in ReservedHeapSpace() is hard to understand ():
>>>> (UseCompressedOops && (requested_address == NULL ||
>>> requested_address+size > (char*)OopEncodingHeapMax) ?
>>>> may be move all this into noaccess_prefix_size() and add comments.
>>> I have to redo this anyways if I make new constructors.
>>>
>>>> Why you need prefix when requested_address == NULL?
>>> If we allocate with NULL, we most probably will get a heap where
>>> base != NULL and thus need a noaccess prefix.
>>>
>>>> Remove next comment in universe.cpp:
>>>> // SAPJVM GL 2014-09-22
>>> Removed.
>>>
>>>> Again you will release space so why bother to include space for classes?:
>>>> +          // For small heaps, save some space for compressed class pointer
>>>> +          // space so it can be decoded with no base.
>>> This was done like this before.  We must assure the upper bound of the
>>> heap is low enough that the compressed class space still fits in there.
>>>
>>> virtualspace.cpp
>>>
>>>> With new code size+noaccess_prefix could be requested. But later it is
>>>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty
>>>> non-protected page below heap.
>>> There's several points to this:
>>>     * Also if not protectable, the heap base has to be below the real start of the
>>>        heap.  Else the first object in the heap will be compressed to 'null'
>>>        and decompression will fail.
>>>     * If we don't reserve the memory other stuff can end up in this space. On
>>>        errors, if would be quite unexpected to find memory there.
>>>     * To get a heap for the new disjoint mode I must control the size of this.
>>>         Requesting a heap starting at (aligned base + prefix) is more likely to fail.
>>>     * The size for the prefix must anyways be considered when deciding whether the
>>>         heap is small enough to run with compressed oops.
>>> So distinguishing the case where we really can omit this would require
>>> quite some additional checks everywhere, and I thought it's not worth it.
>>>
>>> matcher.hpp
>>>
>>>> Universe::narrow_oop_use_implicit_null_checks() should be true for such
>>>> case too. So you can add new condition with || to existing ones. The
>>>> only condition you relax is base != NULL. Right?
>>> Yes, that's how it's intended.
>>>
>>> arguments.* files
>>>
>>>> Why you need PropertyList_add changes.
>>> Oh, the code using it got lost.  I commented on this in the description in the webrev.
>>> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode."
>>> When I know about the heap I do
>>>        Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode",
>>>                                                       narrow_oop_mode_to_string(narrow_oop_mode()),
>>>                                                       false));
>>> in universe.cpp.
>>> On some OSes it's deterministic which modes work, there we don't start such tests.
>>> Others, as you mentioned OSX,  are very indeterministic.  Here we save testruntime with this.
>>> But it's not that important.
>>> We can still parse the PrintCompresseOopsMode output after the test and discard the
>>> run.
>>>
>>>> Do you have platform specific changes?
>>> Yes, for ppc and aix.  I'll submit them once this is in.
>>>
>>>    From your other mail:
>>>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match
>>>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range.
>>> Good point.  I'll fix that in os::attempt_reserve_memory_in_range.
>>>
>>> I'll ping again once a new webrev is done!
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>
>>> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I need to improve a row of things around compressed oops heap handling
>>>> to achieve good performance on ppc.
>>>> I prepared a first webrev for review:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>>>>
>>>> A detailed technical description of the change is in the webrev and according bug.
>>>>
>>>> If requested, I will split the change into parts with more respective less impact on
>>>> non-ppc platforms.
>>>>
>>>> The change is derived from well-tested code in our VM.  Originally it was
>>>> crafted to require the least changes of  VM coding, I changed it to be better
>>>> streamlined with the VM.
>>>> I tested this change to deliver heaps at about the same addresses as before.
>>>> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
>>>> in a better compressed oops mode is found, though.
>>>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>

From christian.thalinger at oracle.com  Thu Dec  4 18:34:36 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 4 Dec 2014 10:34:36 -0800
Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base"
	and improve compressed heap handling.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF39BA5@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap>
	<5466A656.40707@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>
	<547E4F3B.2090501@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap>
	<547F4914.1030904@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF36139@DEWDFEMB12A.global.corp.sap>
	<54809196.7030306@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF39BA5@DEWDFEMB12A.global.corp.sap>
Message-ID: <4F8633D4-2FE5-4676-963B-5C4151EFF5A5@oracle.com>


> On Dec 4, 2014, at 10:27 AM, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi Vladimir.
> 
> Sorry.  I updated the webrev once more.  Hope it's fine now.
> At least I can write comments :)

Comments are more important than the code, right? ;-)

> 
> Best regards,
>  Goetz
> 
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
> Sent: Thursday, December 04, 2014 5:54 PM
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev developers'
> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
> 
> I spotted an other bug.
> You replaced !_base with _base != NULL when moved code to try_reserve_range() - it should be _base == NULL.
> The same problem in asserts:
> 
> +  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(_base)->decode_pointer() == _base,
> +         "area must be distinguishable from marks for mark-sweep");
> +  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(&_base[size])->decode_pointer() == &_base[size],
> +         "area must be distinguishable from marks for mark-sweep");
> 
> 
> Also you did not remove  _base && in next place:
> 
> +         (_base && _base + size > zerobased_max))) {  // Unscaled delivered an arbitrary address.
> 
> New comment is good.
> 
> Thanks,
> Vladimri
> 
> On 12/4/14 1:45 AM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>> 
>>> Add more extending comment explaining that.
>> The comment for try_reserve_heap was meant to explain that.
>> I further added a comment in initialize_compressed_heap().
>> 
>>> You need another parameter to pass UnscaledOopHeapMax or zerobased_max.
>> Oh, thanks a lot!  That's important. Fixed.
>> 
>>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
>> Sorry, now I got it.  Removed.
>> 
>> I updated the webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
>> Increment on top of the increment :)
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs2.patch
>> 
>> Thanks,
>>   Goetz.
>> 
>> 
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Mittwoch, 3. Dezember 2014 18:32
>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>> 
>> Comments are below.
>> 
>> On 12/3/14 5:49 AM, Lindenmaier, Goetz wrote:
>>> Hi Vladimir,
>>> 
>>> thanks for looking at the change!  See my comments inline below.
>>> 
>>> I made a new webrev:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
>>> Incremental changes:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs.patch
>>> 
>>> Best regards,
>>>    Goetz.
>>> 
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Mittwoch, 3. Dezember 2014 00:46
>>>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>> 
>>>> This looks good to me. Someone in runtime/gc have to look on it too.
>>>> 
>>>> universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode"
>>>> we have:
>>>> java.vm.info=mixed mode, sharing
>>>> so we can have:
>>>> java.vm.compressedOopsMode=...
>>> Yes, that's good for me. Fixed.
>>> 
>>>> I am not expert in properties names but I don't want to have 'com.sap'
>>>> in VM's property name.
>>> 
>>>> virtualspace.cpp:
>>>> Could you fix release() - it does not reset _alignment?
>>> Fixed.
>>> 
>>>> In try_reserve_heap(), please, use (base == NULL) instead of (!base).
>>>> And you don't need 'return;' in alignment check at the end of method.
>>> Fixed.
>>> 
>>>> In initialize_compressed_heap() again (!_base).
>>> Fixed.
>>> 
>>>> You don't stop (check
>>>> (base == NULL)) after successful unscaled, zerobased, disjointbase
>>>> allocations. You need to separate them with the check:
>>>> 
>>>> +
>>>> +    }
>>>> +  }
>>>> +  if (_base == NULL) {
>>>> +
>>>> +    if (PrintCompressedOopsMode && Verbose) {
>>>> +      tty->print(" == Z E R O B A S E D ==\n");
>>>> +    }
>>>> and so on.
>>> No, I can't and don't want to check for _base != NULL.
>>> I always keep the result of the last try, also if it didn't fulfil the required properties.
>>> So I take that result and go into the next check.  That check might succeed
>>> with the heap allocated before.
>>> This allows me to separate allocation and placement criteria, and to have the
>>> placement criteria checked in only one place (per mode).
>>> Only for HeapBaseMinAddress I don't do it that way, I explicitly call release().
>>> This way I can enforce mode heapbased.
>> 
>> I see what you are saying. It was not clear from comments what is going on.
>> Add more extending comment explaining that.
>> 
>>> 
>>>> num_attempts calculation and while() loop are similar in unscaled and
>>>> zerobased cases. Could you move it into a separate method?
>>> I can do that, but I don't like it as I have to pass in 7 parameters.
>> 
>> You need an other parameter to pass UnscaledOopHeapMax or zerobased_max.
>> 
>>> That makes the code not much more readable.  The function will look like this:
>> 
>> I think initialize_compressed_heap() is more readable now.
>> 
>>> 
>>> void ReserveHeapSpace::try_reserve_range(char *const highest_start, char *lowest_start, size_t attach_point_alignment,
>>>                                           char *aligned_HBMA, size_t size, size_t alignment, bool large) {
>>>    guarantee(HeapSearchSteps > 0, "Don't set HeapSearchSteps to 0");
>>> 
>>>    const size_t attach_range = highest_start - lowest_start;
>>>    // Cap num_attempts at possible number.
>>>    // At least one is possible even for 0 sized attach range.
>>>    const uint64_t num_attempts_possible = (attach_range / attach_point_alignment) + 1;
>>>    const uint64_t num_attempts_to_try   = MIN2(HeapSearchSteps, num_attempts_possible);
>>> 
>>>    const size_t stepsize = align_size_up(attach_range / num_attempts_to_try, attach_point_alignment);
>>> 
>>>    // Try attach points from top to bottom.
>>>    char* attach_point = highest_start;
>>>    while (attach_point >= lowest_start  &&
>>>           attach_point <= highest_start &&  // Avoid wrap around.
>>>           (!_base || _base < aligned_HBMA || _base + size > (char *)UnscaledOopHeapMax)) {
>>>      try_reserve_heap(size, alignment, large, attach_point);
>>>      attach_point -= stepsize;
>>>    }
>>> }
>>> 
>>> 
>>>> In disjointbase while() condition no need for _base second check:
>>>> +           (_base == NULL ||
>>>> +            ((_base + size > (char *)OopEncodingHeapMax) &&
>>> I need this for the same reason as above:  This is the check for successful allocation.
>> 
>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
>> 
>> Thanks,
>> Vladimir
>> 
>>> 
>>> 
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>> 
>>>> I prepared a new webrev trying to cover all the issues mentioned below.
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/
>>>> 
>>>> I moved functionality from os.cpp and universe.cpp into
>>>> ReservedHeapSpace::initialize_compressed_heap().
>>>> This class offers to save _base and _special, which I would have to reimplement
>>>> if I had improved the methods I had added to os.cpp to also allocate large page
>>>> heaps.
>>>> Anyways, I think this class is the right place to gather code trying to reserve
>>>> the heap.
>>>> Also, I get along without setting the shift, base, implicit_null_check etc. fields
>>>> of Universe, so there is no unnecessary calling back and forth between the two
>>>> classes.
>>>> Universe gets the heap back, and then sets the properties it needs to configure
>>>> the compressed oops.
>>>> All code handling the noaccess prefix is in a single method, too.
>>>> 
>>>> Best regards,
>>>>     Goetz.
>>>> 
>>>> Btw, I had to workaround a SS12u1 problem: it wouldn't compile
>>>> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode.
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>>>> Sent: Montag, 17. November 2014 09:33
>>>> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>> 
>>>> Hi Vladimir,
>>>> 
>>>>> It is very significant rewriting and it takes time to evaluate it.
>>>> Yes, I know ... and I don't want to push, but nevertheless a ping
>>>> can be useful sometimes. Thanks a lot for looking at it.
>>>> 
>>>>> And I would not say it is simpler then before :)
>>>> If I fix what you propose it's gonna get even more simple ;)
>>>>> These is what I found so far.
>>>> 
>>>>> The idea to try to allocate in a range instead of just below
>>>>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do
>>>>> several attempts (3?) on non_PPC64 platforms too.
>>>> Set to 3.
>>>> 
>>>>> It is matter of preference but I am not comfortable with switch in loop.
>>>>> For me sequential 'if (addr == 0)' checks is simpler.
>>>> I'll fix this.
>>>> 
>>>>> One thing worries me that you release found space and try to get it
>>>>> again with ReservedHeapSpace. Is it possible to add new
>>>>> ReservedHeapSpace ctor which simple use already allocated space?
>>>> This was to keep diff's small, but I also think a new constructor is good.
>>>> I'll fix this.
>>>> 
>>>>> The next code in ReservedHeapSpace() is hard to understand ():
>>>>> (UseCompressedOops && (requested_address == NULL ||
>>>> requested_address+size > (char*)OopEncodingHeapMax) ?
>>>>> may be move all this into noaccess_prefix_size() and add comments.
>>>> I have to redo this anyways if I make new constructors.
>>>> 
>>>>> Why you need prefix when requested_address == NULL?
>>>> If we allocate with NULL, we most probably will get a heap where
>>>> base != NULL and thus need a noaccess prefix.
>>>> 
>>>>> Remove next comment in universe.cpp:
>>>>> // SAPJVM GL 2014-09-22
>>>> Removed.
>>>> 
>>>>> Again you will release space so why bother to include space for classes?:
>>>>> +          // For small heaps, save some space for compressed class pointer
>>>>> +          // space so it can be decoded with no base.
>>>> This was done like this before.  We must assure the upper bound of the
>>>> heap is low enough that the compressed class space still fits in there.
>>>> 
>>>> virtualspace.cpp
>>>> 
>>>>> With new code size+noaccess_prefix could be requested. But later it is
>>>>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty
>>>>> non-protected page below heap.
>>>> There's several points to this:
>>>>    * Also if not protectable, the heap base has to be below the real start of the
>>>>       heap.  Else the first object in the heap will be compressed to 'null'
>>>>       and decompression will fail.
>>>>    * If we don't reserve the memory other stuff can end up in this space. On
>>>>       errors, if would be quite unexpected to find memory there.
>>>>    * To get a heap for the new disjoint mode I must control the size of this.
>>>>        Requesting a heap starting at (aligned base + prefix) is more likely to fail.
>>>>    * The size for the prefix must anyways be considered when deciding whether the
>>>>        heap is small enough to run with compressed oops.
>>>> So distinguishing the case where we really can omit this would require
>>>> quite some additional checks everywhere, and I thought it's not worth it.
>>>> 
>>>> matcher.hpp
>>>> 
>>>>> Universe::narrow_oop_use_implicit_null_checks() should be true for such
>>>>> case too. So you can add new condition with || to existing ones. The
>>>>> only condition you relax is base != NULL. Right?
>>>> Yes, that's how it's intended.
>>>> 
>>>> arguments.* files
>>>> 
>>>>> Why you need PropertyList_add changes.
>>>> Oh, the code using it got lost.  I commented on this in the description in the webrev.
>>>> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode."
>>>> When I know about the heap I do
>>>>       Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode",
>>>>                                                      narrow_oop_mode_to_string(narrow_oop_mode()),
>>>>                                                      false));
>>>> in universe.cpp.
>>>> On some OSes it's deterministic which modes work, there we don't start such tests.
>>>> Others, as you mentioned OSX,  are very indeterministic.  Here we save testruntime with this.
>>>> But it's not that important.
>>>> We can still parse the PrintCompresseOopsMode output after the test and discard the
>>>> run.
>>>> 
>>>>> Do you have platform specific changes?
>>>> Yes, for ppc and aix.  I'll submit them once this is in.
>>>> 
>>>>   From your other mail:
>>>>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match
>>>>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range.
>>>> Good point.  I'll fix that in os::attempt_reserve_memory_in_range.
>>>> 
>>>> I'll ping again once a new webrev is done!
>>>> 
>>>> Best regards,
>>>>     Goetz.
>>>> 
>>>> 
>>>> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>> 
>>>>> I need to improve a row of things around compressed oops heap handling
>>>>> to achieve good performance on ppc.
>>>>> I prepared a first webrev for review:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>>>>> 
>>>>> A detailed technical description of the change is in the webrev and according bug.
>>>>> 
>>>>> If requested, I will split the change into parts with more respective less impact on
>>>>> non-ppc platforms.
>>>>> 
>>>>> The change is derived from well-tested code in our VM.  Originally it was
>>>>> crafted to require the least changes of  VM coding, I changed it to be better
>>>>> streamlined with the VM.
>>>>> I tested this change to deliver heaps at about the same addresses as before.
>>>>> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
>>>>> in a better compressed oops mode is found, though.
>>>>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>>>>> 
>>>>> Best regards,
>>>>>      Goetz.
>>>>> 
>>>>> 


From vladimir.kozlov at oracle.com  Thu Dec  4 18:43:36 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 04 Dec 2014 10:43:36 -0800
Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base"
	and improve compressed heap handling.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF39BA5@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap>	<5466A656.40707@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap>	<4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>	<547E4F3B.2090501@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap>	<547F4914.1030904@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CF36139@DEWDFEMB12A.global.corp.sap>	<54809196.7030306@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF39BA5@DEWDFEMB12A.global.corp.sap>
Message-ID: <5480AB58.80604@oracle.com>

This looks good to me.

Now we need second review since changes are significant. Preferable from 
GC group since you changed ReservedHeapSpace. They will be affected 
most. Review from Runtime is also welcome.

Thanks,
Vladimir

On 12/4/14 10:27 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir.
>
> Sorry.  I updated the webrev once more.  Hope it's fine now.
> At least I can write comments :)
>
> Best regards,
>    Goetz
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Thursday, December 04, 2014 5:54 PM
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev developers'
> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>
> I spotted an other bug.
> You replaced !_base with _base != NULL when moved code to try_reserve_range() - it should be _base == NULL.
> The same problem in asserts:
>
> +  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(_base)->decode_pointer() == _base,
> +         "area must be distinguishable from marks for mark-sweep");
> +  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(&_base[size])->decode_pointer() == &_base[size],
> +         "area must be distinguishable from marks for mark-sweep");
>
>
> Also you did not remove  _base && in next place:
>
> +         (_base && _base + size > zerobased_max))) {  // Unscaled delivered an arbitrary address.
>
> New comment is good.
>
> Thanks,
> Vladimri
>
> On 12/4/14 1:45 AM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>>
>>> Add more extending comment explaining that.
>> The comment for try_reserve_heap was meant to explain that.
>> I further added a comment in initialize_compressed_heap().
>>
>>> You need another parameter to pass UnscaledOopHeapMax or zerobased_max.
>> Oh, thanks a lot!  That's important. Fixed.
>>
>>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
>> Sorry, now I got it.  Removed.
>>
>> I updated the webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
>> Increment on top of the increment :)
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs2.patch
>>
>> Thanks,
>>     Goetz.
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Mittwoch, 3. Dezember 2014 18:32
>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>
>> Comments are below.
>>
>> On 12/3/14 5:49 AM, Lindenmaier, Goetz wrote:
>>> Hi Vladimir,
>>>
>>> thanks for looking at the change!  See my comments inline below.
>>>
>>> I made a new webrev:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
>>> Incremental changes:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs.patch
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Mittwoch, 3. Dezember 2014 00:46
>>>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>>
>>>> This looks good to me. Someone in runtime/gc have to look on it too.
>>>>
>>>> universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode"
>>>> we have:
>>>> java.vm.info=mixed mode, sharing
>>>> so we can have:
>>>> java.vm.compressedOopsMode=...
>>> Yes, that's good for me. Fixed.
>>>
>>>> I am not expert in properties names but I don't want to have 'com.sap'
>>>> in VM's property name.
>>>
>>>> virtualspace.cpp:
>>>> Could you fix release() - it does not reset _alignment?
>>> Fixed.
>>>
>>>> In try_reserve_heap(), please, use (base == NULL) instead of (!base).
>>>> And you don't need 'return;' in alignment check at the end of method.
>>> Fixed.
>>>
>>>> In initialize_compressed_heap() again (!_base).
>>> Fixed.
>>>
>>>> You don't stop (check
>>>> (base == NULL)) after successful unscaled, zerobased, disjointbase
>>>> allocations. You need to separate them with the check:
>>>>
>>>> +
>>>> +    }
>>>> +  }
>>>> +  if (_base == NULL) {
>>>> +
>>>> +    if (PrintCompressedOopsMode && Verbose) {
>>>> +      tty->print(" == Z E R O B A S E D ==\n");
>>>> +    }
>>>> and so on.
>>> No, I can't and don't want to check for _base != NULL.
>>> I always keep the result of the last try, also if it didn't fulfil the required properties.
>>> So I take that result and go into the next check.  That check might succeed
>>> with the heap allocated before.
>>> This allows me to separate allocation and placement criteria, and to have the
>>> placement criteria checked in only one place (per mode).
>>> Only for HeapBaseMinAddress I don't do it that way, I explicitly call release().
>>> This way I can enforce mode heapbased.
>>
>> I see what you are saying. It was not clear from comments what is going on.
>> Add more extending comment explaining that.
>>
>>>
>>>> num_attempts calculation and while() loop are similar in unscaled and
>>>> zerobased cases. Could you move it into a separate method?
>>> I can do that, but I don't like it as I have to pass in 7 parameters.
>>
>> You need an other parameter to pass UnscaledOopHeapMax or zerobased_max.
>>
>>> That makes the code not much more readable.  The function will look like this:
>>
>> I think initialize_compressed_heap() is more readable now.
>>
>>>
>>> void ReserveHeapSpace::try_reserve_range(char *const highest_start, char *lowest_start, size_t attach_point_alignment,
>>>                                             char *aligned_HBMA, size_t size, size_t alignment, bool large) {
>>>      guarantee(HeapSearchSteps > 0, "Don't set HeapSearchSteps to 0");
>>>
>>>      const size_t attach_range = highest_start - lowest_start;
>>>      // Cap num_attempts at possible number.
>>>      // At least one is possible even for 0 sized attach range.
>>>      const uint64_t num_attempts_possible = (attach_range / attach_point_alignment) + 1;
>>>      const uint64_t num_attempts_to_try   = MIN2(HeapSearchSteps, num_attempts_possible);
>>>
>>>      const size_t stepsize = align_size_up(attach_range / num_attempts_to_try, attach_point_alignment);
>>>
>>>      // Try attach points from top to bottom.
>>>      char* attach_point = highest_start;
>>>      while (attach_point >= lowest_start  &&
>>>             attach_point <= highest_start &&  // Avoid wrap around.
>>>             (!_base || _base < aligned_HBMA || _base + size > (char *)UnscaledOopHeapMax)) {
>>>        try_reserve_heap(size, alignment, large, attach_point);
>>>        attach_point -= stepsize;
>>>      }
>>> }
>>>
>>>
>>>> In disjointbase while() condition no need for _base second check:
>>>> +           (_base == NULL ||
>>>> +            ((_base + size > (char *)OopEncodingHeapMax) &&
>>> I need this for the same reason as above:  This is the check for successful allocation.
>>
>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
>>
>> Thanks,
>> Vladimir
>>
>>>
>>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I prepared a new webrev trying to cover all the issues mentioned below.
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/
>>>>
>>>> I moved functionality from os.cpp and universe.cpp into
>>>> ReservedHeapSpace::initialize_compressed_heap().
>>>> This class offers to save _base and _special, which I would have to reimplement
>>>> if I had improved the methods I had added to os.cpp to also allocate large page
>>>> heaps.
>>>> Anyways, I think this class is the right place to gather code trying to reserve
>>>> the heap.
>>>> Also, I get along without setting the shift, base, implicit_null_check etc. fields
>>>> of Universe, so there is no unnecessary calling back and forth between the two
>>>> classes.
>>>> Universe gets the heap back, and then sets the properties it needs to configure
>>>> the compressed oops.
>>>> All code handling the noaccess prefix is in a single method, too.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>> Btw, I had to workaround a SS12u1 problem: it wouldn't compile
>>>> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>>>> Sent: Montag, 17. November 2014 09:33
>>>> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>>
>>>> Hi Vladimir,
>>>>
>>>>> It is very significant rewriting and it takes time to evaluate it.
>>>> Yes, I know ... and I don't want to push, but nevertheless a ping
>>>> can be useful sometimes. Thanks a lot for looking at it.
>>>>
>>>>> And I would not say it is simpler then before :)
>>>> If I fix what you propose it's gonna get even more simple ;)
>>>>> These is what I found so far.
>>>>
>>>>> The idea to try to allocate in a range instead of just below
>>>>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do
>>>>> several attempts (3?) on non_PPC64 platforms too.
>>>> Set to 3.
>>>>
>>>>> It is matter of preference but I am not comfortable with switch in loop.
>>>>> For me sequential 'if (addr == 0)' checks is simpler.
>>>> I'll fix this.
>>>>
>>>>> One thing worries me that you release found space and try to get it
>>>>> again with ReservedHeapSpace. Is it possible to add new
>>>>> ReservedHeapSpace ctor which simple use already allocated space?
>>>> This was to keep diff's small, but I also think a new constructor is good.
>>>> I'll fix this.
>>>>
>>>>> The next code in ReservedHeapSpace() is hard to understand ():
>>>>> (UseCompressedOops && (requested_address == NULL ||
>>>> requested_address+size > (char*)OopEncodingHeapMax) ?
>>>>> may be move all this into noaccess_prefix_size() and add comments.
>>>> I have to redo this anyways if I make new constructors.
>>>>
>>>>> Why you need prefix when requested_address == NULL?
>>>> If we allocate with NULL, we most probably will get a heap where
>>>> base != NULL and thus need a noaccess prefix.
>>>>
>>>>> Remove next comment in universe.cpp:
>>>>> // SAPJVM GL 2014-09-22
>>>> Removed.
>>>>
>>>>> Again you will release space so why bother to include space for classes?:
>>>>> +          // For small heaps, save some space for compressed class pointer
>>>>> +          // space so it can be decoded with no base.
>>>> This was done like this before.  We must assure the upper bound of the
>>>> heap is low enough that the compressed class space still fits in there.
>>>>
>>>> virtualspace.cpp
>>>>
>>>>> With new code size+noaccess_prefix could be requested. But later it is
>>>>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty
>>>>> non-protected page below heap.
>>>> There's several points to this:
>>>>      * Also if not protectable, the heap base has to be below the real start of the
>>>>         heap.  Else the first object in the heap will be compressed to 'null'
>>>>         and decompression will fail.
>>>>      * If we don't reserve the memory other stuff can end up in this space. On
>>>>         errors, if would be quite unexpected to find memory there.
>>>>      * To get a heap for the new disjoint mode I must control the size of this.
>>>>          Requesting a heap starting at (aligned base + prefix) is more likely to fail.
>>>>      * The size for the prefix must anyways be considered when deciding whether the
>>>>          heap is small enough to run with compressed oops.
>>>> So distinguishing the case where we really can omit this would require
>>>> quite some additional checks everywhere, and I thought it's not worth it.
>>>>
>>>> matcher.hpp
>>>>
>>>>> Universe::narrow_oop_use_implicit_null_checks() should be true for such
>>>>> case too. So you can add new condition with || to existing ones. The
>>>>> only condition you relax is base != NULL. Right?
>>>> Yes, that's how it's intended.
>>>>
>>>> arguments.* files
>>>>
>>>>> Why you need PropertyList_add changes.
>>>> Oh, the code using it got lost.  I commented on this in the description in the webrev.
>>>> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode."
>>>> When I know about the heap I do
>>>>         Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode",
>>>>                                                        narrow_oop_mode_to_string(narrow_oop_mode()),
>>>>                                                        false));
>>>> in universe.cpp.
>>>> On some OSes it's deterministic which modes work, there we don't start such tests.
>>>> Others, as you mentioned OSX,  are very indeterministic.  Here we save testruntime with this.
>>>> But it's not that important.
>>>> We can still parse the PrintCompresseOopsMode output after the test and discard the
>>>> run.
>>>>
>>>>> Do you have platform specific changes?
>>>> Yes, for ppc and aix.  I'll submit them once this is in.
>>>>
>>>>     From your other mail:
>>>>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match
>>>>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range.
>>>> Good point.  I'll fix that in os::attempt_reserve_memory_in_range.
>>>>
>>>> I'll ping again once a new webrev is done!
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>
>>>> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> I need to improve a row of things around compressed oops heap handling
>>>>> to achieve good performance on ppc.
>>>>> I prepared a first webrev for review:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>>>>>
>>>>> A detailed technical description of the change is in the webrev and according bug.
>>>>>
>>>>> If requested, I will split the change into parts with more respective less impact on
>>>>> non-ppc platforms.
>>>>>
>>>>> The change is derived from well-tested code in our VM.  Originally it was
>>>>> crafted to require the least changes of  VM coding, I changed it to be better
>>>>> streamlined with the VM.
>>>>> I tested this change to deliver heaps at about the same addresses as before.
>>>>> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
>>>>> in a better compressed oops mode is found, though.
>>>>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>>>>>
>>>>> Best regards,
>>>>>        Goetz.
>>>>>
>>>>>

From max.ockner at oracle.com  Thu Dec  4 21:50:55 2014
From: max.ockner at oracle.com (Max Ockner)
Date: Thu, 04 Dec 2014 16:50:55 -0500
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <547437EF.5010806@oracle.com>
References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com>
	<545CF033.4010503@oracle.com> <54619729.30704@oracle.com>
	<546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com>
Message-ID: <5480D73F.7070907@oracle.com>

Hello once again...
I have a new (and suggestively titled) webrev: 
http://cr.openjdk.java.net/~coleenp/8047290final/

Ran aurora tests.

Here is a list of "sometimes" locks:

"WorkGroup monitor" share/vm/utilities/workgroup.cpp
"SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
"CompactibleFreeListSpace._lock" 
share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
"freelist par lock" 
share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
"SR_lock"                            share/vm/runtime/thread.cpp
"CMS_markBitMap_lock" 
share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp

The remaining "sometimes" locks can be found in 
share/vm/runtime/mutexLocker.cpp:

ParGCRareEvent_lock
Safepoint_lock
Threads_lock
VMOperationQueue_lock
VMOperationRequest_lock
Terminator_lock
Heap_lock
Compile_lock
PeriodicTask_lock
JfrStacktrace_lock


Thanks,
Max Ockner




On 11/25/2014 3:03 AM, David Holmes wrote:
> Hi Max,
>
> On 21/11/2014 7:56 AM, Max Ockner wrote:
>> Hello again,
>>
>> I have made changes based on all comments. There is now a pair of assert
>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>
> Is there an updated webrev?
>
>> caught another lock that I had to change to "sometimes", but the assert
>> that caught this lock was not in wait. There are currently no locks that
>> use try to pass an incorrect safepoint check argument to wait().
>> Instead, gcbasher did not catch this lock last time, when the only
>> asserts were in lock and lock_without_safepoint. This lock is
>> "CMS_markBitMap_lock" in
>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. 
>>
>> I'm guessing that it was not caught by the tests because this section of
>> code is not reached very often. My initial inspection failed to catch
>> this lock because it is passed around between various structures and
>> renamed 4 times. I have not yet found a good way to check for this
>> situation, even with a debugger.
>>
>> Are there any tests which actually manage to hit every line of code?
>
> No. There is too much code that is dependent on low-level details of 
> the GC used, the compilation strategy, plus the set of runtime flags 
> used (and whether product or fastdebug). That's why we have lots of 
> tests run in lots of different ways, to try to get coverage.
>
>> How should I handle this situation where I can't rely on the tests that
>> I have run to tell me if I have missed something?
>> At what point can I assume that everything is OK?
>
> Difficult to answer in general - there are a number of recommended 
> test suites used by the runtime team, but your changes will also 
> impact GC and compiler code and so may not get exercised by the 
> runtime test suites (unless run with various compiler and GC options). 
> Perhaps an ad-hoc test run similar to nightlies? Or you push after the 
> weekly snapshot so as to maximise nightly testing, and if there are 
> issues exposed then you have time to address them or revert the fix.
>
> Cheers,
> David
>
>> Thanks,
>> Max Ockner
>>
>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>> Hi Max,
>>>
>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>> Hello all,
>>>> I have made these additonal changes:
>>>> -Moved the assert() statements into the lock and 
>>>> lock_without_safepoint
>>>> methods.
>>>> -Changed Monitor::SafepointAllowed to Monitor::SafepointCheckRequired
>>>> -Changed the Monitor::SafepointCheckRequired values for several locks
>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>> MutexLocker, some were locked were locked without any MutexLocker* )
>>>>
>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>
>>> Generally this is all okay - a few style and other nits below.
>>>
>>> However you missed adding an assert in Monitor::wait to check if the
>>> no_safepoint_check flag was being used correctly for the current 
>>> monitor.
>>>
>>> Specific comments:
>>>
>>> src/share/vm/runtime/mutex.hpp
>>>
>>> This comment is no longer accurate with the moved check location:
>>>
>>> + // MutexLockerEx checks these flags when acquiring a lock
>>> + // to ensure consistent checking for each lock.
>>>
>>> The same goes for other references to MutexLockerEx in the enum
>>> description.
>>>
>>> Also copyright year needs updating.
>>>
>>> ---
>>>
>>> src/share/vm/runtime/mutex.cpp
>>>
>>>  898   //Ensure
>>>  961   //Ensure
>>>
>>> Space needed after //
>>>
>>> ---
>>>
>>> src/share/vm/runtime/mutexLocker.cpp
>>>
>>> +  var = new type(Mutex::pri, #var, 
>>> vm_block,safepoint_check_allowed); \
>>>
>>> space needed after comma in k,s
>>>
>>> ---
>>>
>>> src/share/vm/runtime/mutexLocker.hpp
>>>
>>> Whitespace only changes - looks like leftovers from removed edits.
>>>
>>>
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Additional testing:
>>>> jtreg ./jdk/test/java/lang/invoke
>>>> jtreg jfr tests
>>>>
>>>> Here is a list of ALL of the "sometimes" locks:
>>>>
>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>> "CompactibleFreeListSpace._lock"
>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>
>>>>
>>>> "freelist par lock"
>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>
>>>>
>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>
>>>> The remaining "sometimes" locks can be found in
>>>> share/vm/runtime/mutexLocker.cpp:
>>>>
>>>> ParGCRareEvent_lock
>>>> Safepoint_lock
>>>> Threads_lock
>>>> VMOperationQueue_lock
>>>> VMOperationRequest_lock
>>>> Terminator_lock
>>>> Heap_lock
>>>> Compile_lock
>>>> PeriodicTask_lock
>>>> JfrStacktrace_lock
>>>>
>>>> I have not checked the validity of the "sometimes" locks, and I 
>>>> believe
>>>> that this should be a different project.
>>>>
>>>> Thanks for your help!
>>>> Max Ockner
>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>> Hi Max,
>>>>>
>>>>> This is looking good.
>>>>>
>>>>> A few high-level initial comments:
>>>>>
>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>
>>>>> Why are the checks in MutexLocker when the state is maintained in the
>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>> check in the mutex/monitor methods.
>>>>>
>>>>> Checking consistent usage of the _no_safepoint_check_flag is good. 
>>>>> But
>>>>> another part of this is that a monitor/mutex that never checks for
>>>>> safepoints should never be held when a thread blocks at a safepoint -
>>>>> is there some way to easily check that? I was surprised how many 
>>>>> locks
>>>>> are actually not checking for safepoints.
>>>>>
>>>>> Did you find any cases where the mutex/monitor was being used
>>>>> inconsistently and incorrectly?
>>>>>
>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>> (Aside: just for fun check out what happens if you lock the
>>>>> Threads_lock with a safepoint check and a safepoint has been 
>>>>> requested
>>>>> :) ).
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>> Please review my first fix related to safepoint checking.
>>>>>>
>>>>>> Summary: MutexLockerEx can either acquire a lock with or without a
>>>>>> safepoint check.
>>>>>> In some cases, a particular lock must either safepoint check 
>>>>>> always or
>>>>>> never to avoid deadlocking.
>>>>>> Some other locks have semantics which allow them to avoid deadlocks
>>>>>> despite having a safepoint check only some of the time.
>>>>>> All locks that are OK having inconsistent safepoint checks have been
>>>>>> marked. All locks that should never safepoint check and all locks 
>>>>>> that
>>>>>> should always safepoint check have also been marked.
>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>> check,
>>>>>> the lock's safepointAllowed marker is checked to ensure consistent
>>>>>> safepoint checking.
>>>>>>
>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>
>>>>>> Tested with:
>>>>>>      jprt "-testset hotspot"
>>>>>>      jtreg hotspot
>>>>>>      vm.quick.testlist
>>>>>>
>>>>>> Whitebox tests:
>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test
>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test
>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code
>>>>>> should not assert. (Lock is properly acquired with no safepoint 
>>>>>> check)
>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code
>>>>>> should not assert. (Lock is properly acquired with safepoint check)
>>>>>>
>>>>>> Thanks,
>>>>>> Max
>>>>>>
>>>>
>>


From coleen.phillimore at oracle.com  Thu Dec  4 22:03:27 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 04 Dec 2014 17:03:27 -0500
Subject: RFR 8066171: Out of order with Metaspace allocation lock
In-Reply-To: <547F80B2.1060608@oracle.com>
References: <547F418E.6010301@oracle.com> <547F80B2.1060608@oracle.com>
Message-ID: <5480DA2F.50005@oracle.com>


Thank you Serguei.
Coleen
On 12/3/14, 4:29 PM, serguei.spitsyn at oracle.com wrote:
>
> It looks good to me.
>
> Thanks,
> Serguei
>
>
> On 12/3/14 8:59 AM, Coleen Phillimore wrote:
>> Summary: Lock resolved_references instead.
>>
>> When I took out the constant pool mutex, I thought I could use the 
>> metaspace to synchronize this code sequence, but the metaspace_lock 
>> is out of order with the DirtyCardQ_CBL_mon lock that can sometimes 
>> be taken with obj_at_put() in an object array.   Since there is 
>> always a resolved_reference objArrayOop attached to this class, we 
>> can lock this for this cpCache entry. John and the JSR292 guys tell 
>> me that this code sequence needs to be locked against multiple setters.
>>
>> Tested with jdk/test/java/lang/invoke tests, nsk.quick.testlist.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8066171/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8066171
>>
>> Thanks,
>> Coleen
>


From poonam.bajaj at oracle.com  Thu Dec  4 22:19:37 2014
From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar)
Date: Thu, 04 Dec 2014 14:19:37 -0800
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <548060CC.9010405@oracle.com>
References: <547F1C6E.1070701@oracle.com> <547F64F6.7010001@oracle.com>
	<547F8276.8090205@oracle.com> <548060CC.9010405@oracle.com>
Message-ID: <5480DDF9.8050405@oracle.com>

Hello Stefan,

The changes look good to me.

Perhaps the comment for the following code can be modified from:

3132     // The annotations below has been transfered the _combined_annotations
3133     // so these fields can now be cleared.
3134     _annotations             = NULL;
3135     _type_annotations        = NULL;
3136     _fields_annotations      = NULL;
3137     _fields_type_annotations = NULL;
3138 }

to

3132     // The annotations arrays below have been transferred to the _combined_annotations

Also, if possible, would be good if we can change the name of 
_annotations field to _class_annotations; more like the names of the 
other annotations arrays.

Thanks,
Poonam


On 12/4/2014 5:25 AM, harold seigel wrote:
> Hi,
>
> How about adding an 'else' statement at line 4342?  That would make 
> the code consistent with the comments at lines 4329-4330 and 4343-4344.
>
> 4328   if (_combined_annotations != NULL) {
> 4329     // After all annotations arrays have been created, they are 
> installed into the
> 4330     // Annotations object that will be assigned to the 
> InstanceKlass being created.
> 4331
> 4332     // Deallocate the Annotations object and the installed 
> annotations arrays.
> 4333 _combined_annotations->deallocate_contents(_loader_data);
> 4334
> 4335     // If the _combined_annotations pointer is non-NULL,
> 4336     // then the other annotations fields should have been cleared.
> 4337     assert(_annotations             == NULL, "Should have been 
> cleared");
> 4338     assert(_type_annotations        == NULL, "Should have been 
> cleared");
> 4339     assert(_fields_annotations      == NULL, "Should have been 
> cleared");
> 4340     assert(_fields_type_annotations == NULL, "Should have been 
> cleared");
> 4341   }
> 4342
> 4343   // If the annotations arrays were not installed into the 
> Annotations object,
> 4344   // then they have to be deallocated explicitly.
> 4345   MetadataFactory::free_array<u1>(_loader_data, _annotations);
> 4346   MetadataFactory::free_array<u1>(_loader_data, _type_annotations);
> 4347   Annotations::free_contents(_loader_data, _fields_annotations);
> 4348   Annotations::free_contents(_loader_data, 
> _fields_type_annotations);
>
> Thanks, Harold
>
> On 12/3/2014 4:36 PM, Coleen Phillimore wrote:
>>
>> On 12/3/14, 2:31 PM, harold seigel wrote:
>>> Hi Stefan,
>>>
>>> The change looks good but I have a couple of questions.
>>>
>>> 1. Why does the call to create_combined_annotations(), in 
>>> parseClassFile(), use CHECK_NULL when other calls use 
>>> CHECK_(nullHandle) ?
>>>
>>> 4021     ClassAnnotationCollector parsed_annotations;
>>> 4022     parse_classfile_attributes(&parsed_annotations, 
>>> CHECK_(nullHandle));
>>> 4023
>>> 4024     // Finalize the Annotations metadata object,
>>> 4025     // now that all annotation arrays have been created.
>>> 4026     create_combined_annotations(CHECK_NULL);
>>> 4027
>>> 4028     // Make sure this is the end of class file stream
>>> 4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end 
>>> of class file %s", CHECK_(nullHandle));
>>
>> Oh, this is my fault. https://bugs.openjdk.java.net/browse/JDK-8066624
>> If it looks inconsistent, maybe it can be changed to CHECK_(nullHandle);
>>>
>>>
>>> 2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
>>> Annotations::free_contents() need to be called if the *_annotation 
>>> fields are NULL?
>>
>> free_array() checks for null and is inlined so there isn't another 
>> need for checking if the Array is null first.
>>
>> This change looks good to me.
>>
>> Coleen
>>>
>>>
>>> Thanks, Harold
>>>
>>> On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> Please, review this patch to fix an issue where the GC encounters 
>>>> an InstanceKlass before it has come far enough in the class loading 
>>>> process.
>>>>
>>>> Some background to the fix:
>>>>
>>>> When the JVM loads classes it has to keep track of the allocated 
>>>> Metadata, and in the event of an exception deallocate the Metadata. 
>>>> The ClassFileParser saves the Metadata pointers so that it knows 
>>>> what needs to be deallocated. When the class loading has come far 
>>>> enough there's a point were the GC can take over the ownership of 
>>>> the Metadata and do deallocation of the both the InstanceKlass and 
>>>> the Metadata, if needed. At that point the Metadata pointers in the 
>>>> ClassFileParser are cleared and transfered over to the InstanceKlass.
>>>>
>>>> Most Metadata allocations happen before the InstanceKlass is 
>>>> allocated, but the Annotations are allocated after the 
>>>> InstanceKlass but before the transferal and clearing of the 
>>>> Metadata pointers in the ClassFileParser. If the GC stops when 
>>>> allocating the Annotations, it will likely find this InstanceKlass 
>>>> and assume that the Metadata are correctly setup. This is exactly 
>>>> what's happening in the bug report. The GC finds that the _methods 
>>>> array, unexpectedly, points to NULL.
>>>>
>>>> The proposed solution to this problem is to allocate the 
>>>> Annotations before the InstanceKlass is allocated.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>>>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>>>
>>>> Testing:
>>>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>>>
>>>> Thanks,
>>>> StefanK
>>>
>>
>


From david.holmes at oracle.com  Thu Dec  4 23:52:02 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 09:52:02 +1000
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <5480C601.9040701@oracle.com>
References: <5480C601.9040701@oracle.com>
Message-ID: <5480F3A2.9070600@oracle.com>

Hi Chris,

Sorry I mis-directed you to send this one to build-dev, as it is a 
hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd.

Fix looks good to me.

Thanks,
David

On 5/12/2014 6:37 AM, Chris Plummer wrote:
> Please review the following fix to address JPRT timeout issues when
> using -rtests to run hotspot JTReg tests on slow devices. The same logic
> has been in place for jdk/test/Makefile for a while now, so I just
> copied from there to hotspot/test/Makefile.
>
> https://bugs.openjdk.java.net/browse/JDK-8066508
> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>
> thanks,
>
> Chris
>

From david.holmes at oracle.com  Fri Dec  5 01:11:46 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 11:11:46 +1000
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <5480701F.1060202@oracle.com>
References: <5480701F.1060202@oracle.com>
Message-ID: <54810652.6050208@oracle.com>

Hi Tatiana,

On 5/12/2014 12:30 AM, Tatiana Pivovarova wrote:
> Hi all,
>
> please review this small patch
>
> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
> webrev: http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/webrev.00
>
> Problem:
> Need WhiteBox::allocateCodeBlob(long, int), currently only
> WhiteBox::allocateCodeBlob(int, int) exist.
>
> Solution:
> Just change function signature WhiteBox::allocateCodeBlob(int, int) ->
> WhiteBox::allocateCodeBlob(long, int)

But this gets truncated to an int again:

CodeBlob* WhiteBox::allocate_code_blob(int size, int blob_type)

David

> Test: jprt
>
> Thanks,
> Tatiana

From vitalyd at gmail.com  Fri Dec  5 01:23:58 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 4 Dec 2014 20:23:58 -0500
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <54810652.6050208@oracle.com>
References: <5480701F.1060202@oracle.com>
	<54810652.6050208@oracle.com>
Message-ID: <CAHjP37HHyLY4JNahLW6r9wjYPenevcu6fubjHva5m7juw7V=yg@mail.gmail.com>

This is just for convenience for calling from java code, it seems, and not
because code blob size actually needs to be larger than int (that would be
scary!).

Sent from my phone
On Dec 4, 2014 8:12 PM, "David Holmes" <david.holmes at oracle.com> wrote:

> Hi Tatiana,
>
> On 5/12/2014 12:30 AM, Tatiana Pivovarova wrote:
>
>> Hi all,
>>
>> please review this small patch
>>
>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
>> webrev: http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/
>> webrev.00
>>
>> Problem:
>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>> WhiteBox::allocateCodeBlob(int, int) exist.
>>
>> Solution:
>> Just change function signature WhiteBox::allocateCodeBlob(int, int) ->
>> WhiteBox::allocateCodeBlob(long, int)
>>
>
> But this gets truncated to an int again:
>
> CodeBlob* WhiteBox::allocate_code_blob(int size, int blob_type)
>
> David
>
>  Test: jprt
>>
>> Thanks,
>> Tatiana
>>
>

From jesper.wilhelmsson at oracle.com  Fri Dec  5 01:38:57 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 05 Dec 2014 02:38:57 +0100
Subject: Disallow flags with extra characters appended
Message-ID: <54810CB1.2060207@oracle.com>

Hi,

Today some (not all) flags are accepted even though they have random characters 
appended to them. Some examples are -Xconcgc, -Xcomp, -Xboundthreads, 
-XX:+AlwaysTenure etc which will also be accepted when written for instance 
-Xconcgcnoway, -Xcomposer, -Xboundthreadstodogs or -XX:+AlwaysTenureAtBlueMoon

There is a potential problem here since we will also accept things like 
-XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of course 
without running with G1).

I have a suggestion for a fix here:
http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/

Would this be an acceptable solution?

I couldn't find one, but since this has been around for quite some time I wonder 
if there is a bug for this already. If not I'll create one.

Thanks,
/Jesper


From david.holmes at oracle.com  Fri Dec  5 03:46:41 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 13:46:41 +1000
Subject: Disallow flags with extra characters appended
In-Reply-To: <54810CB1.2060207@oracle.com>
References: <54810CB1.2060207@oracle.com>
Message-ID: <54812AA1.10308@oracle.com>

Hi Jesper,

On 5/12/2014 11:38 AM, Jesper Wilhelmsson wrote:
> Hi,
>
> Today some (not all) flags are accepted even though they have random
> characters appended to them. Some examples are -Xconcgc, -Xcomp,
> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted when
> written for instance -Xconcgcnoway, -Xcomposer, -Xboundthreadstodogs or
> -XX:+AlwaysTenureAtBlueMoon
>
> There is a potential problem here since we will also accept things like
> -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of
> course without running with G1).
>
> I have a suggestion for a fix here:
> http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/
>
> Would this be an acceptable solution?

I'm somewhat surprised the single name version of match_option didn't 
also have the _tail_allowed flag - seems rather unbalanced. But what you 
have is cleaner I think. Though I would suggest moving you new version:

  static bool match_option(const JavaVMOption *option, const char* name) {

to immediately after the tail version (and before the _tail_allowed 
multi-name version), which a suitable comment added.

That said ...

> I couldn't find one, but since this has been around for quite some time
> I wonder if there is a bug for this already. If not I'll create one.

... this has already been rejected

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

Thanks,
David

> Thanks,
> /Jesper
>

From david.holmes at oracle.com  Fri Dec  5 03:50:06 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 13:50:06 +1000
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <5481219F.70203@oracle.com>
References: <5480701F.1060202@oracle.com>	<54810652.6050208@oracle.com>
	<CAHjP37HHyLY4JNahLW6r9wjYPenevcu6fubjHva5m7juw7V=yg@mail.gmail.com>
	<5481219F.70203@oracle.com>
Message-ID: <54812B6E.2070202@oracle.com>

On 5/12/2014 1:08 PM, Chris Plummer wrote:
> Why not do it from java?
>
> public  long    allocateCodeBlob(long size, int type) {
>      allocateCodeBlob((int)size, type);
> }
>
> It will make it a bit more obvious to the caller what is going on,
> rather than letting hidden C++ code implicitly truncate it.

Why is this even needed in the first place? It is simply an invitation 
for errors if you pass a long where only an int is expected. The caller 
of the API needs to know they should be passing an int.

David

> Chris
>
> On 12/4/14 5:23 PM, Vitaly Davidovich wrote:
>> This is just for convenience for calling from java code, it seems, and not
>> because code blob size actually needs to be larger than int (that would be
>> scary!).
>>
>> Sent from my phone
>> On Dec 4, 2014 8:12 PM, "David Holmes"<david.holmes at oracle.com>  wrote:
>>
>>> Hi Tatiana,
>>>
>>> On 5/12/2014 12:30 AM, Tatiana Pivovarova wrote:
>>>
>>>> Hi all,
>>>>
>>>> please review this small patch
>>>>
>>>> bugid:https://bugs.openjdk.java.net/browse/JDK-8065134
>>>> webrev:http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/
>>>> webrev.00
>>>>
>>>> Problem:
>>>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>>>> WhiteBox::allocateCodeBlob(int, int) exist.
>>>>
>>>> Solution:
>>>> Just change function signature WhiteBox::allocateCodeBlob(int, int) ->
>>>> WhiteBox::allocateCodeBlob(long, int)
>>>>
>>> But this gets truncated to an int again:
>>>
>>> CodeBlob* WhiteBox::allocate_code_blob(int size, int blob_type)
>>>
>>> David
>>>
>>>   Test: jprt
>>>> Thanks,
>>>> Tatiana
>>>>
>

From david.holmes at oracle.com  Fri Dec  5 03:53:03 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 13:53:03 +1000
Subject: RFR 8066171: Out of order with Metaspace allocation lock
In-Reply-To: <547F418E.6010301@oracle.com>
References: <547F418E.6010301@oracle.com>
Message-ID: <54812C1F.3040905@oracle.com>

Hi Coleen,

Do you care that you can now block at safepoints when acquiring the lock?

David

On 4/12/2014 2:59 AM, Coleen Phillimore wrote:
> Summary: Lock resolved_references instead.
>
> When I took out the constant pool mutex, I thought I could use the
> metaspace to synchronize this code sequence, but the metaspace_lock is
> out of order with the DirtyCardQ_CBL_mon lock that can sometimes be
> taken with obj_at_put() in an object array.   Since there is always a
> resolved_reference objArrayOop attached to this class, we can lock this
> for this cpCache entry.  John and the JSR292 guys tell me that this code
> sequence needs to be locked against multiple setters.
>
> Tested with jdk/test/java/lang/invoke tests, nsk.quick.testlist.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8066171/
> bug link https://bugs.openjdk.java.net/browse/JDK-8066171
>
> Thanks,
> Coleen

From david.holmes at oracle.com  Fri Dec  5 05:00:12 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 15:00:12 +1000
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <5481359E.1070003@oracle.com>
References: <5480701F.1060202@oracle.com>	<54810652.6050208@oracle.com>
	<CAHjP37HHyLY4JNahLW6r9wjYPenevcu6fubjHva5m7juw7V=yg@mail.gmail.com>
	<5481219F.70203@oracle.com> <54812B6E.2070202@oracle.com>
	<5481359E.1070003@oracle.com>
Message-ID: <54813BDC.10900@oracle.com>

On 5/12/2014 2:33 PM, Chris Plummer wrote:
> On 12/4/14 7:50 PM, David Holmes wrote:
>> On 5/12/2014 1:08 PM, Chris Plummer wrote:
>>> Why not do it from java?
>>>
>>> public  long    allocateCodeBlob(long size, int type) {
>>>      allocateCodeBlob((int)size, type);
>>> }
>>>
>>> It will make it a bit more obvious to the caller what is going on,
>>> rather than letting hidden C++ code implicitly truncate it.
>>
>> Why is this even needed in the first place? It is simply an invitation
>> for errors if you pass a long where only an int is expected. The
>> caller of the API needs to know they should be passing an int.
>
> [For some reason my posts aren't making it to the alias]

Weird - I can see that on the archive too.

>  From the CR:
>
> " currently only WhiteBox::allocateCodeBlob(int, int) is present, which
> is inconvenient while working with MemoryPoolMXBean, which returns long
> values for memory parameters, thus, a type cast has to be done in
> various cases"
>
> So it looks like this is being done for convenience purposes. At some
> point the long needs to be converted to an int. It can be done at the
> lowest layer (C++ as Tatiana has done), a layer up in WhiteBox.java as I
> proposed, in a allocateCodeBlob() wrapper API closer to the code working
> with MemoryPoolMXBean, or at each allocateCodeBlob() call site.

I'd vote for the callsite. And I have a hard time seeing how values from 
MemoryPoolMXBean end up being used for allocateCodeBlob ??

David

> Chris
>>
>> David
>>
>>> Chris
>>>
>>> On 12/4/14 5:23 PM, Vitaly Davidovich wrote:
>>>> This is just for convenience for calling from java code, it seems,
>>>> and not
>>>> because code blob size actually needs to be larger than int (that
>>>> would be
>>>> scary!).
>>>>
>>>> Sent from my phone
>>>> On Dec 4, 2014 8:12 PM, "David Holmes"<david.holmes at oracle.com>  wrote:
>>>>
>>>>> Hi Tatiana,
>>>>>
>>>>> On 5/12/2014 12:30 AM, Tatiana Pivovarova wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> please review this small patch
>>>>>>
>>>>>> bugid:https://bugs.openjdk.java.net/browse/JDK-8065134
>>>>>> webrev:http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/
>>>>>> webrev.00
>>>>>>
>>>>>> Problem:
>>>>>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>>>>>> WhiteBox::allocateCodeBlob(int, int) exist.
>>>>>>
>>>>>> Solution:
>>>>>> Just change function signature WhiteBox::allocateCodeBlob(int,
>>>>>> int) ->
>>>>>> WhiteBox::allocateCodeBlob(long, int)
>>>>>>
>>>>> But this gets truncated to an int again:
>>>>>
>>>>> CodeBlob* WhiteBox::allocate_code_blob(int size, int blob_type)
>>>>>
>>>>> David
>>>>>
>>>>>   Test: jprt
>>>>>> Thanks,
>>>>>> Tatiana
>>>>>>
>>>
>

From staffan.larsen at oracle.com  Fri Dec  5 08:11:59 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 5 Dec 2014 09:11:59 +0100
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <5480F3A2.9070600@oracle.com>
References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com>
Message-ID: <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com>

Running with longer timeouts on fast machines makes the testing less responsive (if a test is on its way to timeout it takes longer for us to detect it). Ideally the timeout factor should be tuned according to the machine type we are running on. I?m not sure that is possible, though?

> On 5 dec 2014, at 00:52, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Chris,
> 
> Sorry I mis-directed you to send this one to build-dev, as it is a hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd.
> 
> Fix looks good to me.
> 
> Thanks,
> David
> 
> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>> Please review the following fix to address JPRT timeout issues when
>> using -rtests to run hotspot JTReg tests on slow devices. The same logic
>> has been in place for jdk/test/Makefile for a while now, so I just
>> copied from there to hotspot/test/Makefile.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8066508
>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>> 
>> thanks,
>> 
>> Chris
>> 


From jesper.wilhelmsson at oracle.com  Fri Dec  5 08:27:54 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 05 Dec 2014 09:27:54 +0100
Subject: Disallow flags with extra characters appended
In-Reply-To: <54812AA1.10308@oracle.com>
References: <54810CB1.2060207@oracle.com> <54812AA1.10308@oracle.com>
Message-ID: <54816C8A.1000401@oracle.com>

Hi David,

Thanks for the pointer to JDK-6522873!

Not fixing this with the motivation "due to the risk of breaking existing 
applications/scripts that already has the incorrect options specified" is 
ridiculous imho.

As I wrote in the bug just now:
We have to stop being so scared about fixing bugs. Fixing a bug like this in a 
major version (9) should cause minimal problems since people will have to 
re-certify their applications and change the command lines anyway to upgrade 
from 8 to 9.

Fixing this bug will make some people go "Oh, I made a typo" and fix it. Not 
fixing this bug will make people go "Hey, we have been running with the wrong 
settings for two years!! Why didn't this $#%@#$# VM say something?!?!"

Dear runtime team, please consider reopening this bug.

Thanks,
/Jesper


David Holmes skrev 5/12/14 04:46:
> Hi Jesper,
>
> On 5/12/2014 11:38 AM, Jesper Wilhelmsson wrote:
>> Hi,
>>
>> Today some (not all) flags are accepted even though they have random
>> characters appended to them. Some examples are -Xconcgc, -Xcomp,
>> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted when
>> written for instance -Xconcgcnoway, -Xcomposer, -Xboundthreadstodogs or
>> -XX:+AlwaysTenureAtBlueMoon
>>
>> There is a potential problem here since we will also accept things like
>> -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of
>> course without running with G1).
>>
>> I have a suggestion for a fix here:
>> http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/
>>
>> Would this be an acceptable solution?
>
> I'm somewhat surprised the single name version of match_option didn't also 
> have the _tail_allowed flag - seems rather unbalanced. But what you have is 
> cleaner I think. Though I would suggest moving you new version:
>
>  static bool match_option(const JavaVMOption *option, const char* name) {
>
> to immediately after the tail version (and before the _tail_allowed multi-name 
> version), which a suitable comment added.
>
> That said ...
>
>> I couldn't find one, but since this has been around for quite some time
>> I wonder if there is a bug for this already. If not I'll create one.
>
> ... this has already been rejected
>
> https://bugs.openjdk.java.net/browse/JDK-6522873
>
> Thanks,
> David
>
>> Thanks,
>> /Jesper
>>


From david.holmes at oracle.com  Fri Dec  5 09:22:39 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 19:22:39 +1000
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com>
References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com>
	<65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com>
Message-ID: <5481795F.4020403@oracle.com>

On 5/12/2014 6:11 PM, Staffan Larsen wrote:
> Running with longer timeouts on fast machines makes the testing less responsive (if a test is on its way to timeout it takes longer for us to detect it). Ideally the timeout factor should be tuned according to the machine type we are running on. I?m not sure that is possible, though?

We don't have that level of control unfortunately.

David

>> On 5 dec 2014, at 00:52, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> Sorry I mis-directed you to send this one to build-dev, as it is a hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd.
>>
>> Fix looks good to me.
>>
>> Thanks,
>> David
>>
>> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>>> Please review the following fix to address JPRT timeout issues when
>>> using -rtests to run hotspot JTReg tests on slow devices. The same logic
>>> has been in place for jdk/test/Makefile for a while now, so I just
>>> copied from there to hotspot/test/Makefile.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8066508
>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>>
>>> thanks,
>>>
>>> Chris
>>>
>

From staffan.larsen at oracle.com  Fri Dec  5 09:33:59 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 5 Dec 2014 10:33:59 +0100
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <5481795F.4020403@oracle.com>
References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com>
	<65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com>
	<5481795F.4020403@oracle.com>
Message-ID: <861FF0F5-C825-43C5-833E-F5C6BA2E4ACF@oracle.com>


> On 5 dec 2014, at 10:22, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 5/12/2014 6:11 PM, Staffan Larsen wrote:
>> Running with longer timeouts on fast machines makes the testing less responsive (if a test is on its way to timeout it takes longer for us to detect it). Ideally the timeout factor should be tuned according to the machine type we are running on. I?m not sure that is possible, though?
> 
> We don't have that level of control unfortunately.

Too bad.

/Staffan

> 
> David
> 
>>> On 5 dec 2014, at 00:52, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Sorry I mis-directed you to send this one to build-dev, as it is a hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd.
>>> 
>>> Fix looks good to me.
>>> 
>>> Thanks,
>>> David
>>> 
>>> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>>>> Please review the following fix to address JPRT timeout issues when
>>>> using -rtests to run hotspot JTReg tests on slow devices. The same logic
>>>> has been in place for jdk/test/Makefile for a while now, so I just
>>>> copied from there to hotspot/test/Makefile.
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8066508
>>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>>> 
>>>> thanks,
>>>> 
>>>> Chris
>>>> 
>> 


From david.holmes at oracle.com  Fri Dec  5 09:38:30 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 19:38:30 +1000
Subject: Disallow flags with extra characters appended
In-Reply-To: <54816C8A.1000401@oracle.com>
References: <54810CB1.2060207@oracle.com> <54812AA1.10308@oracle.com>
	<54816C8A.1000401@oracle.com>
Message-ID: <54817D16.9000609@oracle.com>

On 5/12/2014 6:27 PM, Jesper Wilhelmsson wrote:
> Hi David,
>
> Thanks for the pointer to JDK-6522873!
>
> Not fixing this with the motivation "due to the risk of breaking
> existing applications/scripts that already has the incorrect options
> specified" is ridiculous imho.
>
> As I wrote in the bug just now:
> We have to stop being so scared about fixing bugs. Fixing a bug like
> this in a major version (9) should cause minimal problems since people
> will have to re-certify their applications and change the command lines
> anyway to upgrade from 8 to 9.
>
> Fixing this bug will make some people go "Oh, I made a typo" and fix it.
> Not fixing this bug will make people go "Hey, we have been running with
> the wrong settings for two years!! Why didn't this $#%@#$# VM say
> something?!?!"

I tend to agree that fixing this in a major release like 9 seems to be 
not unreasonable. However it is easy to under estimate the compatibility 
aspect of simple changes - even though that can be very frustrating. 
Given most of the -X options are pretty useless I don't see this as 
likely being a major problem. Even so I come down slightly on the side 
of fixing it.

And as you note 4514888 already fixed this in 5 and we seem to have 
regressed since then.

David

> Dear runtime team, please consider reopening this bug.
>
> Thanks,
> /Jesper
>
>
> David Holmes skrev 5/12/14 04:46:
>> Hi Jesper,
>>
>> On 5/12/2014 11:38 AM, Jesper Wilhelmsson wrote:
>>> Hi,
>>>
>>> Today some (not all) flags are accepted even though they have random
>>> characters appended to them. Some examples are -Xconcgc, -Xcomp,
>>> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted when
>>> written for instance -Xconcgcnoway, -Xcomposer, -Xboundthreadstodogs or
>>> -XX:+AlwaysTenureAtBlueMoon
>>>
>>> There is a potential problem here since we will also accept things like
>>> -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of
>>> course without running with G1).
>>>
>>> I have a suggestion for a fix here:
>>> http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/
>>>
>>> Would this be an acceptable solution?
>>
>> I'm somewhat surprised the single name version of match_option didn't
>> also have the _tail_allowed flag - seems rather unbalanced. But what
>> you have is cleaner I think. Though I would suggest moving you new
>> version:
>>
>>  static bool match_option(const JavaVMOption *option, const char* name) {
>>
>> to immediately after the tail version (and before the _tail_allowed
>> multi-name version), which a suitable comment added.
>>
>> That said ...
>>
>>> I couldn't find one, but since this has been around for quite some time
>>> I wonder if there is a bug for this already. If not I'll create one.
>>
>> ... this has already been rejected
>>
>> https://bugs.openjdk.java.net/browse/JDK-6522873
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>> /Jesper
>>>
>

From ioi.lam at oracle.com  Fri Dec  5 09:43:52 2014
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 05 Dec 2014 01:43:52 -0800
Subject: Disallow flags with extra characters appended
In-Reply-To: <54817D16.9000609@oracle.com>
References: <54810CB1.2060207@oracle.com>
	<54812AA1.10308@oracle.com>	<54816C8A.1000401@oracle.com>
	<54817D16.9000609@oracle.com>
Message-ID: <54817E58.4040208@oracle.com>


On 12/5/14, 1:38 AM, David Holmes wrote:
> On 5/12/2014 6:27 PM, Jesper Wilhelmsson wrote:
>> Hi David,
>>
>> Thanks for the pointer to JDK-6522873!
>>
>> Not fixing this with the motivation "due to the risk of breaking
>> existing applications/scripts that already has the incorrect options
>> specified" is ridiculous imho.
>>
>> As I wrote in the bug just now:
>> We have to stop being so scared about fixing bugs. Fixing a bug like
>> this in a major version (9) should cause minimal problems since people
>> will have to re-certify their applications and change the command lines
>> anyway to upgrade from 8 to 9.
>>
>> Fixing this bug will make some people go "Oh, I made a typo" and fix it.
>> Not fixing this bug will make people go "Hey, we have been running with
>> the wrong settings for two years!! Why didn't this $#%@#$# VM say
>> something?!?!"
>
> I tend to agree that fixing this in a major release like 9 seems to be 
> not unreasonable. However it is easy to under estimate the 
> compatibility aspect of simple changes - even though that can be very 
> frustrating. Given most of the -X options are pretty useless I don't 
> see this as likely being a major problem. Even so I come down slightly 
> on the side of fixing it.
>
> And as you note 4514888 already fixed this in 5 and we seem to have 
> regressed since then.
>
I think it's reasonable to fix for 9. Since there's a compatibility 
concern, we should get a CCC approval. Also, maybe a 
-XX:+DontComplainAboutRubbishAfterOptionsSinceIamTooLazyToFixMyScripts 
flag for backwards compatibility? People who are truly lazy can just add 
this in their JAVA_OPTS environment variable.

- Ioi
> David
>
>> Dear runtime team, please consider reopening this bug.
>>
>> Thanks,
>> /Jesper
>>
>>
>> David Holmes skrev 5/12/14 04:46:
>>> Hi Jesper,
>>>
>>> On 5/12/2014 11:38 AM, Jesper Wilhelmsson wrote:
>>>> Hi,
>>>>
>>>> Today some (not all) flags are accepted even though they have random
>>>> characters appended to them. Some examples are -Xconcgc, -Xcomp,
>>>> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted when
>>>> written for instance -Xconcgcnoway, -Xcomposer, 
>>>> -Xboundthreadstodogs or
>>>> -XX:+AlwaysTenureAtBlueMoon
>>>>
>>>> There is a potential problem here since we will also accept things 
>>>> like
>>>> -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of
>>>> course without running with G1).
>>>>
>>>> I have a suggestion for a fix here:
>>>> http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/
>>>>
>>>> Would this be an acceptable solution?
>>>
>>> I'm somewhat surprised the single name version of match_option didn't
>>> also have the _tail_allowed flag - seems rather unbalanced. But what
>>> you have is cleaner I think. Though I would suggest moving you new
>>> version:
>>>
>>>  static bool match_option(const JavaVMOption *option, const char* 
>>> name) {
>>>
>>> to immediately after the tail version (and before the _tail_allowed
>>> multi-name version), which a suitable comment added.
>>>
>>> That said ...
>>>
>>>> I couldn't find one, but since this has been around for quite some 
>>>> time
>>>> I wonder if there is a bug for this already. If not I'll create one.
>>>
>>> ... this has already been rejected
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-6522873
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks,
>>>> /Jesper
>>>>
>>


From david.holmes at oracle.com  Fri Dec  5 09:45:37 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 19:45:37 +1000
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <5481795F.4020403@oracle.com>
References: <5480C601.9040701@oracle.com>
	<5480F3A2.9070600@oracle.com>	<65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com>
	<5481795F.4020403@oracle.com>
Message-ID: <54817EC1.4070407@oracle.com>

On 5/12/2014 7:22 PM, David Holmes wrote:
> On 5/12/2014 6:11 PM, Staffan Larsen wrote:
>> Running with longer timeouts on fast machines makes the testing less
>> responsive (if a test is on its way to timeout it takes longer for us
>> to detect it). Ideally the timeout factor should be tuned according to
>> the machine type we are running on. I?m not sure that is possible,
>> though?
>
> We don't have that level of control unfortunately.

Sorry that's not true. As this is our Makefile we could make the timeout 
value platform specific (though remember this is an open file). And if 
we have some means of defining a performance metric for a machine, we 
could even tune it for the current machine - but I'm not sure we'd want 
to go that path anyway. Perhaps a RFE.

What Chris is proposing addresses a current problem and brings hotspot 
testing into line with what the JDK testing has been doing since 2009. :)

David

> David
>
>>> On 5 dec 2014, at 00:52, David Holmes <david.holmes at oracle.com> wrote:
>>>
>>> Hi Chris,
>>>
>>> Sorry I mis-directed you to send this one to build-dev, as it is a
>>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd.
>>>
>>> Fix looks good to me.
>>>
>>> Thanks,
>>> David
>>>
>>> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>>>> Please review the following fix to address JPRT timeout issues when
>>>> using -rtests to run hotspot JTReg tests on slow devices. The same
>>>> logic
>>>> has been in place for jdk/test/Makefile for a while now, so I just
>>>> copied from there to hotspot/test/Makefile.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8066508
>>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>

From stefan.johansson at oracle.com  Fri Dec  5 10:01:02 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 05 Dec 2014 11:01:02 +0100
Subject: RFR: 8062672: JVM crashes during GC on various asserts which checks
	that HeapWord ptr is an oop
Message-ID: <5481825E.4080602@oracle.com>

Hi,

Please review this fix for the linux-sparc issue described in:
https://bugs.openjdk.java.net/browse/JDK-8062672

Webrev:
http://cr.openjdk.java.net/~sjohanss/8062672/hotspot.00/

Summary:
This fix is based on 7u-dev because the most linux-sparc testing is done 
for that release and also because it's unclear if we have time to move 
the fix the normal way through 9 and 8u before going into 7u. But the 
main reason is that it would be good to get testing of the fix in 7u 
before porting it to 8u and 9.

The fix it self is fairly simple, after JDK-8029190 was backported the 
condition for disabling UseMemSetInBOT changed from is_niagara() to 
has_blk_init(). This worked well for solaris-sparc but on linux-sparc we 
previously only set the niagara feature bits, so this change adds 
support for detecting blk_init support on linux-sparc.

Testing:
Crashes/asserts was reproducible without the fix and after the fix none 
have been observed. Also verified that UseMemSetInBOT now is set to 
false as it should be.

Thanks,
Stefan

From manasthakur17 at gmail.com  Fri Dec  5 10:29:12 2014
From: manasthakur17 at gmail.com (Manas Thakur)
Date: Fri, 5 Dec 2014 15:59:12 +0530
Subject: Locating call sites of methods in C2
Message-ID: <84EF5E26-832F-4D4D-A573-4ADB83A39BCA@gmail.com>

Hi

Is there a way to access the call-site (possibly in terms of the bytecode offset) of a method being compiled by C2? Doesn?t the current compile task store it in some variable?

Regards,
Manas


From tatiana.pivovarova at oracle.com  Fri Dec  5 12:37:56 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Fri, 05 Dec 2014 15:37:56 +0300
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method
	to be implemented
Message-ID: <5481A724.1070107@oracle.com>

Hi all,

please review this new small patch

bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/

Problem:
Need WhiteBox::allocateCodeBlob(long, int), currently only 
WhiteBox::allocateCodeBlob(int, int) exist.

I change previous fix to this new patch because this conversation [*]

Solution:
   public long allocateCodeBlob(long size, int type) {
       return allocateCodeBlob((int) size, type);
   }

Test: jprt

[*] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html

Thanks,
Tatiana

From jesper.wilhelmsson at oracle.com  Fri Dec  5 13:39:12 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 05 Dec 2014 14:39:12 +0100
Subject: Disallow flags with extra characters appended
In-Reply-To: <54817E58.4040208@oracle.com>
References: <54810CB1.2060207@oracle.com>	<54812AA1.10308@oracle.com>	<54816C8A.1000401@oracle.com>	<54817D16.9000609@oracle.com>
	<54817E58.4040208@oracle.com>
Message-ID: <5481B580.9000807@oracle.com>

Hi,

In the hope that JDK-6522873 will be reopened I'm sending a proper RFR to the 
runtime list. Thanks David for your initial review, I have updated the change as 
you suggested. I also found a few more flags that should be covered by this 
change. A full list of flags is available in the RFR.

Thanks,
/Jesper

Ioi Lam skrev 5/12/14 10:43:
>
> On 12/5/14, 1:38 AM, David Holmes wrote:
>> On 5/12/2014 6:27 PM, Jesper Wilhelmsson wrote:
>>> Hi David,
>>>
>>> Thanks for the pointer to JDK-6522873!
>>>
>>> Not fixing this with the motivation "due to the risk of breaking
>>> existing applications/scripts that already has the incorrect options
>>> specified" is ridiculous imho.
>>>
>>> As I wrote in the bug just now:
>>> We have to stop being so scared about fixing bugs. Fixing a bug like
>>> this in a major version (9) should cause minimal problems since people
>>> will have to re-certify their applications and change the command lines
>>> anyway to upgrade from 8 to 9.
>>>
>>> Fixing this bug will make some people go "Oh, I made a typo" and fix it.
>>> Not fixing this bug will make people go "Hey, we have been running with
>>> the wrong settings for two years!! Why didn't this $#%@#$# VM say
>>> something?!?!"
>>
>> I tend to agree that fixing this in a major release like 9 seems to be not
>> unreasonable. However it is easy to under estimate the compatibility aspect of
>> simple changes - even though that can be very frustrating. Given most of the
>> -X options are pretty useless I don't see this as likely being a major
>> problem. Even so I come down slightly on the side of fixing it.
>>
>> And as you note 4514888 already fixed this in 5 and we seem to have regressed
>> since then.
>>
> I think it's reasonable to fix for 9. Since there's a compatibility concern, we
> should get a CCC approval. Also, maybe a
> -XX:+DontComplainAboutRubbishAfterOptionsSinceIamTooLazyToFixMyScripts flag for
> backwards compatibility? People who are truly lazy can just add this in their
> JAVA_OPTS environment variable.
>
> - Ioi
>> David
>>
>>> Dear runtime team, please consider reopening this bug.
>>>
>>> Thanks,
>>> /Jesper
>>>
>>>
>>> David Holmes skrev 5/12/14 04:46:
>>>> Hi Jesper,
>>>>
>>>> On 5/12/2014 11:38 AM, Jesper Wilhelmsson wrote:
>>>>> Hi,
>>>>>
>>>>> Today some (not all) flags are accepted even though they have random
>>>>> characters appended to them. Some examples are -Xconcgc, -Xcomp,
>>>>> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted when
>>>>> written for instance -Xconcgcnoway, -Xcomposer, -Xboundthreadstodogs or
>>>>> -XX:+AlwaysTenureAtBlueMoon
>>>>>
>>>>> There is a potential problem here since we will also accept things like
>>>>> -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of
>>>>> course without running with G1).
>>>>>
>>>>> I have a suggestion for a fix here:
>>>>> http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/
>>>>>
>>>>> Would this be an acceptable solution?
>>>>
>>>> I'm somewhat surprised the single name version of match_option didn't
>>>> also have the _tail_allowed flag - seems rather unbalanced. But what
>>>> you have is cleaner I think. Though I would suggest moving you new
>>>> version:
>>>>
>>>>  static bool match_option(const JavaVMOption *option, const char* name) {
>>>>
>>>> to immediately after the tail version (and before the _tail_allowed
>>>> multi-name version), which a suitable comment added.
>>>>
>>>> That said ...
>>>>
>>>>> I couldn't find one, but since this has been around for quite some time
>>>>> I wonder if there is a bug for this already. If not I'll create one.
>>>>
>>>> ... this has already been rejected
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-6522873
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks,
>>>>> /Jesper
>>>>>
>>>
>

From stefan.karlsson at oracle.com  Fri Dec  5 13:51:12 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 05 Dec 2014 08:51:12 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <547F64F6.7010001@oracle.com>
References: <547F1C6E.1070701@oracle.com> <547F64F6.7010001@oracle.com>
Message-ID: <5481B850.1070709@oracle.com>

Hi Harold,

Thanks for looking at the patch. My first patch used nullHandle and did 
the freeing was done inside an else statement, but during a pre-review 
of the patch I got feedback to change it to CHECK_NULL and get rid of 
the else statement. :)

Here's a new webrev with nullHandle and the else statement:
http://cr.openjdk.java.net/~stefank/8065634/webrev.02

Thanks,
StefanK

On 2014-12-03 14:31, harold seigel wrote:
> Hi Stefan,
>
> The change looks good but I have a couple of questions.
>
> 1. Why does the call to create_combined_annotations(), in 
> parseClassFile(), use CHECK_NULL when other calls use 
> CHECK_(nullHandle) ?
>
> 4021     ClassAnnotationCollector parsed_annotations;
> 4022     parse_classfile_attributes(&parsed_annotations, 
> CHECK_(nullHandle));
> 4023
> 4024     // Finalize the Annotations metadata object,
> 4025     // now that all annotation arrays have been created.
> 4026     create_combined_annotations(CHECK_NULL);
> 4027
> 4028     // Make sure this is the end of class file stream
> 4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end of 
> class file %s", CHECK_(nullHandle));
>
>
> 2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
> Annotations::free_contents() need to be called if the *_annotation 
> fields are NULL?
>
>
> Thanks, Harold
>
> On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please, review this patch to fix an issue where the GC encounters an 
>> InstanceKlass before it has come far enough in the class loading 
>> process.
>>
>> Some background to the fix:
>>
>> When the JVM loads classes it has to keep track of the allocated 
>> Metadata, and in the event of an exception deallocate the Metadata. 
>> The ClassFileParser saves the Metadata pointers so that it knows what 
>> needs to be deallocated. When the class loading has come far enough 
>> there's a point were the GC can take over the ownership of the 
>> Metadata and do deallocation of the both the InstanceKlass and the 
>> Metadata, if needed. At that point the Metadata pointers in the 
>> ClassFileParser are cleared and transfered over to the InstanceKlass.
>>
>> Most Metadata allocations happen before the InstanceKlass is 
>> allocated, but the Annotations are allocated after the InstanceKlass 
>> but before the transferal and clearing of the Metadata pointers in 
>> the ClassFileParser. If the GC stops when allocating the Annotations, 
>> it will likely find this InstanceKlass and assume that the Metadata 
>> are correctly setup. This is exactly what's happening in the bug 
>> report. The GC finds that the _methods array, unexpectedly, points to 
>> NULL.
>>
>> The proposed solution to this problem is to allocate the Annotations 
>> before the InstanceKlass is allocated.
>>
>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>
>> Testing:
>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>
>> Thanks,
>> StefanK
>


From stefan.karlsson at oracle.com  Fri Dec  5 13:59:57 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 05 Dec 2014 08:59:57 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <5480DDF9.8050405@oracle.com>
References: <547F1C6E.1070701@oracle.com>
	<547F64F6.7010001@oracle.com>	<547F8276.8090205@oracle.com>
	<548060CC.9010405@oracle.com> <5480DDF9.8050405@oracle.com>
Message-ID: <5481BA5D.1050201@oracle.com>

Hi Poonam,

Thanks for reviewing.

On 2014-12-04 17:19, Poonam Bajaj Parhar wrote:
> Hello Stefan,
>
> The changes look good to me.
>
> Perhaps the comment for the following code can be modified from:
>
> 3132     // The annotations below has been transfered the 
> _combined_annotations
> 3133     // so these fields can now be cleared.
> 3134     _annotations             = NULL;
> 3135     _type_annotations        = NULL;
> 3136     _fields_annotations      = NULL;
> 3137     _fields_type_annotations = NULL;
> 3138 }
>
> to
>
> 3132     // The annotations arrays below have been transferred to the 
> _combined_annotations

I'll change the comment before pushing.

>
> Also, if possible, would be good if we can change the name of 
> _annotations field to _class_annotations; more like the names of the 
> other annotations arrays.

It's a good suggestion, but that change itself is around two times 
larger in the number of changed lines, so I don't want to do it as a 
part of this bug fix. I've created the following bug:
https://bugs.openjdk.java.net/browse/JDK-8066774

Thanks,
StefanK

>
> Thanks,
> Poonam
>
>
> On 12/4/2014 5:25 AM, harold seigel wrote:
>> Hi,
>>
>> How about adding an 'else' statement at line 4342?  That would make 
>> the code consistent with the comments at lines 4329-4330 and 4343-4344.
>>
>> 4328   if (_combined_annotations != NULL) {
>> 4329     // After all annotations arrays have been created, they are 
>> installed into the
>> 4330     // Annotations object that will be assigned to the 
>> InstanceKlass being created.
>> 4331
>> 4332     // Deallocate the Annotations object and the installed 
>> annotations arrays.
>> 4333 _combined_annotations->deallocate_contents(_loader_data);
>> 4334
>> 4335     // If the _combined_annotations pointer is non-NULL,
>> 4336     // then the other annotations fields should have been cleared.
>> 4337     assert(_annotations             == NULL, "Should have been 
>> cleared");
>> 4338     assert(_type_annotations        == NULL, "Should have been 
>> cleared");
>> 4339     assert(_fields_annotations      == NULL, "Should have been 
>> cleared");
>> 4340     assert(_fields_type_annotations == NULL, "Should have been 
>> cleared");
>> 4341   }
>> 4342
>> 4343   // If the annotations arrays were not installed into the 
>> Annotations object,
>> 4344   // then they have to be deallocated explicitly.
>> 4345   MetadataFactory::free_array<u1>(_loader_data, _annotations);
>> 4346   MetadataFactory::free_array<u1>(_loader_data, _type_annotations);
>> 4347   Annotations::free_contents(_loader_data, _fields_annotations);
>> 4348   Annotations::free_contents(_loader_data, 
>> _fields_type_annotations);
>>
>> Thanks, Harold
>>
>> On 12/3/2014 4:36 PM, Coleen Phillimore wrote:
>>>
>>> On 12/3/14, 2:31 PM, harold seigel wrote:
>>>> Hi Stefan,
>>>>
>>>> The change looks good but I have a couple of questions.
>>>>
>>>> 1. Why does the call to create_combined_annotations(), in 
>>>> parseClassFile(), use CHECK_NULL when other calls use 
>>>> CHECK_(nullHandle) ?
>>>>
>>>> 4021     ClassAnnotationCollector parsed_annotations;
>>>> 4022     parse_classfile_attributes(&parsed_annotations, 
>>>> CHECK_(nullHandle));
>>>> 4023
>>>> 4024     // Finalize the Annotations metadata object,
>>>> 4025     // now that all annotation arrays have been created.
>>>> 4026     create_combined_annotations(CHECK_NULL);
>>>> 4027
>>>> 4028     // Make sure this is the end of class file stream
>>>> 4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end 
>>>> of class file %s", CHECK_(nullHandle));
>>>
>>> Oh, this is my fault. https://bugs.openjdk.java.net/browse/JDK-8066624
>>> If it looks inconsistent, maybe it can be changed to 
>>> CHECK_(nullHandle);
>>>>
>>>>
>>>> 2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
>>>> Annotations::free_contents() need to be called if the *_annotation 
>>>> fields are NULL?
>>>
>>> free_array() checks for null and is inlined so there isn't another 
>>> need for checking if the Array is null first.
>>>
>>> This change looks good to me.
>>>
>>> Coleen
>>>>
>>>>
>>>> Thanks, Harold
>>>>
>>>> On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
>>>>> Hi all,
>>>>>
>>>>> Please, review this patch to fix an issue where the GC encounters 
>>>>> an InstanceKlass before it has come far enough in the class 
>>>>> loading process.
>>>>>
>>>>> Some background to the fix:
>>>>>
>>>>> When the JVM loads classes it has to keep track of the allocated 
>>>>> Metadata, and in the event of an exception deallocate the 
>>>>> Metadata. The ClassFileParser saves the Metadata pointers so that 
>>>>> it knows what needs to be deallocated. When the class loading has 
>>>>> come far enough there's a point were the GC can take over the 
>>>>> ownership of the Metadata and do deallocation of the both the 
>>>>> InstanceKlass and the Metadata, if needed. At that point the 
>>>>> Metadata pointers in the ClassFileParser are cleared and 
>>>>> transfered over to the InstanceKlass.
>>>>>
>>>>> Most Metadata allocations happen before the InstanceKlass is 
>>>>> allocated, but the Annotations are allocated after the 
>>>>> InstanceKlass but before the transferal and clearing of the 
>>>>> Metadata pointers in the ClassFileParser. If the GC stops when 
>>>>> allocating the Annotations, it will likely find this InstanceKlass 
>>>>> and assume that the Metadata are correctly setup. This is exactly 
>>>>> what's happening in the bug report. The GC finds that the _methods 
>>>>> array, unexpectedly, points to NULL.
>>>>>
>>>>> The proposed solution to this problem is to allocate the 
>>>>> Annotations before the InstanceKlass is allocated.
>>>>>
>>>>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>>>>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>>>>
>>>>> Testing:
>>>>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>>>>
>>>>> Thanks,
>>>>> StefanK
>>>>
>>>
>>
>


From harold.seigel at oracle.com  Fri Dec  5 14:04:27 2014
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 05 Dec 2014 09:04:27 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <5481B850.1070709@oracle.com>
References: <547F1C6E.1070701@oracle.com> <547F64F6.7010001@oracle.com>
	<5481B850.1070709@oracle.com>
Message-ID: <5481BB6B.7010003@oracle.com>

Hi Stefan,

Thanks for restoring the 'else' and the 'nullHandle'.  It looks good!

Harold

On 12/5/2014 8:51 AM, Stefan Karlsson wrote:
> Hi Harold,
>
> Thanks for looking at the patch. My first patch used nullHandle and 
> did the freeing was done inside an else statement, but during a 
> pre-review of the patch I got feedback to change it to CHECK_NULL and 
> get rid of the else statement. :)
>
> Here's a new webrev with nullHandle and the else statement:
> http://cr.openjdk.java.net/~stefank/8065634/webrev.02
>
> Thanks,
> StefanK
>
> On 2014-12-03 14:31, harold seigel wrote:
>> Hi Stefan,
>>
>> The change looks good but I have a couple of questions.
>>
>> 1. Why does the call to create_combined_annotations(), in 
>> parseClassFile(), use CHECK_NULL when other calls use 
>> CHECK_(nullHandle) ?
>>
>> 4021     ClassAnnotationCollector parsed_annotations;
>> 4022     parse_classfile_attributes(&parsed_annotations, 
>> CHECK_(nullHandle));
>> 4023
>> 4024     // Finalize the Annotations metadata object,
>> 4025     // now that all annotation arrays have been created.
>> 4026     create_combined_annotations(CHECK_NULL);
>> 4027
>> 4028     // Make sure this is the end of class file stream
>> 4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end of 
>> class file %s", CHECK_(nullHandle));
>>
>>
>> 2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
>> Annotations::free_contents() need to be called if the *_annotation 
>> fields are NULL?
>>
>>
>> Thanks, Harold
>>
>> On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please, review this patch to fix an issue where the GC encounters an 
>>> InstanceKlass before it has come far enough in the class loading 
>>> process.
>>>
>>> Some background to the fix:
>>>
>>> When the JVM loads classes it has to keep track of the allocated 
>>> Metadata, and in the event of an exception deallocate the Metadata. 
>>> The ClassFileParser saves the Metadata pointers so that it knows 
>>> what needs to be deallocated. When the class loading has come far 
>>> enough there's a point were the GC can take over the ownership of 
>>> the Metadata and do deallocation of the both the InstanceKlass and 
>>> the Metadata, if needed. At that point the Metadata pointers in the 
>>> ClassFileParser are cleared and transfered over to the InstanceKlass.
>>>
>>> Most Metadata allocations happen before the InstanceKlass is 
>>> allocated, but the Annotations are allocated after the InstanceKlass 
>>> but before the transferal and clearing of the Metadata pointers in 
>>> the ClassFileParser. If the GC stops when allocating the 
>>> Annotations, it will likely find this InstanceKlass and assume that 
>>> the Metadata are correctly setup. This is exactly what's happening 
>>> in the bug report. The GC finds that the _methods array, 
>>> unexpectedly, points to NULL.
>>>
>>> The proposed solution to this problem is to allocate the Annotations 
>>> before the InstanceKlass is allocated.
>>>
>>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>>
>>> Testing:
>>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>>
>>> Thanks,
>>> StefanK
>>
>


From daniel.daugherty at oracle.com  Fri Dec  5 14:05:18 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 05 Dec 2014 07:05:18 -0700
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <54817EC1.4070407@oracle.com>
References: <5480C601.9040701@oracle.com>
	<5480F3A2.9070600@oracle.com>	<65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com>
	<5481795F.4020403@oracle.com> <54817EC1.4070407@oracle.com>
Message-ID: <5481BB9E.5040906@oracle.com>

On 12/5/14 2:45 AM, David Holmes wrote:
> On 5/12/2014 7:22 PM, David Holmes wrote:
>> On 5/12/2014 6:11 PM, Staffan Larsen wrote:
>>> Running with longer timeouts on fast machines makes the testing less
>>> responsive (if a test is on its way to timeout it takes longer for us
>>> to detect it). Ideally the timeout factor should be tuned according to
>>> the machine type we are running on. I?m not sure that is possible,
>>> though?
>>
>> We don't have that level of control unfortunately.
>
> Sorry that's not true. As this is our Makefile we could make the 
> timeout value platform specific (though remember this is an open 
> file). And if we have some means of defining a performance metric for 
> a machine, we could even tune it for the current machine - but I'm not 
> sure we'd want to go that path anyway. Perhaps a RFE.
>
> What Chris is proposing addresses a current problem and brings hotspot 
> testing into line with what the JDK testing has been doing since 2009. :)

I'm fairly certain that VM/SQE nightly tunes the JavaTest/JTREG
timeout factor depending on the machine type or the machine name
itself; I don't know the exact details. I suspect that this is
possible in VM/SQE nightly/Aurora because there is a database
of per-machine info.

It might be possible to do something similar for JPRT if it
tracks information per client machine...

Dan


>
> David
>
>> David
>>
>>>> On 5 dec 2014, at 00:52, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Chris,
>>>>
>>>> Sorry I mis-directed you to send this one to build-dev, as it is a
>>>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now 
>>>> cc'd.
>>>>
>>>> Fix looks good to me.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>>>>> Please review the following fix to address JPRT timeout issues when
>>>>> using -rtests to run hotspot JTReg tests on slow devices. The same
>>>>> logic
>>>>> has been in place for jdk/test/Makefile for a while now, so I just
>>>>> copied from there to hotspot/test/Makefile.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8066508
>>>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>
>
>
>


From stefan.karlsson at oracle.com  Fri Dec  5 14:06:47 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 05 Dec 2014 09:06:47 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <5481BB6B.7010003@oracle.com>
References: <547F1C6E.1070701@oracle.com> <547F64F6.7010001@oracle.com>
	<5481B850.1070709@oracle.com> <5481BB6B.7010003@oracle.com>
Message-ID: <5481BBF7.6080805@oracle.com>

On 2014-12-05 09:04, harold seigel wrote:
> Hi Stefan,
>
> Thanks for restoring the 'else' and the 'nullHandle'.  It looks good!

Thanks!

StefanK

>
> Harold
>
> On 12/5/2014 8:51 AM, Stefan Karlsson wrote:
>> Hi Harold,
>>
>> Thanks for looking at the patch. My first patch used nullHandle and 
>> did the freeing was done inside an else statement, but during a 
>> pre-review of the patch I got feedback to change it to CHECK_NULL and 
>> get rid of the else statement. :)
>>
>> Here's a new webrev with nullHandle and the else statement:
>> http://cr.openjdk.java.net/~stefank/8065634/webrev.02
>>
>> Thanks,
>> StefanK
>>
>> On 2014-12-03 14:31, harold seigel wrote:
>>> Hi Stefan,
>>>
>>> The change looks good but I have a couple of questions.
>>>
>>> 1. Why does the call to create_combined_annotations(), in 
>>> parseClassFile(), use CHECK_NULL when other calls use 
>>> CHECK_(nullHandle) ?
>>>
>>> 4021     ClassAnnotationCollector parsed_annotations;
>>> 4022     parse_classfile_attributes(&parsed_annotations, 
>>> CHECK_(nullHandle));
>>> 4023
>>> 4024     // Finalize the Annotations metadata object,
>>> 4025     // now that all annotation arrays have been created.
>>> 4026     create_combined_annotations(CHECK_NULL);
>>> 4027
>>> 4028     // Make sure this is the end of class file stream
>>> 4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end 
>>> of class file %s", CHECK_(nullHandle));
>>>
>>>
>>> 2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
>>> Annotations::free_contents() need to be called if the *_annotation 
>>> fields are NULL?
>>>
>>>
>>> Thanks, Harold
>>>
>>> On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> Please, review this patch to fix an issue where the GC encounters 
>>>> an InstanceKlass before it has come far enough in the class loading 
>>>> process.
>>>>
>>>> Some background to the fix:
>>>>
>>>> When the JVM loads classes it has to keep track of the allocated 
>>>> Metadata, and in the event of an exception deallocate the Metadata. 
>>>> The ClassFileParser saves the Metadata pointers so that it knows 
>>>> what needs to be deallocated. When the class loading has come far 
>>>> enough there's a point were the GC can take over the ownership of 
>>>> the Metadata and do deallocation of the both the InstanceKlass and 
>>>> the Metadata, if needed. At that point the Metadata pointers in the 
>>>> ClassFileParser are cleared and transfered over to the InstanceKlass.
>>>>
>>>> Most Metadata allocations happen before the InstanceKlass is 
>>>> allocated, but the Annotations are allocated after the 
>>>> InstanceKlass but before the transferal and clearing of the 
>>>> Metadata pointers in the ClassFileParser. If the GC stops when 
>>>> allocating the Annotations, it will likely find this InstanceKlass 
>>>> and assume that the Metadata are correctly setup. This is exactly 
>>>> what's happening in the bug report. The GC finds that the _methods 
>>>> array, unexpectedly, points to NULL.
>>>>
>>>> The proposed solution to this problem is to allocate the 
>>>> Annotations before the InstanceKlass is allocated.
>>>>
>>>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>>>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>>>
>>>> Testing:
>>>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>>>
>>>> Thanks,
>>>> StefanK
>>>
>>
>


From magnus.ihse.bursie at oracle.com  Fri Dec  5 14:47:01 2014
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 05 Dec 2014 15:47:01 +0100
Subject: RFR: JDK-8065576: Enable pipefail in the shell used by make to
	better detect build errors
In-Reply-To: <547C6CAE.40600@oracle.com>
References: <5475EA0E.6040405@oracle.com> <54766066.9060206@oracle.com>
	<547C6CAE.40600@oracle.com>
Message-ID: <5481C565.4080204@oracle.com>


On 2014-12-01 14:27, Erik Joelsson wrote:
> Hello,
>
> New webrev, which addresses Magnus' concern below, and various fixes 
> in Hotspot for incompatibilities with errexit.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8065576/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8065576
>
> For the LOG=trace issue Magnus described below, it was enough to just 
> replace $$(BASH) with $$(SHELL) and things worked as expected for me.

I'm a bit surprised at this. Did the options really fall through into 
the actual shell executing in the wrapper?

But if you say it reall works, I'm fine with it. The rest of the code 
looks good.

/Magnus


From coleen.phillimore at oracle.com  Fri Dec  5 15:55:35 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 05 Dec 2014 10:55:35 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <5481BBF7.6080805@oracle.com>
References: <547F1C6E.1070701@oracle.com>
	<547F64F6.7010001@oracle.com>	<5481B850.1070709@oracle.com>
	<5481BB6B.7010003@oracle.com> <5481BBF7.6080805@oracle.com>
Message-ID: <5481D577.1030107@oracle.com>


I agree, this is good.
Coleen

On 12/5/14, 9:06 AM, Stefan Karlsson wrote:
> On 2014-12-05 09:04, harold seigel wrote:
>> Hi Stefan,
>>
>> Thanks for restoring the 'else' and the 'nullHandle'.  It looks good!
>
> Thanks!
>
> StefanK
>
>>
>> Harold
>>
>> On 12/5/2014 8:51 AM, Stefan Karlsson wrote:
>>> Hi Harold,
>>>
>>> Thanks for looking at the patch. My first patch used nullHandle and 
>>> did the freeing was done inside an else statement, but during a 
>>> pre-review of the patch I got feedback to change it to CHECK_NULL 
>>> and get rid of the else statement. :)
>>>
>>> Here's a new webrev with nullHandle and the else statement:
>>> http://cr.openjdk.java.net/~stefank/8065634/webrev.02
>>>
>>> Thanks,
>>> StefanK
>>>
>>> On 2014-12-03 14:31, harold seigel wrote:
>>>> Hi Stefan,
>>>>
>>>> The change looks good but I have a couple of questions.
>>>>
>>>> 1. Why does the call to create_combined_annotations(), in 
>>>> parseClassFile(), use CHECK_NULL when other calls use 
>>>> CHECK_(nullHandle) ?
>>>>
>>>> 4021     ClassAnnotationCollector parsed_annotations;
>>>> 4022     parse_classfile_attributes(&parsed_annotations, 
>>>> CHECK_(nullHandle));
>>>> 4023
>>>> 4024     // Finalize the Annotations metadata object,
>>>> 4025     // now that all annotation arrays have been created.
>>>> 4026     create_combined_annotations(CHECK_NULL);
>>>> 4027
>>>> 4028     // Make sure this is the end of class file stream
>>>> 4029     guarantee_property(cfs->at_eos(), "Extra bytes at the end 
>>>> of class file %s", CHECK_(nullHandle));
>>>>
>>>>
>>>> 2. In ~ClassFileParser(), does MetadataFactory::free_array() and 
>>>> Annotations::free_contents() need to be called if the *_annotation 
>>>> fields are NULL?
>>>>
>>>>
>>>> Thanks, Harold
>>>>
>>>> On 12/3/2014 9:21 AM, Stefan Karlsson wrote:
>>>>> Hi all,
>>>>>
>>>>> Please, review this patch to fix an issue where the GC encounters 
>>>>> an InstanceKlass before it has come far enough in the class 
>>>>> loading process.
>>>>>
>>>>> Some background to the fix:
>>>>>
>>>>> When the JVM loads classes it has to keep track of the allocated 
>>>>> Metadata, and in the event of an exception deallocate the 
>>>>> Metadata. The ClassFileParser saves the Metadata pointers so that 
>>>>> it knows what needs to be deallocated. When the class loading has 
>>>>> come far enough there's a point were the GC can take over the 
>>>>> ownership of the Metadata and do deallocation of the both the 
>>>>> InstanceKlass and the Metadata, if needed. At that point the 
>>>>> Metadata pointers in the ClassFileParser are cleared and 
>>>>> transfered over to the InstanceKlass.
>>>>>
>>>>> Most Metadata allocations happen before the InstanceKlass is 
>>>>> allocated, but the Annotations are allocated after the 
>>>>> InstanceKlass but before the transferal and clearing of the 
>>>>> Metadata pointers in the ClassFileParser. If the GC stops when 
>>>>> allocating the Annotations, it will likely find this InstanceKlass 
>>>>> and assume that the Metadata are correctly setup. This is exactly 
>>>>> what's happening in the bug report. The GC finds that the _methods 
>>>>> array, unexpectedly, points to NULL.
>>>>>
>>>>> The proposed solution to this problem is to allocate the 
>>>>> Annotations before the InstanceKlass is allocated.
>>>>>
>>>>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>>>>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>>>>
>>>>> Testing:
>>>>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>>>>
>>>>> Thanks,
>>>>> StefanK
>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Fri Dec  5 15:58:21 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 05 Dec 2014 10:58:21 -0500
Subject: RFR 8066171: Out of order with Metaspace allocation lock
In-Reply-To: <54812C1F.3040905@oracle.com>
References: <547F418E.6010301@oracle.com> <54812C1F.3040905@oracle.com>
Message-ID: <5481D61D.3020207@oracle.com>


On 12/4/14, 10:53 PM, David Holmes wrote:
> Hi Coleen,
>
> Do you care that you can now block at safepoints when acquiring the lock?

No, I don't think it matters that this can block.
Coleen

>
> David
>
> On 4/12/2014 2:59 AM, Coleen Phillimore wrote:
>> Summary: Lock resolved_references instead.
>>
>> When I took out the constant pool mutex, I thought I could use the
>> metaspace to synchronize this code sequence, but the metaspace_lock is
>> out of order with the DirtyCardQ_CBL_mon lock that can sometimes be
>> taken with obj_at_put() in an object array.   Since there is always a
>> resolved_reference objArrayOop attached to this class, we can lock this
>> for this cpCache entry.  John and the JSR292 guys tell me that this code
>> sequence needs to be locked against multiple setters.
>>
>> Tested with jdk/test/java/lang/invoke tests, nsk.quick.testlist.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8066171/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8066171
>>
>> Thanks,
>> Coleen


From dmitrij.pochepko at oracle.com  Fri Dec  5 17:18:49 2014
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Fri, 05 Dec 2014 20:18:49 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <5480B272.3030808@oracle.com>
References: <5480B272.3030808@oracle.com>
Message-ID: <5481E8F9.1080307@oracle.com>

Adding hotspot-dev for wider audience.
> Hi,
>
> Please review changes for
> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: 
> Test task: JMX- tests
> and
> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in 
> testlibrary for JDK-8059613
>
> It introduce a number of tests for segmented code cache, mostly 
> testing thresholds, usage,
> memory notifications using respective MemoryPoolMXBean(s).
> There is also a small modification for testlibrary(8066440) used in 
> tests.
>
> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>
> Testing: manually, using fastdebug nightly build from 2014-12-02
>
> Additional note: this patch assumes 
> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" 
> is fixed.
>
> Thanks,
> Dmitrij


From staffan.larsen at oracle.com  Fri Dec  5 19:47:57 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 5 Dec 2014 20:47:57 +0100
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <5481E8F9.1080307@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
Message-ID: <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>

Utils.ITERATION_COUNT does not look like something that is usable outside these specific tests? Should it really be part of the test library?

> On 5 dec 2014, at 18:18, Dmitrij Pochepko <Dmitrij.Pochepko at oracle.COM> wrote:
> 
> Adding hotspot-dev for wider audience.
>> Hi,
>> 
>> Please review changes for
>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: JMX- tests
>> and
>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in testlibrary for JDK-8059613
>> 
>> It introduce a number of tests for segmented code cache, mostly testing thresholds, usage,
>> memory notifications using respective MemoryPoolMXBean(s).
>> There is also a small modification for testlibrary(8066440) used in tests.
>> 
>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>> 
>> Testing: manually, using fastdebug nightly build from 2014-12-02
>> 
>> Additional note: this patch assumes "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed.
>> 
>> Thanks,
>> Dmitrij
> 


From coleen.phillimore at oracle.com  Fri Dec  5 20:08:40 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 05 Dec 2014 15:08:40 -0500
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <5480D73F.7070907@oracle.com>
References: <543EB71A.8000403@oracle.com>
	<543F174F.7040204@oracle.com>	<545CF033.4010503@oracle.com>
	<54619729.30704@oracle.com>	<546E638E.2020208@oracle.com>
	<547437EF.5010806@oracle.com> <5480D73F.7070907@oracle.com>
Message-ID: <548210C8.3080405@oracle.com>


Max,

I think these changes look great!  There were some comments about making 
this more of a static check with types or detecting deadlocks within the 
safepointing code, but the change here is a good first step and does so 
with minimal disruption to the code and minimal complexity.  So I 
consider this low-hanging fruit in order to make the code safer.

Thanks!
Coleen


On 12/4/14, 4:50 PM, Max Ockner wrote:
> Hello once again...
> I have a new (and suggestively titled) webrev: 
> http://cr.openjdk.java.net/~coleenp/8047290final/
>
> Ran aurora tests.
>
> Here is a list of "sometimes" locks:
>
> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
> "CompactibleFreeListSpace._lock" 
> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
> "freelist par lock" 
> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
> "SR_lock"                            share/vm/runtime/thread.cpp
> "CMS_markBitMap_lock" 
> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>
> The remaining "sometimes" locks can be found in 
> share/vm/runtime/mutexLocker.cpp:
>
> ParGCRareEvent_lock
> Safepoint_lock
> Threads_lock
> VMOperationQueue_lock
> VMOperationRequest_lock
> Terminator_lock
> Heap_lock
> Compile_lock
> PeriodicTask_lock
> JfrStacktrace_lock
>
>
> Thanks,
> Max Ockner
>
>
>
>
> On 11/25/2014 3:03 AM, David Holmes wrote:
>> Hi Max,
>>
>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>> Hello again,
>>>
>>> I have made changes based on all comments. There is now a pair of 
>>> assert
>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>
>> Is there an updated webrev?
>>
>>> caught another lock that I had to change to "sometimes", but the assert
>>> that caught this lock was not in wait. There are currently no locks 
>>> that
>>> use try to pass an incorrect safepoint check argument to wait().
>>> Instead, gcbasher did not catch this lock last time, when the only
>>> asserts were in lock and lock_without_safepoint. This lock is
>>> "CMS_markBitMap_lock" in
>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. 
>>>
>>> I'm guessing that it was not caught by the tests because this 
>>> section of
>>> code is not reached very often. My initial inspection failed to catch
>>> this lock because it is passed around between various structures and
>>> renamed 4 times. I have not yet found a good way to check for this
>>> situation, even with a debugger.
>>>
>>> Are there any tests which actually manage to hit every line of code?
>>
>> No. There is too much code that is dependent on low-level details of 
>> the GC used, the compilation strategy, plus the set of runtime flags 
>> used (and whether product or fastdebug). That's why we have lots of 
>> tests run in lots of different ways, to try to get coverage.
>>
>>> How should I handle this situation where I can't rely on the tests that
>>> I have run to tell me if I have missed something?
>>> At what point can I assume that everything is OK?
>>
>> Difficult to answer in general - there are a number of recommended 
>> test suites used by the runtime team, but your changes will also 
>> impact GC and compiler code and so may not get exercised by the 
>> runtime test suites (unless run with various compiler and GC 
>> options). Perhaps an ad-hoc test run similar to nightlies? Or you 
>> push after the weekly snapshot so as to maximise nightly testing, and 
>> if there are issues exposed then you have time to address them or 
>> revert the fix.
>>
>> Cheers,
>> David
>>
>>> Thanks,
>>> Max Ockner
>>>
>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>> Hi Max,
>>>>
>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>> Hello all,
>>>>> I have made these additonal changes:
>>>>> -Moved the assert() statements into the lock and 
>>>>> lock_without_safepoint
>>>>> methods.
>>>>> -Changed Monitor::SafepointAllowed to Monitor::SafepointCheckRequired
>>>>> -Changed the Monitor::SafepointCheckRequired values for several locks
>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>> MutexLocker, some were locked were locked without any MutexLocker* )
>>>>>
>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>
>>>> Generally this is all okay - a few style and other nits below.
>>>>
>>>> However you missed adding an assert in Monitor::wait to check if the
>>>> no_safepoint_check flag was being used correctly for the current 
>>>> monitor.
>>>>
>>>> Specific comments:
>>>>
>>>> src/share/vm/runtime/mutex.hpp
>>>>
>>>> This comment is no longer accurate with the moved check location:
>>>>
>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>> + // to ensure consistent checking for each lock.
>>>>
>>>> The same goes for other references to MutexLockerEx in the enum
>>>> description.
>>>>
>>>> Also copyright year needs updating.
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutex.cpp
>>>>
>>>>  898   //Ensure
>>>>  961   //Ensure
>>>>
>>>> Space needed after //
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>
>>>> +  var = new type(Mutex::pri, #var, 
>>>> vm_block,safepoint_check_allowed); \
>>>>
>>>> space needed after comma in k,s
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>
>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> Additional testing:
>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>> jtreg jfr tests
>>>>>
>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>
>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>> "CompactibleFreeListSpace._lock"
>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>
>>>>>
>>>>> "freelist par lock"
>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>
>>>>>
>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>
>>>>> The remaining "sometimes" locks can be found in
>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>
>>>>> ParGCRareEvent_lock
>>>>> Safepoint_lock
>>>>> Threads_lock
>>>>> VMOperationQueue_lock
>>>>> VMOperationRequest_lock
>>>>> Terminator_lock
>>>>> Heap_lock
>>>>> Compile_lock
>>>>> PeriodicTask_lock
>>>>> JfrStacktrace_lock
>>>>>
>>>>> I have not checked the validity of the "sometimes" locks, and I 
>>>>> believe
>>>>> that this should be a different project.
>>>>>
>>>>> Thanks for your help!
>>>>> Max Ockner
>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>> Hi Max,
>>>>>>
>>>>>> This is looking good.
>>>>>>
>>>>>> A few high-level initial comments:
>>>>>>
>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>
>>>>>> Why are the checks in MutexLocker when the state is maintained in 
>>>>>> the
>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>> check in the mutex/monitor methods.
>>>>>>
>>>>>> Checking consistent usage of the _no_safepoint_check_flag is 
>>>>>> good. But
>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>> safepoints should never be held when a thread blocks at a 
>>>>>> safepoint -
>>>>>> is there some way to easily check that? I was surprised how many 
>>>>>> locks
>>>>>> are actually not checking for safepoints.
>>>>>>
>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>> inconsistently and incorrectly?
>>>>>>
>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>> Threads_lock with a safepoint check and a safepoint has been 
>>>>>> requested
>>>>>> :) ).
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>
>>>>>>> Summary: MutexLockerEx can either acquire a lock with or without a
>>>>>>> safepoint check.
>>>>>>> In some cases, a particular lock must either safepoint check 
>>>>>>> always or
>>>>>>> never to avoid deadlocking.
>>>>>>> Some other locks have semantics which allow them to avoid deadlocks
>>>>>>> despite having a safepoint check only some of the time.
>>>>>>> All locks that are OK having inconsistent safepoint checks have 
>>>>>>> been
>>>>>>> marked. All locks that should never safepoint check and all 
>>>>>>> locks that
>>>>>>> should always safepoint check have also been marked.
>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>> check,
>>>>>>> the lock's safepointAllowed marker is checked to ensure consistent
>>>>>>> safepoint checking.
>>>>>>>
>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>
>>>>>>> Tested with:
>>>>>>>      jprt "-testset hotspot"
>>>>>>>      jtreg hotspot
>>>>>>>      vm.quick.testlist
>>>>>>>
>>>>>>> Whitebox tests:
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test
>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test
>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code
>>>>>>> should not assert. (Lock is properly acquired with no safepoint 
>>>>>>> check)
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code
>>>>>>> should not assert. (Lock is properly acquired with safepoint check)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Max
>>>>>>>
>>>>>
>>>
>


From chris.plummer at oracle.com  Fri Dec  5 20:52:38 2014
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 05 Dec 2014 12:52:38 -0800
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <5481BB9E.5040906@oracle.com>
References: <5480C601.9040701@oracle.com>	<5480F3A2.9070600@oracle.com>	<65E426D6-B2A5-467B-B7B4-E436F1D5C84E@oracle.com>	<5481795F.4020403@oracle.com>
	<54817EC1.4070407@oracle.com> <5481BB9E.5040906@oracle.com>
Message-ID: <54821B16.6030005@oracle.com>

On 12/5/14 6:05 AM, Daniel D. Daugherty wrote:
> On 12/5/14 2:45 AM, David Holmes wrote:
>> On 5/12/2014 7:22 PM, David Holmes wrote:
>>> On 5/12/2014 6:11 PM, Staffan Larsen wrote:
>>>> Running with longer timeouts on fast machines makes the testing less
>>>> responsive (if a test is on its way to timeout it takes longer for us
>>>> to detect it). Ideally the timeout factor should be tuned according to
>>>> the machine type we are running on. I?m not sure that is possible,
>>>> though?
>>>
>>> We don't have that level of control unfortunately.
>>
>> Sorry that's not true. As this is our Makefile we could make the 
>> timeout value platform specific (though remember this is an open 
>> file). And if we have some means of defining a performance metric for 
>> a machine, we could even tune it for the current machine - but I'm 
>> not sure we'd want to go that path anyway. Perhaps a RFE.
>>
>> What Chris is proposing addresses a current problem and brings 
>> hotspot testing into line with what the JDK testing has been doing 
>> since 2009. :)
>
> I'm fairly certain that VM/SQE nightly tunes the JavaTest/JTREG
> timeout factor depending on the machine type or the machine name
> itself; I don't know the exact details. I suspect that this is
> possible in VM/SQE nightly/Aurora because there is a database
> of per-machine info.
>
> It might be possible to do something similar for JPRT if it
> tracks information per client machine...
Ok. BTW, I was not suggesting a JPRT fix instead of my above fix in the 
near term. I still would like to push my fix and have the timeout for 
hotspot/test be on par with jdk/test. I still need one more reviewer.

thanks,

Chris
>
> Dan
>
>
>>
>> David
>>
>>> David
>>>
>>>>> On 5 dec 2014, at 00:52, David Holmes <david.holmes at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Sorry I mis-directed you to send this one to build-dev, as it is a
>>>>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now 
>>>>> cc'd.
>>>>>
>>>>> Fix looks good to me.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>>>>>> Please review the following fix to address JPRT timeout issues when
>>>>>> using -rtests to run hotspot JTReg tests on slow devices. The same
>>>>>> logic
>>>>>> has been in place for jdk/test/Makefile for a while now, so I just
>>>>>> copied from there to hotspot/test/Makefile.
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066508
>>>>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>
>>
>>
>>
>



From daniel.daugherty at oracle.com  Fri Dec  5 21:27:34 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 05 Dec 2014 14:27:34 -0700
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <5480D73F.7070907@oracle.com>
References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com>
	<545CF033.4010503@oracle.com> <54619729.30704@oracle.com>
	<546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com>
	<5480D73F.7070907@oracle.com>
Message-ID: <54822346.5060407@oracle.com>

General

- Most of these comments are style related.

- The accidental deletion of 'UnsafeJlong_lock' needs to
   be fixed.

- This is a big piece of work for the first bug that you
   started on! You've done really good work here.

- The correct choice between these values:

   Monitor::_safepoint_check_never
   Monitor::_safepoint_check_sometimes
   Monitor::_safepoint_check_always

   is very hard to sanity check. As David H. likes to say
   for changes like this: The proof is in the testing!

   In this case, because of the myriad of options and code
   paths, we may not catch all the "oops" values right away.
   This early in the JDK9 release is the perfect time to
   push a change like this!

- jcheck is going to complain about some of your lines that
   have trailing white space:

   $ grep -n '  *$' `cat files.list`
   $ grep -n '\t' `cat files.list`

   Don't know if you have any tabs, but I included that one also.
   Not all platforms like '\t' for the grep parameter.

- jcheck may also complain about the blank lines at the end
   of the new tests


On 12/4/14 2:50 PM, Max Ockner wrote:
> Hello once again...
> I have a new (and suggestively titled) webrev: 
> http://cr.openjdk.java.net/~coleenp/8047290final/

src/share/vm/runtime/mutex.hpp
     lines 157-162: the entire comment block needs one more
         space of indent.

     line 163   enum SafepointCheckRequired {
     line 171:         };
         The right brace should line up under the 'e' in 'enum'.

     line 173:  NOT_PRODUCT(SafepointCheckRequired 
_safepoint_check_required;)
         I think this one needs one more space of indent.

     line 196:   Monitor(int rank, const char *name, bool 
allow_vm_block=false,
     line 197:           SafepointCheckRequired 
safepoint_check_required= _safepoint_check_always);
         A single space around the '=' would be good.

     line 283:    Mutex (int rank, const char *name, bool 
allow_vm_block=false,
         Deleting the space before the '(' would be good; I
         A single space around the '=' would be good.

src/share/vm/runtime/mutex.cpp
     line 1094:   //Make sure safepoint checking is used properly.
         Please add a space before 'Make'.

src/share/vm/runtime/mutexLocker.cpp
     line 170: #define def(var, type, pri, vm_block, 
safepoint_check_allowed ) {      \
     line 171: var = new type(Mutex::pri, #var, vm_block, 
safepoint_check_allowed); \
     line 172: assert(_num_mutex < MAX_NUM_MUTEX, "increase 
MAX_NUM_MUTEX");        \
     line 173: _mutex_array[_num_mutex] = var;

     Please reformat like so:

     line 170: #define def(var, type, pri, vm_block, 
safepoint_check_allowed) {        \
     line 171:   var = new type(Mutex::pri, #var, vm_block, 
safepoint_check_allowed);  \
     line 172:   assert(_num_mutex < MAX_NUM_MUTEX, "increase 
MAX_NUM_MUTEX");         \
     line 173:   _mutex_array[_num_mutex] = 
var;                                       \

     line 176: void mutex_init() {
         For all the def() macro calls, you need to decide whether to
         have spaces before the ');' or not to make them line up on the
         longest variant. I see these variations:

         ..., Monitor::_safepoint_check_never );
         ..., Monitor::_safepoint_check_sometimes);
         ..., Monitor::_safepoint_check_always);

         I would prefer no space before the ');' and do the line ups on
         the comments, but it is your call. Example:

         ..., Monitor::_safepoint_check_never);      // comment1
         ..., Monitor::_safepoint_check_sometimes);  // comment2
         ..., Monitor::_safepoint_check_always);     // comment3

     line 240:   // CMS_modUnionTable_lock                   leaf
     line 241:    // CMS_bitMap_lock                          leaf 1
     line 242:    // CMS_freeList_lock                        leaf 2
         Lines 241,242 should line up with the line 240.

     line 293: #ifndef SUPPORTS_NATIVE_CX8
     line 294:   def(UnsafeJlong_lock             , Mutex, special,     
false);
     line 295: #endif
         Looks like a merge error. This lock was recently added.

src/share/vm/runtime/thread.cpp
     No comments.

src/share/vm/runtime/vmThread.cpp
     line 217: please break the really line at the new parameter
               and align with the 'M' in '(Mutex:...'

src/os/aix/vm/osThread_aix.cpp
     No comments.

src/os/bsd/vm/osThread_bsd.cpp
     No comments.

src/os/linux/vm/osThread_linux.cpp
     No comments.

src/share/vm/classfile/classLoaderData.cpp
     No comments.

src/share/vm/memory/metaspace.cpp
     No comments.

src/share/vm/runtime/vm_operations.cpp
     No comments.

src/share/vm/memory/sharedHeap.cpp
     No comments.

src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
     No comments.

src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
     No comments.

src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
     No comments.

src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
     No comments.

src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
     No comments.

src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
     No comments.

src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
     No comments.

src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
     No comments.

src/share/vm/services/diagnosticFramework.cpp
     No comments.

src/share/vm/services/memoryManager.cpp
     No comments.

src/share/vm/utilities/decoder.cpp
     No comments.

src/share/vm/utilities/events.hpp
     No comments.

src/share/vm/utilities/workgroup.cpp
     No comments.

src/share/vm/prims/whitebox.cpp
     line 1044                    attemptedNoSafepointValue == JNI_TRUE );
         Please delete the space before ');'.

test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
     line 230:   //Safepoint Checking
         Please add a space before the 'S' in 'Safepoint'.

Comment test comments:
     New file should have a single copyright year.
     Should there be an @bug entry?
     Should there be an @build entry for the test library?

test/runtime/Safepoint/AssertSafepointCheckConsistency1.java
     See common test comments.
     Should this test check for "assert"?

test/runtime/Safepoint/AssertSafepointCheckConsistency2.java
     See common test comments.

     line 53:          OutputAnalyzer output = new 
OutputAnalyzer(pb.start());
         One space too many on this indent.

     Should this test check for "assert"?

test/runtime/Safepoint/AssertSafepointCheckConsistency3.java
     See common test comments.

     Should this test check for no "assert"?

test/runtime/Safepoint/AssertSafepointCheckConsistency4.java
     See common test comments.

     Should this test check for no "assert"?


> Ran aurora tests.

OK, but which Aurora tests? With Aurora you can run a single
test in one subsuite or you can run everything we have...

My recommendation would be to run the configs that are
specific to each team's nightly run. For example, the
"Runtime-SVC Nightly tests" is ours...

Dan



>
> Here is a list of "sometimes" locks:
>
> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
> "CompactibleFreeListSpace._lock" 
> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
> "freelist par lock" 
> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
> "SR_lock"                            share/vm/runtime/thread.cpp
> "CMS_markBitMap_lock" 
> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>
> The remaining "sometimes" locks can be found in 
> share/vm/runtime/mutexLocker.cpp:
>
> ParGCRareEvent_lock
> Safepoint_lock
> Threads_lock
> VMOperationQueue_lock
> VMOperationRequest_lock
> Terminator_lock
> Heap_lock
> Compile_lock
> PeriodicTask_lock
> JfrStacktrace_lock
>
>
> Thanks,
> Max Ockner
>
>
>
>
> On 11/25/2014 3:03 AM, David Holmes wrote:
>> Hi Max,
>>
>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>> Hello again,
>>>
>>> I have made changes based on all comments. There is now a pair of 
>>> assert
>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>
>> Is there an updated webrev?
>>
>>> caught another lock that I had to change to "sometimes", but the assert
>>> that caught this lock was not in wait. There are currently no locks 
>>> that
>>> use try to pass an incorrect safepoint check argument to wait().
>>> Instead, gcbasher did not catch this lock last time, when the only
>>> asserts were in lock and lock_without_safepoint. This lock is
>>> "CMS_markBitMap_lock" in
>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. 
>>>
>>> I'm guessing that it was not caught by the tests because this 
>>> section of
>>> code is not reached very often. My initial inspection failed to catch
>>> this lock because it is passed around between various structures and
>>> renamed 4 times. I have not yet found a good way to check for this
>>> situation, even with a debugger.
>>>
>>> Are there any tests which actually manage to hit every line of code?
>>
>> No. There is too much code that is dependent on low-level details of 
>> the GC used, the compilation strategy, plus the set of runtime flags 
>> used (and whether product or fastdebug). That's why we have lots of 
>> tests run in lots of different ways, to try to get coverage.
>>
>>> How should I handle this situation where I can't rely on the tests that
>>> I have run to tell me if I have missed something?
>>> At what point can I assume that everything is OK?
>>
>> Difficult to answer in general - there are a number of recommended 
>> test suites used by the runtime team, but your changes will also 
>> impact GC and compiler code and so may not get exercised by the 
>> runtime test suites (unless run with various compiler and GC 
>> options). Perhaps an ad-hoc test run similar to nightlies? Or you 
>> push after the weekly snapshot so as to maximise nightly testing, and 
>> if there are issues exposed then you have time to address them or 
>> revert the fix.
>>
>> Cheers,
>> David
>>
>>> Thanks,
>>> Max Ockner
>>>
>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>> Hi Max,
>>>>
>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>> Hello all,
>>>>> I have made these additonal changes:
>>>>> -Moved the assert() statements into the lock and 
>>>>> lock_without_safepoint
>>>>> methods.
>>>>> -Changed Monitor::SafepointAllowed to Monitor::SafepointCheckRequired
>>>>> -Changed the Monitor::SafepointCheckRequired values for several locks
>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>> MutexLocker, some were locked were locked without any MutexLocker* )
>>>>>
>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>
>>>> Generally this is all okay - a few style and other nits below.
>>>>
>>>> However you missed adding an assert in Monitor::wait to check if the
>>>> no_safepoint_check flag was being used correctly for the current 
>>>> monitor.
>>>>
>>>> Specific comments:
>>>>
>>>> src/share/vm/runtime/mutex.hpp
>>>>
>>>> This comment is no longer accurate with the moved check location:
>>>>
>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>> + // to ensure consistent checking for each lock.
>>>>
>>>> The same goes for other references to MutexLockerEx in the enum
>>>> description.
>>>>
>>>> Also copyright year needs updating.
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutex.cpp
>>>>
>>>>  898   //Ensure
>>>>  961   //Ensure
>>>>
>>>> Space needed after //
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>
>>>> +  var = new type(Mutex::pri, #var, 
>>>> vm_block,safepoint_check_allowed); \
>>>>
>>>> space needed after comma in k,s
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>
>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> Additional testing:
>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>> jtreg jfr tests
>>>>>
>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>
>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>> "CompactibleFreeListSpace._lock"
>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>
>>>>>
>>>>> "freelist par lock"
>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>
>>>>>
>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>
>>>>> The remaining "sometimes" locks can be found in
>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>
>>>>> ParGCRareEvent_lock
>>>>> Safepoint_lock
>>>>> Threads_lock
>>>>> VMOperationQueue_lock
>>>>> VMOperationRequest_lock
>>>>> Terminator_lock
>>>>> Heap_lock
>>>>> Compile_lock
>>>>> PeriodicTask_lock
>>>>> JfrStacktrace_lock
>>>>>
>>>>> I have not checked the validity of the "sometimes" locks, and I 
>>>>> believe
>>>>> that this should be a different project.
>>>>>
>>>>> Thanks for your help!
>>>>> Max Ockner
>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>> Hi Max,
>>>>>>
>>>>>> This is looking good.
>>>>>>
>>>>>> A few high-level initial comments:
>>>>>>
>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>
>>>>>> Why are the checks in MutexLocker when the state is maintained in 
>>>>>> the
>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>> check in the mutex/monitor methods.
>>>>>>
>>>>>> Checking consistent usage of the _no_safepoint_check_flag is 
>>>>>> good. But
>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>> safepoints should never be held when a thread blocks at a 
>>>>>> safepoint -
>>>>>> is there some way to easily check that? I was surprised how many 
>>>>>> locks
>>>>>> are actually not checking for safepoints.
>>>>>>
>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>> inconsistently and incorrectly?
>>>>>>
>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>> Threads_lock with a safepoint check and a safepoint has been 
>>>>>> requested
>>>>>> :) ).
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>
>>>>>>> Summary: MutexLockerEx can either acquire a lock with or without a
>>>>>>> safepoint check.
>>>>>>> In some cases, a particular lock must either safepoint check 
>>>>>>> always or
>>>>>>> never to avoid deadlocking.
>>>>>>> Some other locks have semantics which allow them to avoid deadlocks
>>>>>>> despite having a safepoint check only some of the time.
>>>>>>> All locks that are OK having inconsistent safepoint checks have 
>>>>>>> been
>>>>>>> marked. All locks that should never safepoint check and all 
>>>>>>> locks that
>>>>>>> should always safepoint check have also been marked.
>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>> check,
>>>>>>> the lock's safepointAllowed marker is checked to ensure consistent
>>>>>>> safepoint checking.
>>>>>>>
>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>
>>>>>>> Tested with:
>>>>>>>      jprt "-testset hotspot"
>>>>>>>      jtreg hotspot
>>>>>>>      vm.quick.testlist
>>>>>>>
>>>>>>> Whitebox tests:
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test
>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test
>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code
>>>>>>> should not assert. (Lock is properly acquired with no safepoint 
>>>>>>> check)
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code
>>>>>>> should not assert. (Lock is properly acquired with safepoint check)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Max
>>>>>>>
>>>>>
>>>
>
>
>


From igor.ignatyev at oracle.com  Fri Dec  5 21:28:30 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Sat, 06 Dec 2014 00:28:30 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <548211EF.3050402@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com>
Message-ID: <5482237E.6010201@oracle.com>

Hi Staffan,

Utils.ITERATION_COUNT will be extremely useful during porting our 
existing tests. so I'd like to have it in common testlibrary.

Thanks
Igor

On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
> During internal team review, Igor.Igntatyev asked to move it to Utils,
> perhaps he has future plans for this.
> Igor?
>
> Thanks,
> Dmitrij
>> Utils.ITERATION_COUNT does not look like something that is usable
>> outside these specific tests? Should it really be part of the test
>> library?
>>
>>> On 5 dec 2014, at 18:18, Dmitrij
>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>
>>> Adding hotspot-dev for wider audience.
>>>> Hi,
>>>>
>>>> Please review changes for
>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>> Test task: JMX- tests
>>>> and
>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>> in testlibrary for JDK-8059613
>>>>
>>>> It introduce a number of tests for segmented code cache, mostly
>>>> testing thresholds, usage,
>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>> There is also a small modification for testlibrary(8066440) used in
>>>> tests.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>
>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>
>>>> Additional note: this patch assumes
>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>> is fixed.
>>>>
>>>> Thanks,
>>>> Dmitrij
>

From daniel.daugherty at oracle.com  Fri Dec  5 21:48:05 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 05 Dec 2014 14:48:05 -0700
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <5480F3A2.9070600@oracle.com>
References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com>
Message-ID: <54822815.4000606@oracle.com>

 > http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/

test/Makefile
     No comments.

Thumbs up. Please fix the Copyright year before you push.

Dan


On 12/4/14 4:52 PM, David Holmes wrote:
> Hi Chris,
>
> Sorry I mis-directed you to send this one to build-dev, as it is a 
> hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd.
>
> Fix looks good to me.
>
> Thanks,
> David
>
> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>> Please review the following fix to address JPRT timeout issues when
>> using -rtests to run hotspot JTReg tests on slow devices. The same logic
>> has been in place for jdk/test/Makefile for a while now, so I just
>> copied from there to hotspot/test/Makefile.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8066508
>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>
>> thanks,
>>
>> Chris
>>
>
>


From chris.plummer at oracle.com  Fri Dec  5 22:17:19 2014
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 05 Dec 2014 14:17:19 -0800
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <54822815.4000606@oracle.com>
References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com>
	<54822815.4000606@oracle.com>
Message-ID: <54822EEF.5080504@oracle.com>

Is the copyright rule/policy to leave the oldest date and update the 
most recent date to the current year?

Chris

On 12/5/14 1:48 PM, Daniel D. Daugherty wrote:
> > http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>
> test/Makefile
>     No comments.
>
> Thumbs up. Please fix the Copyright year before you push.
>
> Dan
>
>
> On 12/4/14 4:52 PM, David Holmes wrote:
>> Hi Chris,
>>
>> Sorry I mis-directed you to send this one to build-dev, as it is a 
>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now cc'd.
>>
>> Fix looks good to me.
>>
>> Thanks,
>> David
>>
>> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>>> Please review the following fix to address JPRT timeout issues when
>>> using -rtests to run hotspot JTReg tests on slow devices. The same 
>>> logic
>>> has been in place for jdk/test/Makefile for a while now, so I just
>>> copied from there to hotspot/test/Makefile.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8066508
>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>
>>
>


From jon.masamitsu at oracle.com  Fri Dec  5 22:30:22 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 05 Dec 2014 14:30:22 -0800
Subject: RFR: 8062672: JVM crashes during GC on various asserts which
	checks that HeapWord ptr is an oop
In-Reply-To: <5481825E.4080602@oracle.com>
References: <5481825E.4080602@oracle.com>
Message-ID: <548231FE.5090301@oracle.com>

Stefan,

Changes look good.

Would you like to explicitly check the return from
fgets() against NULL?  Your call.

What do you think of an assert after the call to fgets() to
check the length of the returned string.

assert(strnlen(line, 1023) < 1023, "buffer line[1024] is too small.");

Too paranoid?

Reviewed.

Jon

On 12/5/2014 2:01 AM, Stefan Johansson wrote:
> Hi,
>
> Please review this fix for the linux-sparc issue described in:
> https://bugs.openjdk.java.net/browse/JDK-8062672
>
> Webrev:
> http://cr.openjdk.java.net/~sjohanss/8062672/hotspot.00/
>
> Summary:
> This fix is based on 7u-dev because the most linux-sparc testing is 
> done for that release and also because it's unclear if we have time to 
> move the fix the normal way through 9 and 8u before going into 7u. But 
> the main reason is that it would be good to get testing of the fix in 
> 7u before porting it to 8u and 9.
>
> The fix it self is fairly simple, after JDK-8029190 was backported the 
> condition for disabling UseMemSetInBOT changed from is_niagara() to 
> has_blk_init(). This worked well for solaris-sparc but on linux-sparc 
> we previously only set the niagara feature bits, so this change adds 
> support for detecting blk_init support on linux-sparc.
>
> Testing:
> Crashes/asserts was reproducible without the fix and after the fix 
> none have been observed. Also verified that UseMemSetInBOT now is set 
> to false as it should be.
>
> Thanks,
> Stefan


From daniel.daugherty at oracle.com  Fri Dec  5 22:52:31 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 05 Dec 2014 15:52:31 -0700
Subject: [9] RFR (XS) 8066508: JTReg tests timeout on slow devices when
	run using JPRT
In-Reply-To: <54822EEF.5080504@oracle.com>
References: <5480C601.9040701@oracle.com> <5480F3A2.9070600@oracle.com>
	<54822815.4000606@oracle.com> <54822EEF.5080504@oracle.com>
Message-ID: <5482372F.5070201@oracle.com>

Yes. So '2013' -> '2014'.

Dan


On 12/5/14 3:17 PM, Chris Plummer wrote:
> Is the copyright rule/policy to leave the oldest date and update the 
> most recent date to the current year?
>
> Chris
>
> On 12/5/14 1:48 PM, Daniel D. Daugherty wrote:
>> > http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>
>> test/Makefile
>>     No comments.
>>
>> Thumbs up. Please fix the Copyright year before you push.
>>
>> Dan
>>
>>
>> On 12/4/14 4:52 PM, David Holmes wrote:
>>> Hi Chris,
>>>
>>> Sorry I mis-directed you to send this one to build-dev, as it is a 
>>> hotspot test/Makefile fix it should be reviewed by hotspot-dev now 
>>> cc'd.
>>>
>>> Fix looks good to me.
>>>
>>> Thanks,
>>> David
>>>
>>> On 5/12/2014 6:37 AM, Chris Plummer wrote:
>>>> Please review the following fix to address JPRT timeout issues when
>>>> using -rtests to run hotspot JTReg tests on slow devices. The same 
>>>> logic
>>>> has been in place for jdk/test/Makefile for a while now, so I just
>>>> copied from there to hotspot/test/Makefile.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8066508
>>>> http://cr.openjdk.java.net/~cjplummer/8066508/webrev.00/
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Fri Dec  5 23:02:49 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 05 Dec 2014 18:02:49 -0500
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <548210C8.3080405@oracle.com>
References: <543EB71A.8000403@oracle.com>	<543F174F.7040204@oracle.com>	<545CF033.4010503@oracle.com>	<54619729.30704@oracle.com>	<546E638E.2020208@oracle.com>	<547437EF.5010806@oracle.com>
	<5480D73F.7070907@oracle.com> <548210C8.3080405@oracle.com>
Message-ID: <54823999.3000809@oracle.com>


Dan prompted me to look at all the bits.

I think in the merge you accidentally reverted these lines.

    // CMS_modUnionTable_lock                   leaf
-  // CMS_bitMap_lock                          leaf + 1
-  // CMS_freeList_lock                        leaf + 2
+   // CMS_bitMap_lock                          leaf 1
+   // CMS_freeList_lock                        leaf 2

Besides restoring UnsafeJlong_lock (which is never checks for safepoints).

-#ifndef SUPPORTS_NATIVE_CX8
-  def(UnsafeJlong_lock             , Mutex,   special,     false);
-#endif

The rest looks fine.  I checked.   We think this compiled ok for you in 
JPRT because our platforms define SUPPORTS_NATIVE_CX8.

Also, I think we should file an single RFE for analyzing the locks for 
the GC code:

"WorkGroup monitor" share/vm/utilities/workgroup.cpp
"SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
"CompactibleFreeListSpace._lock" 
share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
"freelist par lock" 
share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
"CMS_markBitMap_lock" 
share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
ParGCRareEvent_lock


One RFE for analyzing the locks for the compiler:

Compile_lock

And one for the JFR code:

JfrStacktrace_lock

And one for the Runtime code (which may be intentionally "sometimes" 
locks because they control safepoints but someone should verify this):

Safepoint_lock
Threads_lock
VMOperationQueue_lock
VMOperationRequest_lock
Terminator_lock
Heap_lock
PeriodicTask_lock

Thanks!
Coleen


On 12/5/14, 3:08 PM, Coleen Phillimore wrote:
>
> Max,
>
> I think these changes look great!  There were some comments about 
> making this more of a static check with types or detecting deadlocks 
> within the safepointing code, but the change here is a good first step 
> and does so with minimal disruption to the code and minimal 
> complexity.  So I consider this low-hanging fruit in order to make the 
> code safer.
>
> Thanks!
> Coleen
>
>
> On 12/4/14, 4:50 PM, Max Ockner wrote:
>> Hello once again...
>> I have a new (and suggestively titled) webrev: 
>> http://cr.openjdk.java.net/~coleenp/8047290final/
>>
>> Ran aurora tests.
>>
>> Here is a list of "sometimes" locks:
>>
>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>> "CompactibleFreeListSpace._lock" 
>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>> "freelist par lock" 
>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>> "SR_lock"                            share/vm/runtime/thread.cpp
>> "CMS_markBitMap_lock" 
>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>>
>> The remaining "sometimes" locks can be found in 
>> share/vm/runtime/mutexLocker.cpp:
>>
>> ParGCRareEvent_lock
>> Safepoint_lock
>> Threads_lock
>> VMOperationQueue_lock
>> VMOperationRequest_lock
>> Terminator_lock
>> Heap_lock
>> Compile_lock
>> PeriodicTask_lock
>> JfrStacktrace_lock
>>
>>
>> Thanks,
>> Max Ockner
>>
>>
>>
>>
>> On 11/25/2014 3:03 AM, David Holmes wrote:
>>> Hi Max,
>>>
>>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>>> Hello again,
>>>>
>>>> I have made changes based on all comments. There is now a pair of 
>>>> assert
>>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>>
>>> Is there an updated webrev?
>>>
>>>> caught another lock that I had to change to "sometimes", but the 
>>>> assert
>>>> that caught this lock was not in wait. There are currently no locks 
>>>> that
>>>> use try to pass an incorrect safepoint check argument to wait().
>>>> Instead, gcbasher did not catch this lock last time, when the only
>>>> asserts were in lock and lock_without_safepoint. This lock is
>>>> "CMS_markBitMap_lock" in
>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. 
>>>>
>>>> I'm guessing that it was not caught by the tests because this 
>>>> section of
>>>> code is not reached very often. My initial inspection failed to catch
>>>> this lock because it is passed around between various structures and
>>>> renamed 4 times. I have not yet found a good way to check for this
>>>> situation, even with a debugger.
>>>>
>>>> Are there any tests which actually manage to hit every line of code?
>>>
>>> No. There is too much code that is dependent on low-level details of 
>>> the GC used, the compilation strategy, plus the set of runtime flags 
>>> used (and whether product or fastdebug). That's why we have lots of 
>>> tests run in lots of different ways, to try to get coverage.
>>>
>>>> How should I handle this situation where I can't rely on the tests 
>>>> that
>>>> I have run to tell me if I have missed something?
>>>> At what point can I assume that everything is OK?
>>>
>>> Difficult to answer in general - there are a number of recommended 
>>> test suites used by the runtime team, but your changes will also 
>>> impact GC and compiler code and so may not get exercised by the 
>>> runtime test suites (unless run with various compiler and GC 
>>> options). Perhaps an ad-hoc test run similar to nightlies? Or you 
>>> push after the weekly snapshot so as to maximise nightly testing, 
>>> and if there are issues exposed then you have time to address them 
>>> or revert the fix.
>>>
>>> Cheers,
>>> David
>>>
>>>> Thanks,
>>>> Max Ockner
>>>>
>>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>>> Hi Max,
>>>>>
>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>>> Hello all,
>>>>>> I have made these additonal changes:
>>>>>> -Moved the assert() statements into the lock and 
>>>>>> lock_without_safepoint
>>>>>> methods.
>>>>>> -Changed Monitor::SafepointAllowed to 
>>>>>> Monitor::SafepointCheckRequired
>>>>>> -Changed the Monitor::SafepointCheckRequired values for several 
>>>>>> locks
>>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>>> MutexLocker, some were locked were locked without any MutexLocker* )
>>>>>>
>>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>>
>>>>> Generally this is all okay - a few style and other nits below.
>>>>>
>>>>> However you missed adding an assert in Monitor::wait to check if the
>>>>> no_safepoint_check flag was being used correctly for the current 
>>>>> monitor.
>>>>>
>>>>> Specific comments:
>>>>>
>>>>> src/share/vm/runtime/mutex.hpp
>>>>>
>>>>> This comment is no longer accurate with the moved check location:
>>>>>
>>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>>> + // to ensure consistent checking for each lock.
>>>>>
>>>>> The same goes for other references to MutexLockerEx in the enum
>>>>> description.
>>>>>
>>>>> Also copyright year needs updating.
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/mutex.cpp
>>>>>
>>>>>  898   //Ensure
>>>>>  961   //Ensure
>>>>>
>>>>> Space needed after //
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>
>>>>> +  var = new type(Mutex::pri, #var, 
>>>>> vm_block,safepoint_check_allowed); \
>>>>>
>>>>> space needed after comma in k,s
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>>
>>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Additional testing:
>>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>>> jtreg jfr tests
>>>>>>
>>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>>
>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>> "SLTMonitor" 
>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>> "CompactibleFreeListSpace._lock"
>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>
>>>>>>
>>>>>> "freelist par lock"
>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>
>>>>>>
>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>
>>>>>> The remaining "sometimes" locks can be found in
>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>
>>>>>> ParGCRareEvent_lock
>>>>>> Safepoint_lock
>>>>>> Threads_lock
>>>>>> VMOperationQueue_lock
>>>>>> VMOperationRequest_lock
>>>>>> Terminator_lock
>>>>>> Heap_lock
>>>>>> Compile_lock
>>>>>> PeriodicTask_lock
>>>>>> JfrStacktrace_lock
>>>>>>
>>>>>> I have not checked the validity of the "sometimes" locks, and I 
>>>>>> believe
>>>>>> that this should be a different project.
>>>>>>
>>>>>> Thanks for your help!
>>>>>> Max Ockner
>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>>> Hi Max,
>>>>>>>
>>>>>>> This is looking good.
>>>>>>>
>>>>>>> A few high-level initial comments:
>>>>>>>
>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>>
>>>>>>> Why are the checks in MutexLocker when the state is maintained 
>>>>>>> in the
>>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>>> check in the mutex/monitor methods.
>>>>>>>
>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is 
>>>>>>> good. But
>>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>>> safepoints should never be held when a thread blocks at a 
>>>>>>> safepoint -
>>>>>>> is there some way to easily check that? I was surprised how many 
>>>>>>> locks
>>>>>>> are actually not checking for safepoints.
>>>>>>>
>>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>>> inconsistently and incorrectly?
>>>>>>>
>>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>>> Threads_lock with a safepoint check and a safepoint has been 
>>>>>>> requested
>>>>>>> :) ).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>>
>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or without a
>>>>>>>> safepoint check.
>>>>>>>> In some cases, a particular lock must either safepoint check 
>>>>>>>> always or
>>>>>>>> never to avoid deadlocking.
>>>>>>>> Some other locks have semantics which allow them to avoid 
>>>>>>>> deadlocks
>>>>>>>> despite having a safepoint check only some of the time.
>>>>>>>> All locks that are OK having inconsistent safepoint checks have 
>>>>>>>> been
>>>>>>>> marked. All locks that should never safepoint check and all 
>>>>>>>> locks that
>>>>>>>> should always safepoint check have also been marked.
>>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>>> check,
>>>>>>>> the lock's safepointAllowed marker is checked to ensure consistent
>>>>>>>> safepoint checking.
>>>>>>>>
>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>>
>>>>>>>> Tested with:
>>>>>>>>      jprt "-testset hotspot"
>>>>>>>>      jtreg hotspot
>>>>>>>>      vm.quick.testlist
>>>>>>>>
>>>>>>>> Whitebox tests:
>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test
>>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test
>>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code
>>>>>>>> should not assert. (Lock is properly acquired with no safepoint 
>>>>>>>> check)
>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code
>>>>>>>> should not assert. (Lock is properly acquired with safepoint 
>>>>>>>> check)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Max
>>>>>>>>
>>>>>>
>>>>
>>
>


From david.holmes at oracle.com  Mon Dec  8 02:09:51 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Dec 2014 12:09:51 +1000
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <5481A724.1070107@oracle.com>
References: <5481A724.1070107@oracle.com>
Message-ID: <5485086F.3090007@oracle.com>

On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote:
> Hi all,
>
> please review this new small patch
>
> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
> webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/
>
> Problem:
> Need WhiteBox::allocateCodeBlob(long, int), currently only
> WhiteBox::allocateCodeBlob(int, int) exist.
>
> I change previous fix to this new patch because this conversation [*]
>
> Solution:
>    public long allocateCodeBlob(long size, int type) {
>        return allocateCodeBlob((int) size, type);
>    }

I still think this is a bad idea. The callsite needs to know, and show, 
that the size it is passing will be truncated. And I still don't see a 
connection between MX bean memory sizes and allocateCodeBlob.

David


> Test: jprt
>
> [*]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html
>
>
> Thanks,
> Tatiana

From david.holmes at oracle.com  Mon Dec  8 02:24:42 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Dec 2014 12:24:42 +1000
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <54823999.3000809@oracle.com>
References: <543EB71A.8000403@oracle.com>	<543F174F.7040204@oracle.com>	<545CF033.4010503@oracle.com>	<54619729.30704@oracle.com>	<546E638E.2020208@oracle.com>	<547437EF.5010806@oracle.com>	<5480D73F.7070907@oracle.com>
	<548210C8.3080405@oracle.com> <54823999.3000809@oracle.com>
Message-ID: <54850BEA.7060404@oracle.com>

On 6/12/2014 9:02 AM, Coleen Phillimore wrote:
>
> Dan prompted me to look at all the bits.
>
> I think in the merge you accidentally reverted these lines.
>
>     // CMS_modUnionTable_lock                   leaf
> -  // CMS_bitMap_lock                          leaf + 1
> -  // CMS_freeList_lock                        leaf + 2
> +   // CMS_bitMap_lock                          leaf 1
> +   // CMS_freeList_lock                        leaf 2
>
> Besides restoring UnsafeJlong_lock (which is never checks for safepoints).
>
> -#ifndef SUPPORTS_NATIVE_CX8
> -  def(UnsafeJlong_lock             , Mutex,   special,     false);
> -#endif

Thanks for adding that info Coleen - it was on my todo list to mention 
this new lock to Max.

> The rest looks fine.  I checked.   We think this compiled ok for you in
> JPRT because our platforms define SUPPORTS_NATIVE_CX8.

Not all them - a full JPRT test job would have failed.

Cheers,
David

> Also, I think we should file an single RFE for analyzing the locks for
> the GC code:
>
> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
> "CompactibleFreeListSpace._lock"
> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
> "freelist par lock"
> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
> "CMS_markBitMap_lock"
> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>
> ParGCRareEvent_lock
>
>
> One RFE for analyzing the locks for the compiler:
>
> Compile_lock
>
> And one for the JFR code:
>
> JfrStacktrace_lock
>
> And one for the Runtime code (which may be intentionally "sometimes"
> locks because they control safepoints but someone should verify this):
>
> Safepoint_lock
> Threads_lock
> VMOperationQueue_lock
> VMOperationRequest_lock
> Terminator_lock
> Heap_lock
> PeriodicTask_lock
>
> Thanks!
> Coleen
>
>
> On 12/5/14, 3:08 PM, Coleen Phillimore wrote:
>>
>> Max,
>>
>> I think these changes look great!  There were some comments about
>> making this more of a static check with types or detecting deadlocks
>> within the safepointing code, but the change here is a good first step
>> and does so with minimal disruption to the code and minimal
>> complexity.  So I consider this low-hanging fruit in order to make the
>> code safer.
>>
>> Thanks!
>> Coleen
>>
>>
>> On 12/4/14, 4:50 PM, Max Ockner wrote:
>>> Hello once again...
>>> I have a new (and suggestively titled) webrev:
>>> http://cr.openjdk.java.net/~coleenp/8047290final/
>>>
>>> Ran aurora tests.
>>>
>>> Here is a list of "sometimes" locks:
>>>
>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>> "CompactibleFreeListSpace._lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>
>>> "freelist par lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>
>>> "SR_lock"                            share/vm/runtime/thread.cpp
>>> "CMS_markBitMap_lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>>>
>>>
>>> The remaining "sometimes" locks can be found in
>>> share/vm/runtime/mutexLocker.cpp:
>>>
>>> ParGCRareEvent_lock
>>> Safepoint_lock
>>> Threads_lock
>>> VMOperationQueue_lock
>>> VMOperationRequest_lock
>>> Terminator_lock
>>> Heap_lock
>>> Compile_lock
>>> PeriodicTask_lock
>>> JfrStacktrace_lock
>>>
>>>
>>> Thanks,
>>> Max Ockner
>>>
>>>
>>>
>>>
>>> On 11/25/2014 3:03 AM, David Holmes wrote:
>>>> Hi Max,
>>>>
>>>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>>>> Hello again,
>>>>>
>>>>> I have made changes based on all comments. There is now a pair of
>>>>> assert
>>>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>>>
>>>> Is there an updated webrev?
>>>>
>>>>> caught another lock that I had to change to "sometimes", but the
>>>>> assert
>>>>> that caught this lock was not in wait. There are currently no locks
>>>>> that
>>>>> use try to pass an incorrect safepoint check argument to wait().
>>>>> Instead, gcbasher did not catch this lock last time, when the only
>>>>> asserts were in lock and lock_without_safepoint. This lock is
>>>>> "CMS_markBitMap_lock" in
>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.
>>>>>
>>>>> I'm guessing that it was not caught by the tests because this
>>>>> section of
>>>>> code is not reached very often. My initial inspection failed to catch
>>>>> this lock because it is passed around between various structures and
>>>>> renamed 4 times. I have not yet found a good way to check for this
>>>>> situation, even with a debugger.
>>>>>
>>>>> Are there any tests which actually manage to hit every line of code?
>>>>
>>>> No. There is too much code that is dependent on low-level details of
>>>> the GC used, the compilation strategy, plus the set of runtime flags
>>>> used (and whether product or fastdebug). That's why we have lots of
>>>> tests run in lots of different ways, to try to get coverage.
>>>>
>>>>> How should I handle this situation where I can't rely on the tests
>>>>> that
>>>>> I have run to tell me if I have missed something?
>>>>> At what point can I assume that everything is OK?
>>>>
>>>> Difficult to answer in general - there are a number of recommended
>>>> test suites used by the runtime team, but your changes will also
>>>> impact GC and compiler code and so may not get exercised by the
>>>> runtime test suites (unless run with various compiler and GC
>>>> options). Perhaps an ad-hoc test run similar to nightlies? Or you
>>>> push after the weekly snapshot so as to maximise nightly testing,
>>>> and if there are issues exposed then you have time to address them
>>>> or revert the fix.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Max Ockner
>>>>>
>>>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>>>> Hi Max,
>>>>>>
>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>>>> Hello all,
>>>>>>> I have made these additonal changes:
>>>>>>> -Moved the assert() statements into the lock and
>>>>>>> lock_without_safepoint
>>>>>>> methods.
>>>>>>> -Changed Monitor::SafepointAllowed to
>>>>>>> Monitor::SafepointCheckRequired
>>>>>>> -Changed the Monitor::SafepointCheckRequired values for several
>>>>>>> locks
>>>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>>>> MutexLocker, some were locked were locked without any MutexLocker* )
>>>>>>>
>>>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>>>
>>>>>> Generally this is all okay - a few style and other nits below.
>>>>>>
>>>>>> However you missed adding an assert in Monitor::wait to check if the
>>>>>> no_safepoint_check flag was being used correctly for the current
>>>>>> monitor.
>>>>>>
>>>>>> Specific comments:
>>>>>>
>>>>>> src/share/vm/runtime/mutex.hpp
>>>>>>
>>>>>> This comment is no longer accurate with the moved check location:
>>>>>>
>>>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>>>> + // to ensure consistent checking for each lock.
>>>>>>
>>>>>> The same goes for other references to MutexLockerEx in the enum
>>>>>> description.
>>>>>>
>>>>>> Also copyright year needs updating.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutex.cpp
>>>>>>
>>>>>>  898   //Ensure
>>>>>>  961   //Ensure
>>>>>>
>>>>>> Space needed after //
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>>
>>>>>> +  var = new type(Mutex::pri, #var,
>>>>>> vm_block,safepoint_check_allowed); \
>>>>>>
>>>>>> space needed after comma in k,s
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>>>
>>>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Additional testing:
>>>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>>>> jtreg jfr tests
>>>>>>>
>>>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>>>
>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>>> "SLTMonitor"
>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>>> "CompactibleFreeListSpace._lock"
>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>>
>>>>>>>
>>>>>>> "freelist par lock"
>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>>
>>>>>>>
>>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>>
>>>>>>> The remaining "sometimes" locks can be found in
>>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>>
>>>>>>> ParGCRareEvent_lock
>>>>>>> Safepoint_lock
>>>>>>> Threads_lock
>>>>>>> VMOperationQueue_lock
>>>>>>> VMOperationRequest_lock
>>>>>>> Terminator_lock
>>>>>>> Heap_lock
>>>>>>> Compile_lock
>>>>>>> PeriodicTask_lock
>>>>>>> JfrStacktrace_lock
>>>>>>>
>>>>>>> I have not checked the validity of the "sometimes" locks, and I
>>>>>>> believe
>>>>>>> that this should be a different project.
>>>>>>>
>>>>>>> Thanks for your help!
>>>>>>> Max Ockner
>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>>>> Hi Max,
>>>>>>>>
>>>>>>>> This is looking good.
>>>>>>>>
>>>>>>>> A few high-level initial comments:
>>>>>>>>
>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>>>
>>>>>>>> Why are the checks in MutexLocker when the state is maintained
>>>>>>>> in the
>>>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>>>> check in the mutex/monitor methods.
>>>>>>>>
>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is
>>>>>>>> good. But
>>>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>>>> safepoints should never be held when a thread blocks at a
>>>>>>>> safepoint -
>>>>>>>> is there some way to easily check that? I was surprised how many
>>>>>>>> locks
>>>>>>>> are actually not checking for safepoints.
>>>>>>>>
>>>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>>>> inconsistently and incorrectly?
>>>>>>>>
>>>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>>>> Threads_lock with a safepoint check and a safepoint has been
>>>>>>>> requested
>>>>>>>> :) ).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>>>
>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or without a
>>>>>>>>> safepoint check.
>>>>>>>>> In some cases, a particular lock must either safepoint check
>>>>>>>>> always or
>>>>>>>>> never to avoid deadlocking.
>>>>>>>>> Some other locks have semantics which allow them to avoid
>>>>>>>>> deadlocks
>>>>>>>>> despite having a safepoint check only some of the time.
>>>>>>>>> All locks that are OK having inconsistent safepoint checks have
>>>>>>>>> been
>>>>>>>>> marked. All locks that should never safepoint check and all
>>>>>>>>> locks that
>>>>>>>>> should always safepoint check have also been marked.
>>>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>>>> check,
>>>>>>>>> the lock's safepointAllowed marker is checked to ensure consistent
>>>>>>>>> safepoint checking.
>>>>>>>>>
>>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>>>
>>>>>>>>> Tested with:
>>>>>>>>>      jprt "-testset hotspot"
>>>>>>>>>      jtreg hotspot
>>>>>>>>>      vm.quick.testlist
>>>>>>>>>
>>>>>>>>> Whitebox tests:
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test
>>>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test
>>>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code
>>>>>>>>> should not assert. (Lock is properly acquired with no safepoint
>>>>>>>>> check)
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code
>>>>>>>>> should not assert. (Lock is properly acquired with safepoint
>>>>>>>>> check)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

From david.holmes at oracle.com  Mon Dec  8 06:25:57 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Dec 2014 16:25:57 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <547DCCFB.3050209@gmail.com>
References: <542C8274.3010809@gmail.com>	<54338B70.9080709@oracle.com>	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>	<543B1FD6.3000200@oracle.com>	<543CF553.80601@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>
	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
	<547D891D.7010809@oracle.com> <547DCCFB.3050209@gmail.com>
Message-ID: <54854475.20800@oracle.com>

Hi Yasumasa,

I'm okay with these changes. Just a minor style nit (no need for updated 
webrev) can you remove the blank lines in os_linux.cpp:

6011       }
6012
6013     }
6014
6015   }

6057       }
6058
6059     }
6060
6061   }

If anyone has any objections please raise them asap.

Thanks,
David

On 3/12/2014 12:30 AM, Yasumasa Suenaga wrote:
> Hi David, Thomas,
>
> I've uploaded new webrev:
> http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.04/
>
>>>     I want to rewrite a patch as below:
>>>
>>>       - Use async signal safety functions.
>>>         fopen -> open, fgets -> read, etc.
>>
>> This is commendable if it is practical, but error reporting already
>> does many, many things that are not async-signal safe, so there is no
>> need to go to extreme measures here.
>
> I've used async-signal safe functions as possible.
>
>
>>>       - Use O_BUFLEN for buffer size.
>>>         O_BUFLEN is defined to 2000 in ostream.hpp .
>>>         This macro is used in various points.
>>> VMError::coredump_message is
>>>         also defined with this value.
>>>
>>>
>>> I think PATH_MAX is fine. I think O_BUFLEN was originally used as a max.
>>> length of temporary buffers to assemble an output line. And then it
>>> spread a bit. But your intend is to hold a path and using PATH_MAX
>>> clearly documents this.
>
> I've used PATH_MAX again.
>
>
>>> And, to really nitpick, right now you do not handle ERANGE with
>>> get_current_path() (if the provided buffer is too small), which is
>>> probably fine because it is improbable that a path is larger than
>>> PATH_MAX. But if you change the size of the buffer to something which
>>> may be smaller than PATH_MAX (O_BUFLEN), get_current_directory() may
>>> fail.
>
> If get_current_path() call is failed in get_core_path(), get_core_path()
> returns immediately with 0.
> Caller (check_or_create_dump()) handles this result as illegal state.
>
> get_current_path() calls getcwd() only and redirects result to caller.
> So result of this function is NULL, we can judge getcwd() was finished with
> error.
> I think it is enough.
>
>
>>> I like your patch, I think it could be a nice time safer when
>>> core_pattern is something unusual. But I also see Staffans point of
>>> too-much-complexity. So I will keep out of this discussion until the
>>> real Reviewers decided what to do :)
>>
>> I have a hard time evaluating the merits of the patch as I don't work
>> in an environment where this extra info is needed. But I take it on
>> good faith that it is useful for the context Yasumasa describes.
>
> I want to suggest to Java user where coredump is.
> Modern Linux distribution(s) contains ABRT.
> OS can dump corefile automatically despite a lack of setting coredump
> resource by user.
>
> I'm support engineer of Java. My customer says "coredump does not found.",
> but coredump is saved by ABRT.
> Thus I want them to know "coredump is available" through stderr and
> hs_err immediately.
> I belive it is first step of troubleshoot.
>
>
> Thanks,
>
> Yasumasa
>
>
> (2014/12/02 18:40), David Holmes wrote:
>> On 1/12/2014 10:57 PM, Thomas St?fe wrote:
>>> Hi Yasumasa,
>>>
>>> On Mon, Dec 1, 2014 at 10:45 AM, Yasumasa Suenaga <yasuenag at gmail.com
>>> <mailto:yasuenag at gmail.com>> wrote:
>>>
>>>     Hi Thomas, David,
>>>
>>>     Sorry, I didn't think about async signal safety.
>>>
>>>         That would work, VmError::report_and_die() is singlethreaded. At
>>>         least the part which dumps out the core file name.
>>>
>>>
>>>     I think that signal handler (in this case) may run concurrency with
>>>     other thread.
>>>     If another thread calls malloc(3) in JNI, C Heap corruption may
>>> occur.
>>>
>>>
>>> No, malloc(3) should be thread safe on our platforms. But this was not
>>> the point. If I understood David right, he suggested using a static
>>> buffer inside get_core_path() for assembling the core path, which would
>>> make get_core_path() thread-unsafe (multiple threads calling it would
>>> get garbled results). But as get_core_path() is only called from within
>>> VmError::report_and_die() and that section is only ever executed by one
>>> thread, Davids suggestion would still work.
>>
>> Yes that is what I was suggesting.
>>
>>>     I want to rewrite a patch as below:
>>>
>>>       - Use async signal safety functions.
>>>         fopen -> open, fgets -> read, etc.
>>
>> This is commendable if it is practical, but error reporting already
>> does many, many things that are not async-signal safe, so there is no
>> need to go to extreme measures here.
>>
>>>       - Use O_BUFLEN for buffer size.
>>>         O_BUFLEN is defined to 2000 in ostream.hpp .
>>>         This macro is used in various points.
>>> VMError::coredump_message is
>>>         also defined with this value.
>>>
>>>
>>> I think PATH_MAX is fine. I think O_BUFLEN was originally used as a max.
>>> length of temporary buffers to assemble an output line. And then it
>>> spread a bit. But your intend is to hold a path and using PATH_MAX
>>> clearly documents this.
>>> And, to really nitpick, right now you do not handle ERANGE with
>>> get_current_path() (if the provided buffer is too small), which is
>>> probably fine because it is improbable that a path is larger than
>>> PATH_MAX. But if you change the size of the buffer to something which
>>> may be smaller than PATH_MAX (O_BUFLEN), get_current_directory() may
>>> fail.
>>>
>>> I like your patch, I think it could be a nice time safer when
>>> core_pattern is something unusual. But I also see Staffans point of
>>> too-much-complexity. So I will keep out of this discussion until the
>>> real Reviewers decided what to do :)
>>
>> I have a hard time evaluating the merits of the patch as I don't work
>> in an environment where this extra info is needed. But I take it on
>> good faith that it is useful for the context Yasumasa describes.
>>
>> David
>>
>>> Kind Regards, Thomas
>>>

From igor.ignatyev at oracle.com  Mon Dec  8 06:27:35 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 08 Dec 2014 09:27:35 +0300
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <5485086F.3090007@oracle.com>
References: <5481A724.1070107@oracle.com> <5485086F.3090007@oracle.com>
Message-ID: <548544D7.3030509@oracle.com>

David,

initially, we wanted to change WB::allocateCodeBlob to take jlong w/o 
truncating. for that we make CodeCache::allocate to take size_t instead 
of int, however it leads to too many changes in the product. And we were 
sure that all these changes are safe, so it was decided to make changes 
as smaller as possible.

what do you think about the version w/ check? smth like:
> public long allocateCodeBlob(long size, int type) {
>  int i = (int) size;
>  if ((long)i != size) { throw new IAE(); }
>  return allocateCodeBlob(i, type);
> }

8065134 was filled by Dmitrij Pochepko, and it's needed for his tests 
JMX tests for SegmentedCodeCache[1]. so I think he can enlighten us 
about connection.

Dima,
could you please explain connection between beans and allocateCodeBlob?

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016336.html

Thanks,
Igor

On 12/08/2014 05:09 AM, David Holmes wrote:
> On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote:
>> Hi all,
>>
>> please review this new small patch
>>
>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
>> webrev:
>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/
>>
>> Problem:
>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>> WhiteBox::allocateCodeBlob(int, int) exist.
>>
>> I change previous fix to this new patch because this conversation [*]
>>
>> Solution:
>>    public long allocateCodeBlob(long size, int type) {
>>        return allocateCodeBlob((int) size, type);
>>    }
>
> I still think this is a bad idea. The callsite needs to know, and show,
> that the size it is passing will be truncated. And I still don't see a
> connection between MX bean memory sizes and allocateCodeBlob.
>
> David
>
>
>> Test: jprt
>>
>> [*]
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html
>>
>>
>>
>> Thanks,
>> Tatiana

From david.holmes at oracle.com  Mon Dec  8 06:39:48 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Dec 2014 16:39:48 +1000
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <5480D73F.7070907@oracle.com>
References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com>
	<545CF033.4010503@oracle.com> <54619729.30704@oracle.com>
	<546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com>
	<5480D73F.7070907@oracle.com>
Message-ID: <548547B4.7000205@oracle.com>

Hi Max,

Just a nit with the tests - it seems to me we should be able to write a 
single Java class that can process all four combinations rather than 
duplicating the bulk of the code.

Thanks,
David

On 5/12/2014 7:50 AM, Max Ockner wrote:
> Hello once again...
> I have a new (and suggestively titled) webrev:
> http://cr.openjdk.java.net/~coleenp/8047290final/
>
> Ran aurora tests.
>
> Here is a list of "sometimes" locks:
>
> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
> "CompactibleFreeListSpace._lock"
> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
> "freelist par lock"
> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
> "SR_lock"                            share/vm/runtime/thread.cpp
> "CMS_markBitMap_lock"
> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>
>
> The remaining "sometimes" locks can be found in
> share/vm/runtime/mutexLocker.cpp:
>
> ParGCRareEvent_lock
> Safepoint_lock
> Threads_lock
> VMOperationQueue_lock
> VMOperationRequest_lock
> Terminator_lock
> Heap_lock
> Compile_lock
> PeriodicTask_lock
> JfrStacktrace_lock
>
>
> Thanks,
> Max Ockner
>
>
>
>
> On 11/25/2014 3:03 AM, David Holmes wrote:
>> Hi Max,
>>
>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>> Hello again,
>>>
>>> I have made changes based on all comments. There is now a pair of assert
>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>
>> Is there an updated webrev?
>>
>>> caught another lock that I had to change to "sometimes", but the assert
>>> that caught this lock was not in wait. There are currently no locks that
>>> use try to pass an incorrect safepoint check argument to wait().
>>> Instead, gcbasher did not catch this lock last time, when the only
>>> asserts were in lock and lock_without_safepoint. This lock is
>>> "CMS_markBitMap_lock" in
>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.
>>>
>>> I'm guessing that it was not caught by the tests because this section of
>>> code is not reached very often. My initial inspection failed to catch
>>> this lock because it is passed around between various structures and
>>> renamed 4 times. I have not yet found a good way to check for this
>>> situation, even with a debugger.
>>>
>>> Are there any tests which actually manage to hit every line of code?
>>
>> No. There is too much code that is dependent on low-level details of
>> the GC used, the compilation strategy, plus the set of runtime flags
>> used (and whether product or fastdebug). That's why we have lots of
>> tests run in lots of different ways, to try to get coverage.
>>
>>> How should I handle this situation where I can't rely on the tests that
>>> I have run to tell me if I have missed something?
>>> At what point can I assume that everything is OK?
>>
>> Difficult to answer in general - there are a number of recommended
>> test suites used by the runtime team, but your changes will also
>> impact GC and compiler code and so may not get exercised by the
>> runtime test suites (unless run with various compiler and GC options).
>> Perhaps an ad-hoc test run similar to nightlies? Or you push after the
>> weekly snapshot so as to maximise nightly testing, and if there are
>> issues exposed then you have time to address them or revert the fix.
>>
>> Cheers,
>> David
>>
>>> Thanks,
>>> Max Ockner
>>>
>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>> Hi Max,
>>>>
>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>> Hello all,
>>>>> I have made these additonal changes:
>>>>> -Moved the assert() statements into the lock and
>>>>> lock_without_safepoint
>>>>> methods.
>>>>> -Changed Monitor::SafepointAllowed to Monitor::SafepointCheckRequired
>>>>> -Changed the Monitor::SafepointCheckRequired values for several locks
>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>> MutexLocker, some were locked were locked without any MutexLocker* )
>>>>>
>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>
>>>> Generally this is all okay - a few style and other nits below.
>>>>
>>>> However you missed adding an assert in Monitor::wait to check if the
>>>> no_safepoint_check flag was being used correctly for the current
>>>> monitor.
>>>>
>>>> Specific comments:
>>>>
>>>> src/share/vm/runtime/mutex.hpp
>>>>
>>>> This comment is no longer accurate with the moved check location:
>>>>
>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>> + // to ensure consistent checking for each lock.
>>>>
>>>> The same goes for other references to MutexLockerEx in the enum
>>>> description.
>>>>
>>>> Also copyright year needs updating.
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutex.cpp
>>>>
>>>>  898   //Ensure
>>>>  961   //Ensure
>>>>
>>>> Space needed after //
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>
>>>> +  var = new type(Mutex::pri, #var,
>>>> vm_block,safepoint_check_allowed); \
>>>>
>>>> space needed after comma in k,s
>>>>
>>>> ---
>>>>
>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>
>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> Additional testing:
>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>> jtreg jfr tests
>>>>>
>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>
>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>> "CompactibleFreeListSpace._lock"
>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>
>>>>>
>>>>> "freelist par lock"
>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>
>>>>>
>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>
>>>>> The remaining "sometimes" locks can be found in
>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>
>>>>> ParGCRareEvent_lock
>>>>> Safepoint_lock
>>>>> Threads_lock
>>>>> VMOperationQueue_lock
>>>>> VMOperationRequest_lock
>>>>> Terminator_lock
>>>>> Heap_lock
>>>>> Compile_lock
>>>>> PeriodicTask_lock
>>>>> JfrStacktrace_lock
>>>>>
>>>>> I have not checked the validity of the "sometimes" locks, and I
>>>>> believe
>>>>> that this should be a different project.
>>>>>
>>>>> Thanks for your help!
>>>>> Max Ockner
>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>> Hi Max,
>>>>>>
>>>>>> This is looking good.
>>>>>>
>>>>>> A few high-level initial comments:
>>>>>>
>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>
>>>>>> Why are the checks in MutexLocker when the state is maintained in the
>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>> check in the mutex/monitor methods.
>>>>>>
>>>>>> Checking consistent usage of the _no_safepoint_check_flag is good.
>>>>>> But
>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>> safepoints should never be held when a thread blocks at a safepoint -
>>>>>> is there some way to easily check that? I was surprised how many
>>>>>> locks
>>>>>> are actually not checking for safepoints.
>>>>>>
>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>> inconsistently and incorrectly?
>>>>>>
>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>> Threads_lock with a safepoint check and a safepoint has been
>>>>>> requested
>>>>>> :) ).
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>
>>>>>>> Summary: MutexLockerEx can either acquire a lock with or without a
>>>>>>> safepoint check.
>>>>>>> In some cases, a particular lock must either safepoint check
>>>>>>> always or
>>>>>>> never to avoid deadlocking.
>>>>>>> Some other locks have semantics which allow them to avoid deadlocks
>>>>>>> despite having a safepoint check only some of the time.
>>>>>>> All locks that are OK having inconsistent safepoint checks have been
>>>>>>> marked. All locks that should never safepoint check and all locks
>>>>>>> that
>>>>>>> should always safepoint check have also been marked.
>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>> check,
>>>>>>> the lock's safepointAllowed marker is checked to ensure consistent
>>>>>>> safepoint checking.
>>>>>>>
>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>
>>>>>>> Tested with:
>>>>>>>      jprt "-testset hotspot"
>>>>>>>      jtreg hotspot
>>>>>>>      vm.quick.testlist
>>>>>>>
>>>>>>> Whitebox tests:
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test
>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test
>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code
>>>>>>> should not assert. (Lock is properly acquired with no safepoint
>>>>>>> check)
>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code
>>>>>>> should not assert. (Lock is properly acquired with safepoint check)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Max
>>>>>>>
>>>>>
>>>
>

From staffan.larsen at oracle.com  Mon Dec  8 06:59:22 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 8 Dec 2014 07:59:22 +0100
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <5482237E.6010201@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
Message-ID: <AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>

I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. 

/Staffan

> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> Hi Staffan,
> 
> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
> 
> Thanks
> Igor
> 
> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>> perhaps he has future plans for this.
>> Igor?
>> 
>> Thanks,
>> Dmitrij
>>> Utils.ITERATION_COUNT does not look like something that is usable
>>> outside these specific tests? Should it really be part of the test
>>> library?
>>> 
>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>> 
>>>> Adding hotspot-dev for wider audience.
>>>>> Hi,
>>>>> 
>>>>> Please review changes for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>> Test task: JMX- tests
>>>>> and
>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>> in testlibrary for JDK-8059613
>>>>> 
>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>> testing thresholds, usage,
>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>> tests.
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>> 
>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>> 
>>>>> Additional note: this patch assumes
>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>> is fixed.
>>>>> 
>>>>> Thanks,
>>>>> Dmitrij
>> 


From david.holmes at oracle.com  Mon Dec  8 07:00:04 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Dec 2014 17:00:04 +1000
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <548544D7.3030509@oracle.com>
References: <5481A724.1070107@oracle.com> <5485086F.3090007@oracle.com>
	<548544D7.3030509@oracle.com>
Message-ID: <54854C74.8010308@oracle.com>

Hi Igor,

On 8/12/2014 4:27 PM, Igor Ignatyev wrote:
> David,
>
> initially, we wanted to change WB::allocateCodeBlob to take jlong w/o
> truncating. for that we make CodeCache::allocate to take size_t instead
> of int, however it leads to too many changes in the product. And we were
> sure that all these changes are safe, so it was decided to make changes
> as smaller as possible.
>
> what do you think about the version w/ check? smth like:
>> public long allocateCodeBlob(long size, int type) {
>>  int i = (int) size;
>>  if ((long)i != size) { throw new IAE(); }
>>  return allocateCodeBlob(i, type);
>> }

Yes that would be more acceptable. I've looked at the other tests and 
see how the use of uint/x forces us to use Java longs. But still seems 
to me that the tests are where we should be concerned that we haven't 
overflowed the int. But I can live with the above safety check.

Thanks,
David

> 8065134 was filled by Dmitrij Pochepko, and it's needed for his tests
> JMX tests for SegmentedCodeCache[1]. so I think he can enlighten us
> about connection.
>
> Dima,
> could you please explain connection between beans and allocateCodeBlob?
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016336.html
>
>
> Thanks,
> Igor
>
> On 12/08/2014 05:09 AM, David Holmes wrote:
>> On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote:
>>> Hi all,
>>>
>>> please review this new small patch
>>>
>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
>>> webrev:
>>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/
>>>
>>> Problem:
>>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>>> WhiteBox::allocateCodeBlob(int, int) exist.
>>>
>>> I change previous fix to this new patch because this conversation [*]
>>>
>>> Solution:
>>>    public long allocateCodeBlob(long size, int type) {
>>>        return allocateCodeBlob((int) size, type);
>>>    }
>>
>> I still think this is a bad idea. The callsite needs to know, and show,
>> that the size it is passing will be truncated. And I still don't see a
>> connection between MX bean memory sizes and allocateCodeBlob.
>>
>> David
>>
>>
>>> Test: jprt
>>>
>>> [*]
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Tatiana

From tobias.hartmann at oracle.com  Mon Dec  8 07:24:36 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 08 Dec 2014 08:24:36 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com>
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
Message-ID: <54855234.3050400@oracle.com>

Hi,

As we discussed off-thread I copied the Whitebox API to the top level repository
(test/testlibrary). We will then file a RFE to adopt the hotspot tests and
eventually remove the testlibrary from the hotspot repo.

New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/

Can I get reviews for this?

Thanks,
Tobias

On 04.12.2014 11:29, Staffan Larsen wrote:
> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code.
> 
> /Staffan
> 
>> On 4 dec 2014, at 08:32, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>
>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
>> the library at the moment. What do you think about having the duplication as an
>> intermediate solution until we get the necessary support from jtreg / jprt to
>> share the library?
>>
>> There are also other JDK tests that would benefit from having the Whitebox API
>> available. For example, JDK-8057707 [1].
>>
>> Thanks,
>> Tobias
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
>>
>> On 02.12.2014 20:54, Tobias Hartmann wrote:
>>> Hi Staffan,
>>>
>>> thanks for the feedback.
>>>
>>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>>>
>>>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>>>
>>>>>
>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>>
>>>>>> Hi Mikael,
>>>>>>
>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>>>
>>>>>>> Tobias,
>>>>>>>
>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>>>> copy the code. I can't stress that enough.
>>>>>>
>>>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>>>> library from different repositories and I don't think we want to have path
>>>>>> dependencies between the repositories.
>>>>>>
>>>>>> Any suggestions?
>>>>>
>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>>>
>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>>>
>>>>   @library /../../test/testlibrary
>>>>
>>>> I don?t think that is what we want to do?
>>>
>>> Yes, that's what I meant with "path dependencies between repositories". I don't
>>> think this is a very robust solution.
>>>
>>> Best,
>>> Tobias
>>>
>>>>
>>>> /Staffan
>>>>
>>>>
>>>>>
>>>>> /Staffan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Mikael
>>>>>>>
>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>>>
>>>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>>>> library in the future.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>
>>>>>
>>>>
> 

From staffan.larsen at oracle.com  Mon Dec  8 07:37:11 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 8 Dec 2014 08:37:11 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <54855234.3050400@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com>
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
	<54855234.3050400@oracle.com>
Message-ID: <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>

I am for this change in principle, but before we go ahead I think this warrants a larger discussion on build-dev at ojn or jdk9-dev at ojn. We need to propose and get acceptance for this from the larger group.

(I was also surprised to see a Makefile here - who calls that?)

/Staffan

> On 8 dec 2014, at 08:24, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
> 
> Hi,
> 
> As we discussed off-thread I copied the Whitebox API to the top level repository
> (test/testlibrary). We will then file a RFE to adopt the hotspot tests and
> eventually remove the testlibrary from the hotspot repo.
> 
> New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
> 
> Can I get reviews for this?
> 
> Thanks,
> Tobias
> 
> On 04.12.2014 11:29, Staffan Larsen wrote:
>> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code.
>> 
>> /Staffan
>> 
>>> On 4 dec 2014, at 08:32, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>> 
>>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
>>> the library at the moment. What do you think about having the duplication as an
>>> intermediate solution until we get the necessary support from jtreg / jprt to
>>> share the library?
>>> 
>>> There are also other JDK tests that would benefit from having the Whitebox API
>>> available. For example, JDK-8057707 [1].
>>> 
>>> Thanks,
>>> Tobias
>>> 
>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
>>> 
>>> On 02.12.2014 20:54, Tobias Hartmann wrote:
>>>> Hi Staffan,
>>>> 
>>>> thanks for the feedback.
>>>> 
>>>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>>>> 
>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Mikael,
>>>>>>> 
>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>>>> 
>>>>>>>> Tobias,
>>>>>>>> 
>>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>>>>> copy the code. I can't stress that enough.
>>>>>>> 
>>>>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>>>>> library from different repositories and I don't think we want to have path
>>>>>>> dependencies between the repositories.
>>>>>>> 
>>>>>>> Any suggestions?
>>>>>> 
>>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>>>> 
>>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>>>> 
>>>>>  @library /../../test/testlibrary
>>>>> 
>>>>> I don?t think that is what we want to do?
>>>> 
>>>> Yes, that's what I meant with "path dependencies between repositories". I don't
>>>> think this is a very robust solution.
>>>> 
>>>> Best,
>>>> Tobias
>>>> 
>>>>> 
>>>>> /Staffan
>>>>> 
>>>>> 
>>>>>> 
>>>>>> /Staffan
>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>> 
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Mikael
>>>>>>>> 
>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>>>> 
>>>>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>>>>> library in the future.
>>>>>>>>> 
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Tobias
>>>>>>>> 
>>>>>> 
>>>>> 
>> 


From tobias.hartmann at oracle.com  Mon Dec  8 09:06:57 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 08 Dec 2014 10:06:57 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com>
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
	<54855234.3050400@oracle.com>
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>
Message-ID: <54856A31.9020702@oracle.com>

CC'ing to jdk9-dev for wider audience.

Summary:
The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests [2] need
access to the Whitebox API testlibrary that is part of the hotspot repository.

We therefore propose to move the Whitebox API from the hotspot repository to the
top level repository (test/testlibrary/) in the following steps:

1) Copy testlibrary to top level repository
2) Adapt existing hotspot tests (> 200 tests)
3) Remove testlibrary from hotspot repository

First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/

Thanks,
Tobias

[1] https://bugs.openjdk.java.net/browse/JDK-8066625
[2] https://bugs.openjdk.java.net/browse/JDK-8064875

On 08.12.2014 08:37, Staffan Larsen wrote:
> I am for this change in principle, but before we go ahead I think this warrants a larger discussion on build-dev at ojn or jdk9-dev at ojn. We need to propose and get acceptance for this from the larger group.
> 
> (I was also surprised to see a Makefile here - who calls that?)
> 
> /Staffan
> 
>> On 8 dec 2014, at 08:24, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>
>> Hi,
>>
>> As we discussed off-thread I copied the Whitebox API to the top level repository
>> (test/testlibrary). We will then file a RFE to adopt the hotspot tests and
>> eventually remove the testlibrary from the hotspot repo.
>>
>> New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
>>
>> Can I get reviews for this?
>>
>> Thanks,
>> Tobias
>>
>> On 04.12.2014 11:29, Staffan Larsen wrote:
>>> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code.
>>>
>>> /Staffan
>>>
>>>> On 4 dec 2014, at 08:32, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>
>>>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
>>>> the library at the moment. What do you think about having the duplication as an
>>>> intermediate solution until we get the necessary support from jtreg / jprt to
>>>> share the library?
>>>>
>>>> There are also other JDK tests that would benefit from having the Whitebox API
>>>> available. For example, JDK-8057707 [1].
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
>>>>
>>>> On 02.12.2014 20:54, Tobias Hartmann wrote:
>>>>> Hi Staffan,
>>>>>
>>>>> thanks for the feedback.
>>>>>
>>>>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>>>>>
>>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Mikael,
>>>>>>>>
>>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>>>>>
>>>>>>>>> Tobias,
>>>>>>>>>
>>>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>>>>>> copy the code. I can't stress that enough.
>>>>>>>>
>>>>>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>>>>>> library from different repositories and I don't think we want to have path
>>>>>>>> dependencies between the repositories.
>>>>>>>>
>>>>>>>> Any suggestions?
>>>>>>>
>>>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>>>>>
>>>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>>>>>
>>>>>>  @library /../../test/testlibrary
>>>>>>
>>>>>> I don?t think that is what we want to do?
>>>>>
>>>>> Yes, that's what I meant with "path dependencies between repositories". I don't
>>>>> think this is a very robust solution.
>>>>>
>>>>> Best,
>>>>> Tobias
>>>>>
>>>>>>
>>>>>> /Staffan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> /Staffan
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Mikael
>>>>>>>>>
>>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>>>>>
>>>>>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>>>>>> library in the future.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias
>>>>>>>>>
>>>>>>>
>>>>>>
>>>
> 

From tobias.hartmann at oracle.com  Mon Dec  8 09:12:06 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 08 Dec 2014 10:12:06 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to /jdk/test
In-Reply-To: <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com>
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
	<54855234.3050400@oracle.com>
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>
Message-ID: <54856B66.3000005@oracle.com>

Hi Staffan,

On 08.12.2014 08:37, Staffan Larsen wrote:
> I am for this change in principle, but before we go ahead I think this warrants a larger discussion on build-dev at ojn or jdk9-dev at ojn. We need to propose and get acceptance for this from the larger group.

I sent a request to jdk9-dev.

> (I was also surprised to see a Makefile here - who calls that?)

It was added by Igor Ignatyev with JDK-8012447:

"I also added Makefile for WhiteBox to simplify its using outside the
jtreg-testbase." [1]

Thanks,
Tobias

[1]
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-September/011572.html

> 
> /Staffan
> 
>> On 8 dec 2014, at 08:24, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>
>> Hi,
>>
>> As we discussed off-thread I copied the Whitebox API to the top level repository
>> (test/testlibrary). We will then file a RFE to adopt the hotspot tests and
>> eventually remove the testlibrary from the hotspot repo.
>>
>> New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
>>
>> Can I get reviews for this?
>>
>> Thanks,
>> Tobias
>>
>> On 04.12.2014 11:29, Staffan Larsen wrote:
>>> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code.
>>>
>>> /Staffan
>>>
>>>> On 4 dec 2014, at 08:32, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>
>>>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
>>>> the library at the moment. What do you think about having the duplication as an
>>>> intermediate solution until we get the necessary support from jtreg / jprt to
>>>> share the library?
>>>>
>>>> There are also other JDK tests that would benefit from having the Whitebox API
>>>> available. For example, JDK-8057707 [1].
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
>>>>
>>>> On 02.12.2014 20:54, Tobias Hartmann wrote:
>>>>> Hi Staffan,
>>>>>
>>>>> thanks for the feedback.
>>>>>
>>>>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>>>>>
>>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Mikael,
>>>>>>>>
>>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>>>>>
>>>>>>>>> Tobias,
>>>>>>>>>
>>>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>>>>>> copy the code. I can't stress that enough.
>>>>>>>>
>>>>>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>>>>>> library from different repositories and I don't think we want to have path
>>>>>>>> dependencies between the repositories.
>>>>>>>>
>>>>>>>> Any suggestions?
>>>>>>>
>>>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>>>>>
>>>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>>>>>
>>>>>>  @library /../../test/testlibrary
>>>>>>
>>>>>> I don?t think that is what we want to do?
>>>>>
>>>>> Yes, that's what I meant with "path dependencies between repositories". I don't
>>>>> think this is a very robust solution.
>>>>>
>>>>> Best,
>>>>> Tobias
>>>>>
>>>>>>
>>>>>> /Staffan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> /Staffan
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Mikael
>>>>>>>>>
>>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>>>>>
>>>>>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>>>>>> library in the future.
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias
>>>>>>>>>
>>>>>>>
>>>>>>
>>>
> 

From stefan.sarne at oracle.com  Mon Dec  8 10:19:26 2014
From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=)
Date: Mon, 08 Dec 2014 11:19:26 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <54856A31.9020702@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com>
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
	<54855234.3050400@oracle.com>
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>
	<54856A31.9020702@oracle.com>
Message-ID: <54857B2E.8020100@oracle.com>


I think this is a good path forward.

The WhiteBox api is just the next example of test library code which we 
want to use both from the hotspot and the jdk repo. There are other 
classes which exists in both repos, which currently are copies. And just 
as expected with copies - time is spent to keep them in sync and yet 
they are not. Copy vs. share is a trade off but in this case I lean 
towards share, since this has been brought up as an issue at multiple 
times. Other examples are ProcessTools, OutputAnalyzer and friends.

If we treat the WhiteBox API as a pilot, we should create an RFE that 
follows up for the other utilities.
This would also be a good place to discuss the structure of the test 
library.

I don't see a shared test library replacing the local ones - it would 
just a be a complement when the library code is shared.

If we do setup a shared place for this, we also should have a good way 
to handle changes to it.
It would be easy to start here - on jdk9-dev, but if it turns out to be 
needed, we could setup a separate list.

Based on the discussion around microbenchmarks, it may make sense to 
break out the test folder to a separate repo if it starts growing.
But again, perhaps this is something we can wait for and handle in the 
RFE. The test folder already exists in the top repo.

Cheers,
Stefan


Tobias Hartmann skrev 2014-12-08 10:06:
> CC'ing to jdk9-dev for wider audience.
>
> Summary:
> The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests [2] need
> access to the Whitebox API testlibrary that is part of the hotspot repository.
>
> We therefore propose to move the Whitebox API from the hotspot repository to the
> top level repository (test/testlibrary/) in the following steps:
>
> 1) Copy testlibrary to top level repository
> 2) Adapt existing hotspot tests (> 200 tests)
> 3) Remove testlibrary from hotspot repository
>
> First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
>
> Thanks,
> Tobias
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8066625
> [2] https://bugs.openjdk.java.net/browse/JDK-8064875
>
> On 08.12.2014 08:37, Staffan Larsen wrote:
>> I am for this change in principle, but before we go ahead I think this warrants a larger discussion on build-dev at ojn or jdk9-dev at ojn. We need to propose and get acceptance for this from the larger group.
>>
>> (I was also surprised to see a Makefile here - who calls that?)
>>
>> /Staffan
>>
>>> On 8 dec 2014, at 08:24, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> As we discussed off-thread I copied the Whitebox API to the top level repository
>>> (test/testlibrary). We will then file a RFE to adopt the hotspot tests and
>>> eventually remove the testlibrary from the hotspot repo.
>>>
>>> New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
>>>
>>> Can I get reviews for this?
>>>
>>> Thanks,
>>> Tobias
>>>
>>> On 04.12.2014 11:29, Staffan Larsen wrote:
>>>> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code.
>>>>
>>>> /Staffan
>>>>
>>>>> On 4 dec 2014, at 08:32, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>
>>>>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing
>>>>> the library at the moment. What do you think about having the duplication as an
>>>>> intermediate solution until we get the necessary support from jtreg / jprt to
>>>>> share the library?
>>>>>
>>>>> There are also other JDK tests that would benefit from having the Whitebox API
>>>>> available. For example, JDK-8057707 [1].
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
>>>>>
>>>>> On 02.12.2014 20:54, Tobias Hartmann wrote:
>>>>>> Hi Staffan,
>>>>>>
>>>>>> thanks for the feedback.
>>>>>>
>>>>>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Mikael,
>>>>>>>>>
>>>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>>>>>> Tobias,
>>>>>>>>>>
>>>>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it
>>>>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to
>>>>>>>>>> copy the code. I can't stress that enough.
>>>>>>>>> I agree that having the testlibrary in a shared location is definitely the best
>>>>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the
>>>>>>>>> library from different repositories and I don't think we want to have path
>>>>>>>>> dependencies between the repositories.
>>>>>>>>>
>>>>>>>>> Any suggestions?
>>>>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should.
>>>>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as:
>>>>>>>
>>>>>>>   @library /../../test/testlibrary
>>>>>>>
>>>>>>> I don?t think that is what we want to do?
>>>>>> Yes, that's what I meant with "path dependencies between repositories". I don't
>>>>>> think this is a very robust solution.
>>>>>>
>>>>>> Best,
>>>>>> Tobias
>>>>>>
>>>>>>> /Staffan
>>>>>>>
>>>>>>>
>>>>>>>> /Staffan
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Tobias
>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Mikael
>>>>>>>>>>
>>>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> please review the following patch that copies the Whitebox testlibrary to
>>>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]).
>>>>>>>>>>>
>>>>>>>>>>> The change leads to code duplication but in my opinion we should favour stable
>>>>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the
>>>>>>>>>>> library in the future.
>>>>>>>>>>>
>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Tobias


From thomas.stuefe at gmail.com  Mon Dec  8 10:27:16 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 8 Dec 2014 11:27:16 +0100
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <54854475.20800@oracle.com>
References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com>
	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>
	<543B1FD6.3000200@oracle.com> <543CF553.80601@gmail.com>
	<543DC2BF.9050407@oracle.com> <543E80F8.3080204@gmail.com>
	<547330E5.1050708@gmail.com>
	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>
	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com> <547C079A.9020604@oracle.com>
	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
	<547C1815.6050900@oracle.com>
	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>
	<547C38AD.6050703@gmail.com>
	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
	<547D891D.7010809@oracle.com> <547DCCFB.3050209@gmail.com>
	<54854475.20800@oracle.com>
Message-ID: <CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>

Hi,

I do not really like the handling of the leading pipe symbol:

So, we read the core_pattern, and if the pipe symbol is detected, we write
the core pattern minus the pipe symbol but plus a leading quote to the
output; the leading quote then serves as a info to the layer above in
os_posix.cpp to treat this case specially. This means the logic spills out
of the platform dependend os_linux.cpp to shared code and this is also
difficult to read.

This comes from the fact that "get_core_path()" assumes the core file is
written to the file system. I think it just does not fit anymore, better
would be to replace it with something like
"os::print_core_file_location(outputStream* os)", and the OS handles both
core path retrieval and the printing. Because then the shared code does not
need to know whether core file gets printed traditionally or piped to a
executable or whatever.

Kind regards, Thomas


On Mon, Dec 8, 2014 at 7:25 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Yasumasa,
>
> I'm okay with these changes. Just a minor style nit (no need for updated
> webrev) can you remove the blank lines in os_linux.cpp:
>
> 6011       }
> 6012
> 6013     }
> 6014
> 6015   }
>
> 6057       }
> 6058
> 6059     }
> 6060
> 6061   }
>
> If anyone has any objections please raise them asap.
>
> Thanks,
> David
>
>
> On 3/12/2014 12:30 AM, Yasumasa Suenaga wrote:
>
>> Hi David, Thomas,
>>
>> I've uploaded new webrev:
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.04/
>>
>>      I want to rewrite a patch as below:
>>>>
>>>>       - Use async signal safety functions.
>>>>         fopen -> open, fgets -> read, etc.
>>>>
>>>
>>> This is commendable if it is practical, but error reporting already
>>> does many, many things that are not async-signal safe, so there is no
>>> need to go to extreme measures here.
>>>
>>
>> I've used async-signal safe functions as possible.
>>
>>
>>        - Use O_BUFLEN for buffer size.
>>>>         O_BUFLEN is defined to 2000 in ostream.hpp .
>>>>         This macro is used in various points.
>>>> VMError::coredump_message is
>>>>         also defined with this value.
>>>>
>>>>
>>>> I think PATH_MAX is fine. I think O_BUFLEN was originally used as a max.
>>>> length of temporary buffers to assemble an output line. And then it
>>>> spread a bit. But your intend is to hold a path and using PATH_MAX
>>>> clearly documents this.
>>>>
>>>
>> I've used PATH_MAX again.
>>
>>
>>  And, to really nitpick, right now you do not handle ERANGE with
>>>> get_current_path() (if the provided buffer is too small), which is
>>>> probably fine because it is improbable that a path is larger than
>>>> PATH_MAX. But if you change the size of the buffer to something which
>>>> may be smaller than PATH_MAX (O_BUFLEN), get_current_directory() may
>>>> fail.
>>>>
>>>
>> If get_current_path() call is failed in get_core_path(), get_core_path()
>> returns immediately with 0.
>> Caller (check_or_create_dump()) handles this result as illegal state.
>>
>> get_current_path() calls getcwd() only and redirects result to caller.
>> So result of this function is NULL, we can judge getcwd() was finished
>> with
>> error.
>> I think it is enough.
>>
>>
>>  I like your patch, I think it could be a nice time safer when
>>>> core_pattern is something unusual. But I also see Staffans point of
>>>> too-much-complexity. So I will keep out of this discussion until the
>>>> real Reviewers decided what to do :)
>>>>
>>>
>>> I have a hard time evaluating the merits of the patch as I don't work
>>> in an environment where this extra info is needed. But I take it on
>>> good faith that it is useful for the context Yasumasa describes.
>>>
>>
>> I want to suggest to Java user where coredump is.
>> Modern Linux distribution(s) contains ABRT.
>> OS can dump corefile automatically despite a lack of setting coredump
>> resource by user.
>>
>> I'm support engineer of Java. My customer says "coredump does not found.",
>> but coredump is saved by ABRT.
>> Thus I want them to know "coredump is available" through stderr and
>> hs_err immediately.
>> I belive it is first step of troubleshoot.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> (2014/12/02 18:40), David Holmes wrote:
>>
>>> On 1/12/2014 10:57 PM, Thomas St?fe wrote:
>>>
>>>> Hi Yasumasa,
>>>>
>>>> On Mon, Dec 1, 2014 at 10:45 AM, Yasumasa Suenaga <yasuenag at gmail.com
>>>> <mailto:yasuenag at gmail.com>> wrote:
>>>>
>>>>     Hi Thomas, David,
>>>>
>>>>     Sorry, I didn't think about async signal safety.
>>>>
>>>>         That would work, VmError::report_and_die() is singlethreaded. At
>>>>         least the part which dumps out the core file name.
>>>>
>>>>
>>>>     I think that signal handler (in this case) may run concurrency with
>>>>     other thread.
>>>>     If another thread calls malloc(3) in JNI, C Heap corruption may
>>>> occur.
>>>>
>>>>
>>>> No, malloc(3) should be thread safe on our platforms. But this was not
>>>> the point. If I understood David right, he suggested using a static
>>>> buffer inside get_core_path() for assembling the core path, which would
>>>> make get_core_path() thread-unsafe (multiple threads calling it would
>>>> get garbled results). But as get_core_path() is only called from within
>>>> VmError::report_and_die() and that section is only ever executed by one
>>>> thread, Davids suggestion would still work.
>>>>
>>>
>>> Yes that is what I was suggesting.
>>>
>>>      I want to rewrite a patch as below:
>>>>
>>>>       - Use async signal safety functions.
>>>>         fopen -> open, fgets -> read, etc.
>>>>
>>>
>>> This is commendable if it is practical, but error reporting already
>>> does many, many things that are not async-signal safe, so there is no
>>> need to go to extreme measures here.
>>>
>>>        - Use O_BUFLEN for buffer size.
>>>>         O_BUFLEN is defined to 2000 in ostream.hpp .
>>>>         This macro is used in various points.
>>>> VMError::coredump_message is
>>>>         also defined with this value.
>>>>
>>>>
>>>> I think PATH_MAX is fine. I think O_BUFLEN was originally used as a max.
>>>> length of temporary buffers to assemble an output line. And then it
>>>> spread a bit. But your intend is to hold a path and using PATH_MAX
>>>> clearly documents this.
>>>> And, to really nitpick, right now you do not handle ERANGE with
>>>> get_current_path() (if the provided buffer is too small), which is
>>>> probably fine because it is improbable that a path is larger than
>>>> PATH_MAX. But if you change the size of the buffer to something which
>>>> may be smaller than PATH_MAX (O_BUFLEN), get_current_directory() may
>>>> fail.
>>>>
>>>> I like your patch, I think it could be a nice time safer when
>>>> core_pattern is something unusual. But I also see Staffans point of
>>>> too-much-complexity. So I will keep out of this discussion until the
>>>> real Reviewers decided what to do :)
>>>>
>>>
>>> I have a hard time evaluating the merits of the patch as I don't work
>>> in an environment where this extra info is needed. But I take it on
>>> good faith that it is useful for the context Yasumasa describes.
>>>
>>> David
>>>
>>>  Kind Regards, Thomas
>>>>
>>>>

From aph at redhat.com  Mon Dec  8 12:58:07 2014
From: aph at redhat.com (Andrew Haley)
Date: Mon, 08 Dec 2014 12:58:07 +0000
Subject: Assertion failed: int pressure is incorrect
Message-ID: <5485A05F.9020701@redhat.com>

I'm occasionally seeing this:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/scratch1/large-codecache/hotspot/src/share/vm/opto/ifg.cpp:693), pid=9212, tid=4395909313024
#  assert(int_pressure.current_pressure() == count_int_pressure(liveout)) failed: the int pressure is incorrect
#

Does anyone know what might cause this?  Perhaps a bug in my back
end?  If not, can I please have some advice about how to debug it?

I'm only seeing this with a fairly recent cut of JDK9.

Thanks,
Andrew,

From stefan.johansson at oracle.com  Mon Dec  8 14:23:40 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 08 Dec 2014 15:23:40 +0100
Subject: RFR: 8062672: JVM crashes during GC on various asserts which
	checks that HeapWord ptr is an oop
In-Reply-To: <548231FE.5090301@oracle.com>
References: <5481825E.4080602@oracle.com> <548231FE.5090301@oracle.com>
Message-ID: <5485B46C.2020509@oracle.com>

Thanks for looking at this Jon,

On 2014-12-05 23:30, Jon Masamitsu wrote:
> Stefan,
>
> Changes look good.
>
> Would you like to explicitly check the return from
> fgets() against NULL?  Your call.
>
I see that all other while(fgets...) checks for != NULL so I will add it.
> What do you think of an assert after the call to fgets() to
> check the length of the returned string.
>
> assert(strnlen(line, 1023) < 1023, "buffer line[1024] is too small.");
>
> Too paranoid?
I like adding an assert, but using strnlen feels a little paranoid since 
fgets promise to add '\0' at the end even if the line is longer than the 
buffer. So I plan to add this assert:
assert(strlen(line) < sizeof(line) - 1, "buffer line[1024] is too small.");

Thanks,
Stefan
>
> Reviewed.
>
> Jon
>
> On 12/5/2014 2:01 AM, Stefan Johansson wrote:
>> Hi,
>>
>> Please review this fix for the linux-sparc issue described in:
>> https://bugs.openjdk.java.net/browse/JDK-8062672
>>
>> Webrev:
>> http://cr.openjdk.java.net/~sjohanss/8062672/hotspot.00/
>>
>> Summary:
>> This fix is based on 7u-dev because the most linux-sparc testing is 
>> done for that release and also because it's unclear if we have time 
>> to move the fix the normal way through 9 and 8u before going into 7u. 
>> But the main reason is that it would be good to get testing of the 
>> fix in 7u before porting it to 8u and 9.
>>
>> The fix it self is fairly simple, after JDK-8029190 was backported 
>> the condition for disabling UseMemSetInBOT changed from is_niagara() 
>> to has_blk_init(). This worked well for solaris-sparc but on 
>> linux-sparc we previously only set the niagara feature bits, so this 
>> change adds support for detecting blk_init support on linux-sparc.
>>
>> Testing:
>> Crashes/asserts was reproducible without the fix and after the fix 
>> none have been observed. Also verified that UseMemSetInBOT now is set 
>> to false as it should be.
>>
>> Thanks,
>> Stefan
>


From goetz.lindenmaier at sap.com  Mon Dec  8 15:54:36 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 8 Dec 2014 15:54:36 +0000
Subject: RFR(L): 8064457: Introduce compressed oops mode "disjoint base"
	and improve compressed heap handling.
In-Reply-To: <5480AB58.80604@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF264E2@DEWDFEMB12A.global.corp.sap>
	<5466A656.40707@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF27CD3@DEWDFEMB12A.global.corp.sap>
	<4295855A5C1DE049A61835A1887419CC2CF29936@DEWDFEMB12A.global.corp.sap>
	<547E4F3B.2090501@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF35E66@DEWDFEMB12A.global.corp.sap>
	<547F4914.1030904@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF36139@DEWDFEMB12A.global.corp.sap>
	<54809196.7030306@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF39BA5@DEWDFEMB12A.global.corp.sap>
	<5480AB58.80604@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF3D6BB@DEWDFEMB12A.global.corp.sap>

Hi,

This is just a ping to gc/rt mailing lists to reach appropriate
people.

I please need a reviewer from gc or rt, could somebody have a 
look at this?

Short summary:
- new cOops mode disjointbase that allows optimizations on PPC improving over heapbased
- search for heaps: finds zerobased on sparc Solaris 11 and Aix
- concentrate cOops heap allocation code in one function
http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/

Please reply only to the original thread in hotspot-dev to keep this
local.

Thanks and best regards,
  Goetz.

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Donnerstag, 4. Dezember 2014 19:44
To: Lindenmaier, Goetz
Cc: 'hotspot-dev developers'
Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.

This looks good to me.

Now we need second review since changes are significant. Preferable from 
GC group since you changed ReservedHeapSpace. They will be affected 
most. Review from Runtime is also welcome.

Thanks,
Vladimir

On 12/4/14 10:27 AM, Lindenmaier, Goetz wrote:
> Hi Vladimir.
>
> Sorry.  I updated the webrev once more.  Hope it's fine now.
> At least I can write comments :)
>
> Best regards,
>    Goetz
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Thursday, December 04, 2014 5:54 PM
> To: Lindenmaier, Goetz
> Cc: 'hotspot-dev developers'
> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>
> I spotted an other bug.
> You replaced !_base with _base != NULL when moved code to try_reserve_range() - it should be _base == NULL.
> The same problem in asserts:
>
> +  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(_base)->decode_pointer() == _base,
> +         "area must be distinguishable from marks for mark-sweep");
> +  assert(_base != NULL || markOopDesc::encode_pointer_as_mark(&_base[size])->decode_pointer() == &_base[size],
> +         "area must be distinguishable from marks for mark-sweep");
>
>
> Also you did not remove  _base && in next place:
>
> +         (_base && _base + size > zerobased_max))) {  // Unscaled delivered an arbitrary address.
>
> New comment is good.
>
> Thanks,
> Vladimri
>
> On 12/4/14 1:45 AM, Lindenmaier, Goetz wrote:
>> Hi Vladimir,
>>
>>> Add more extending comment explaining that.
>> The comment for try_reserve_heap was meant to explain that.
>> I further added a comment in initialize_compressed_heap().
>>
>>> You need another parameter to pass UnscaledOopHeapMax or zerobased_max.
>> Oh, thanks a lot!  That's important. Fixed.
>>
>>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
>> Sorry, now I got it.  Removed.
>>
>> I updated the webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
>> Increment on top of the increment :)
>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs2.patch
>>
>> Thanks,
>>     Goetz.
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Mittwoch, 3. Dezember 2014 18:32
>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>
>> Comments are below.
>>
>> On 12/3/14 5:49 AM, Lindenmaier, Goetz wrote:
>>> Hi Vladimir,
>>>
>>> thanks for looking at the change!  See my comments inline below.
>>>
>>> I made a new webrev:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/
>>> Incremental changes:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.02/incremental_diffs.patch
>>>
>>> Best regards,
>>>      Goetz.
>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Mittwoch, 3. Dezember 2014 00:46
>>>> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
>>>> Subject: Re: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>>
>>>> This looks good to me. Someone in runtime/gc have to look on it too.
>>>>
>>>> universe.cpp about SystemProperty("com.sap.vm.test.compressedOopsMode"
>>>> we have:
>>>> java.vm.info=mixed mode, sharing
>>>> so we can have:
>>>> java.vm.compressedOopsMode=...
>>> Yes, that's good for me. Fixed.
>>>
>>>> I am not expert in properties names but I don't want to have 'com.sap'
>>>> in VM's property name.
>>>
>>>> virtualspace.cpp:
>>>> Could you fix release() - it does not reset _alignment?
>>> Fixed.
>>>
>>>> In try_reserve_heap(), please, use (base == NULL) instead of (!base).
>>>> And you don't need 'return;' in alignment check at the end of method.
>>> Fixed.
>>>
>>>> In initialize_compressed_heap() again (!_base).
>>> Fixed.
>>>
>>>> You don't stop (check
>>>> (base == NULL)) after successful unscaled, zerobased, disjointbase
>>>> allocations. You need to separate them with the check:
>>>>
>>>> +
>>>> +    }
>>>> +  }
>>>> +  if (_base == NULL) {
>>>> +
>>>> +    if (PrintCompressedOopsMode && Verbose) {
>>>> +      tty->print(" == Z E R O B A S E D ==\n");
>>>> +    }
>>>> and so on.
>>> No, I can't and don't want to check for _base != NULL.
>>> I always keep the result of the last try, also if it didn't fulfil the required properties.
>>> So I take that result and go into the next check.  That check might succeed
>>> with the heap allocated before.
>>> This allows me to separate allocation and placement criteria, and to have the
>>> placement criteria checked in only one place (per mode).
>>> Only for HeapBaseMinAddress I don't do it that way, I explicitly call release().
>>> This way I can enforce mode heapbased.
>>
>> I see what you are saying. It was not clear from comments what is going on.
>> Add more extending comment explaining that.
>>
>>>
>>>> num_attempts calculation and while() loop are similar in unscaled and
>>>> zerobased cases. Could you move it into a separate method?
>>> I can do that, but I don't like it as I have to pass in 7 parameters.
>>
>> You need an other parameter to pass UnscaledOopHeapMax or zerobased_max.
>>
>>> That makes the code not much more readable.  The function will look like this:
>>
>> I think initialize_compressed_heap() is more readable now.
>>
>>>
>>> void ReserveHeapSpace::try_reserve_range(char *const highest_start, char *lowest_start, size_t attach_point_alignment,
>>>                                             char *aligned_HBMA, size_t size, size_t alignment, bool large) {
>>>      guarantee(HeapSearchSteps > 0, "Don't set HeapSearchSteps to 0");
>>>
>>>      const size_t attach_range = highest_start - lowest_start;
>>>      // Cap num_attempts at possible number.
>>>      // At least one is possible even for 0 sized attach range.
>>>      const uint64_t num_attempts_possible = (attach_range / attach_point_alignment) + 1;
>>>      const uint64_t num_attempts_to_try   = MIN2(HeapSearchSteps, num_attempts_possible);
>>>
>>>      const size_t stepsize = align_size_up(attach_range / num_attempts_to_try, attach_point_alignment);
>>>
>>>      // Try attach points from top to bottom.
>>>      char* attach_point = highest_start;
>>>      while (attach_point >= lowest_start  &&
>>>             attach_point <= highest_start &&  // Avoid wrap around.
>>>             (!_base || _base < aligned_HBMA || _base + size > (char *)UnscaledOopHeapMax)) {
>>>        try_reserve_heap(size, alignment, large, attach_point);
>>>        attach_point -= stepsize;
>>>      }
>>> }
>>>
>>>
>>>> In disjointbase while() condition no need for _base second check:
>>>> +           (_base == NULL ||
>>>> +            ((_base + size > (char *)OopEncodingHeapMax) &&
>>> I need this for the same reason as above:  This is the check for successful allocation.
>>
>> I mean that you already checked _base == NULL so on other side of || _base != NULL - why you need (_base &&) check?
>>
>> Thanks,
>> Vladimir
>>
>>>
>>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 11/21/14 5:31 AM, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> I prepared a new webrev trying to cover all the issues mentioned below.
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.01/
>>>>
>>>> I moved functionality from os.cpp and universe.cpp into
>>>> ReservedHeapSpace::initialize_compressed_heap().
>>>> This class offers to save _base and _special, which I would have to reimplement
>>>> if I had improved the methods I had added to os.cpp to also allocate large page
>>>> heaps.
>>>> Anyways, I think this class is the right place to gather code trying to reserve
>>>> the heap.
>>>> Also, I get along without setting the shift, base, implicit_null_check etc. fields
>>>> of Universe, so there is no unnecessary calling back and forth between the two
>>>> classes.
>>>> Universe gets the heap back, and then sets the properties it needs to configure
>>>> the compressed oops.
>>>> All code handling the noaccess prefix is in a single method, too.
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>> Btw, I had to workaround a SS12u1 problem: it wouldn't compile
>>>> char * x = (char*)UnscaledOopHeapMax - size in 32-bit mode.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
>>>> Sent: Montag, 17. November 2014 09:33
>>>> To: 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
>>>> Subject: RE: RFR(L): 8064457: Introduce compressed oops mode "disjoint base" and improve compressed heap handling.
>>>>
>>>> Hi Vladimir,
>>>>
>>>>> It is very significant rewriting and it takes time to evaluate it.
>>>> Yes, I know ... and I don't want to push, but nevertheless a ping
>>>> can be useful sometimes. Thanks a lot for looking at it.
>>>>
>>>>> And I would not say it is simpler then before :)
>>>> If I fix what you propose it's gonna get even more simple ;)
>>>>> These is what I found so far.
>>>>
>>>>> The idea to try to allocate in a range instead of just below
>>>>> UnscaledOopHeapMax or OopEncodingHeapMax is good. So I would ask to do
>>>>> several attempts (3?) on non_PPC64 platforms too.
>>>> Set to 3.
>>>>
>>>>> It is matter of preference but I am not comfortable with switch in loop.
>>>>> For me sequential 'if (addr == 0)' checks is simpler.
>>>> I'll fix this.
>>>>
>>>>> One thing worries me that you release found space and try to get it
>>>>> again with ReservedHeapSpace. Is it possible to add new
>>>>> ReservedHeapSpace ctor which simple use already allocated space?
>>>> This was to keep diff's small, but I also think a new constructor is good.
>>>> I'll fix this.
>>>>
>>>>> The next code in ReservedHeapSpace() is hard to understand ():
>>>>> (UseCompressedOops && (requested_address == NULL ||
>>>> requested_address+size > (char*)OopEncodingHeapMax) ?
>>>>> may be move all this into noaccess_prefix_size() and add comments.
>>>> I have to redo this anyways if I make new constructors.
>>>>
>>>>> Why you need prefix when requested_address == NULL?
>>>> If we allocate with NULL, we most probably will get a heap where
>>>> base != NULL and thus need a noaccess prefix.
>>>>
>>>>> Remove next comment in universe.cpp:
>>>>> // SAPJVM GL 2014-09-22
>>>> Removed.
>>>>
>>>>> Again you will release space so why bother to include space for classes?:
>>>>> +          // For small heaps, save some space for compressed class pointer
>>>>> +          // space so it can be decoded with no base.
>>>> This was done like this before.  We must assure the upper bound of the
>>>> heap is low enough that the compressed class space still fits in there.
>>>>
>>>> virtualspace.cpp
>>>>
>>>>> With new code size+noaccess_prefix could be requested. But later it is
>>>>> not used if WIN64_ONLY(&& UseLargePages) and you will have empty
>>>>> non-protected page below heap.
>>>> There's several points to this:
>>>>      * Also if not protectable, the heap base has to be below the real start of the
>>>>         heap.  Else the first object in the heap will be compressed to 'null'
>>>>         and decompression will fail.
>>>>      * If we don't reserve the memory other stuff can end up in this space. On
>>>>         errors, if would be quite unexpected to find memory there.
>>>>      * To get a heap for the new disjoint mode I must control the size of this.
>>>>          Requesting a heap starting at (aligned base + prefix) is more likely to fail.
>>>>      * The size for the prefix must anyways be considered when deciding whether the
>>>>          heap is small enough to run with compressed oops.
>>>> So distinguishing the case where we really can omit this would require
>>>> quite some additional checks everywhere, and I thought it's not worth it.
>>>>
>>>> matcher.hpp
>>>>
>>>>> Universe::narrow_oop_use_implicit_null_checks() should be true for such
>>>>> case too. So you can add new condition with || to existing ones. The
>>>>> only condition you relax is base != NULL. Right?
>>>> Yes, that's how it's intended.
>>>>
>>>> arguments.* files
>>>>
>>>>> Why you need PropertyList_add changes.
>>>> Oh, the code using it got lost.  I commented on this in the description in the webrev.
>>>> "To more efficiently run expensive tests in various compressed oop modes, we set a property with the mode the VM is running in. So far it's called "com.sap.vm.test.compressedOopsMode" better suggestions are welcome (and necessary I guess). Our long running tests that are supposed to run in a dedicated compressed oop mode check this property and abort themselves if it's not the expected mode."
>>>> When I know about the heap I do
>>>>         Arguments::PropertyList_add(new SystemProperty("com.sap.vm.test.compressedOopsMode",
>>>>                                                        narrow_oop_mode_to_string(narrow_oop_mode()),
>>>>                                                        false));
>>>> in universe.cpp.
>>>> On some OSes it's deterministic which modes work, there we don't start such tests.
>>>> Others, as you mentioned OSX,  are very indeterministic.  Here we save testruntime with this.
>>>> But it's not that important.
>>>> We can still parse the PrintCompresseOopsMode output after the test and discard the
>>>> run.
>>>>
>>>>> Do you have platform specific changes?
>>>> Yes, for ppc and aix.  I'll submit them once this is in.
>>>>
>>>>     From your other mail:
>>>>> One more thing. You should allow an allocation in the range when returned from OS allocated address does not match
>>>>> requested address. We had such cases on OSX, for example, when OS allocates at different address but still inside range.
>>>> Good point.  I'll fix that in os::attempt_reserve_memory_in_range.
>>>>
>>>> I'll ping again once a new webrev is done!
>>>>
>>>> Best regards,
>>>>       Goetz.
>>>>
>>>>
>>>> On 11/10/14 6:57 AM, Lindenmaier, Goetz wrote:
>>>>> Hi,
>>>>>
>>>>> I need to improve a row of things around compressed oops heap handling
>>>>> to achieve good performance on ppc.
>>>>> I prepared a first webrev for review:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8064457-disjoint/webrev.00/
>>>>>
>>>>> A detailed technical description of the change is in the webrev and according bug.
>>>>>
>>>>> If requested, I will split the change into parts with more respective less impact on
>>>>> non-ppc platforms.
>>>>>
>>>>> The change is derived from well-tested code in our VM.  Originally it was
>>>>> crafted to require the least changes of  VM coding, I changed it to be better
>>>>> streamlined with the VM.
>>>>> I tested this change to deliver heaps at about the same addresses as before.
>>>>> Heap addresses mostly differ in lower bits.  In some cases (Solaris 5.11) a heap
>>>>> in a better compressed oops mode is found, though.
>>>>> I ran (and adapted) test/runtime/CompressedOops and gc/arguments/TestUseCompressedOops*.
>>>>>
>>>>> Best regards,
>>>>>        Goetz.
>>>>>
>>>>>

From tatiana.pivovarova at oracle.com  Mon Dec  8 16:49:16 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Mon, 08 Dec 2014 19:49:16 +0300
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method
	to be implemented
Message-ID: <5485D68C.7040106@oracle.com>

Hi all,

please review this new patch

bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/

Problem:
Need WhiteBox::allocateCodeBlob(long, int), currently only 
WhiteBox::allocateCodeBlob(int, int) exist.

Solution:
Add new function with check:

  156   public        long    allocateCodeBlob(long size, int type) {
  157       int intSize = (int) size;
  158       if ((long) intSize != size || size < 0) {
  159           throw new IllegalArgumentException(
  160                 "size argument has illegal value " + size);
  161       }
  162       return allocateCodeBlob( intSize, type);
  163   }


Test: jprt


Thanks,
Tatiana

From vladimir.kozlov at oracle.com  Mon Dec  8 17:06:06 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 08 Dec 2014 09:06:06 -0800
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <5485D68C.7040106@oracle.com>
References: <5485D68C.7040106@oracle.com>
Message-ID: <5485DA7E.5000906@oracle.com>

The webrev is wrong, should be

http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.03/

which looks good.

Thanks,
Vladimir

On 12/8/14 8:49 AM, Tatiana Pivovarova wrote:
> Hi all,
>
> please review this new patch
>
> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
> webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/
>
> Problem:
> Need WhiteBox::allocateCodeBlob(long, int), currently only WhiteBox::allocateCodeBlob(int, int) exist.
>
> Solution:
> Add new function with check:
>
>   156   public        long    allocateCodeBlob(long size, int type) {
>   157       int intSize = (int) size;
>   158       if ((long) intSize != size || size < 0) {
>   159           throw new IllegalArgumentException(
>   160                 "size argument has illegal value " + size);
>   161       }
>   162       return allocateCodeBlob( intSize, type);
>   163   }
>
>
> Test: jprt
>
>
> Thanks,
> Tatiana

From mark.reinhold at oracle.com  Mon Dec  8 19:18:59 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 08 Dec 2014 11:18:59 -0800
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <54857B2E.8020100@oracle.com>
References: <547DCF47.9000608@oracle.com>, <547DF563.8080509@oracle.com>,
	<547DF8D8.8080601@oracle.com>,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>
Message-ID: <20141208111859.936395@eggemoggin.niobe.net>

2014/12/8 2:19 -0800, stefan.sarne at oracle.com:
> ...
> 
> This would also be a good place to discuss the structure of the test 
> library.

Yes.  The various "testlibrary" directories in different repos are, at
the moment, a bit of a mess and in some cases appear to be redundant.

For the present root-repo proposal:

  - Why is it named test/testlibrary rather than test/lib, which is
    what's used in the jdk repo?

  - Why does the white-box library get its own directory?  Shouldn't
    all test-library classes have the same package root?

  - The package name "sun.hotspot" is archaic.  We should figure out a
    proper naming scheme for test-library packages, preferably starting
    with "jdk.".

> ...
> 
> Based on the discussion around microbenchmarks, it may make sense to
> break out the test folder to a separate repo if it starts growing.
> But again, perhaps this is something we can wait for and handle in the
> RFE. The test folder already exists in the top repo.

The jdk/test/lib directory has been around for many years now and only
contains 28 files.  It seems unlikely that the root-repo equivalent will
ever be much larger than that, so a separate repo would be overkill.

- Mark

From staffan.larsen at oracle.com  Mon Dec  8 19:46:59 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 8 Dec 2014 20:46:59 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <20141208111859.936395@eggemoggin.niobe.net>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com>,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>
	<20141208111859.936395@eggemoggin.niobe.net>
Message-ID: <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>


> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote:
> 
> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com:
>> ...
>> 
>> This would also be a good place to discuss the structure of the test 
>> library.
> 
> Yes.  The various "testlibrary" directories in different repos are, at
> the moment, a bit of a mess and in some cases appear to be redundant.
> 
> For the present root-repo proposal:
> 
>  - Why is it named test/testlibrary rather than test/lib, which is
>    what's used in the jdk repo?

Probably because it?s called test/testlibrary in the hotspot repo :-)

>  - Why does the white-box library get its own directory?  Shouldn't
>    all test-library classes have the same package root?

+1

>  - The package name "sun.hotspot" is archaic.  We should figure out a
>    proper naming scheme for test-library packages, preferably starting
>    with "jdk.?.

So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?

> 
>> ...
>> 
>> Based on the discussion around microbenchmarks, it may make sense to
>> break out the test folder to a separate repo if it starts growing.
>> But again, perhaps this is something we can wait for and handle in the
>> RFE. The test folder already exists in the top repo.
> 
> The jdk/test/lib directory has been around for many years now and only
> contains 28 files.  It seems unlikely that the root-repo equivalent will
> ever be much larger than that, so a separate repo would be overkill.

The corresponding directory in hotspot has 56 files and has expanded quite a bit recently. I expect some growth to continue. Many of these overlap with the files in the jdk directory, however.

/Staffan


From jon.masamitsu at oracle.com  Mon Dec  8 20:00:20 2014
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Mon, 08 Dec 2014 12:00:20 -0800
Subject: RFR: 8062672: JVM crashes during GC on various asserts which
	checks that HeapWord ptr is an oop
In-Reply-To: <5485B46C.2020509@oracle.com>
References: <5481825E.4080602@oracle.com> <548231FE.5090301@oracle.com>
	<5485B46C.2020509@oracle.com>
Message-ID: <54860354.9040707@oracle.com>


On 12/08/2014 06:23 AM, Stefan Johansson wrote:
> Thanks for looking at this Jon,
>
> On 2014-12-05 23:30, Jon Masamitsu wrote:
>> Stefan,
>>
>> Changes look good.
>>
>> Would you like to explicitly check the return from
>> fgets() against NULL?  Your call.
>>
> I see that all other while(fgets...) checks for != NULL so I will add it.
>> What do you think of an assert after the call to fgets() to
>> check the length of the returned string.
>>
>> assert(strnlen(line, 1023) < 1023, "buffer line[1024] is too small.");
>>
>> Too paranoid?
> I like adding an assert, but using strnlen feels a little paranoid 
> since fgets promise to add '\0' at the end even if the line is longer 
> than the buffer. So I plan to add this assert:
> assert(strlen(line) < sizeof(line) - 1, "buffer line[1024] is too 
> small.");

Ok.  That's fine.

Jon

>
> Thanks,
> Stefan
>>
>> Reviewed.
>>
>> Jon
>>
>> On 12/5/2014 2:01 AM, Stefan Johansson wrote:
>>> Hi,
>>>
>>> Please review this fix for the linux-sparc issue described in:
>>> https://bugs.openjdk.java.net/browse/JDK-8062672
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~sjohanss/8062672/hotspot.00/
>>>
>>> Summary:
>>> This fix is based on 7u-dev because the most linux-sparc testing is 
>>> done for that release and also because it's unclear if we have time 
>>> to move the fix the normal way through 9 and 8u before going into 
>>> 7u. But the main reason is that it would be good to get testing of 
>>> the fix in 7u before porting it to 8u and 9.
>>>
>>> The fix it self is fairly simple, after JDK-8029190 was backported 
>>> the condition for disabling UseMemSetInBOT changed from is_niagara() 
>>> to has_blk_init(). This worked well for solaris-sparc but on 
>>> linux-sparc we previously only set the niagara feature bits, so this 
>>> change adds support for detecting blk_init support on linux-sparc.
>>>
>>> Testing:
>>> Crashes/asserts was reproducible without the fix and after the fix 
>>> none have been observed. Also verified that UseMemSetInBOT now is 
>>> set to false as it should be.
>>>
>>> Thanks,
>>> Stefan
>>
>


From dmitrij.pochepko at oracle.com  Fri Dec  5 20:13:35 2014
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Fri, 05 Dec 2014 23:13:35 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
Message-ID: <548211EF.3050402@oracle.com>

During internal team review, Igor.Igntatyev asked to move it to Utils, 
perhaps he has future plans for this.
Igor?

Thanks,
Dmitrij
> Utils.ITERATION_COUNT does not look like something that is usable outside these specific tests? Should it really be part of the test library?
>
>> On 5 dec 2014, at 18:18, Dmitrij Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>
>> Adding hotspot-dev for wider audience.
>>> Hi,
>>>
>>> Please review changes for
>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: JMX- tests
>>> and
>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in testlibrary for JDK-8059613
>>>
>>> It introduce a number of tests for segmented code cache, mostly testing thresholds, usage,
>>> memory notifications using respective MemoryPoolMXBean(s).
>>> There is also a small modification for testlibrary(8066440) used in tests.
>>>
>>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>
>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>
>>> Additional note: this patch assumes "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed.
>>>
>>> Thanks,
>>> Dmitrij


From dmitrij.pochepko at oracle.com  Mon Dec  8 13:02:22 2014
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Mon, 08 Dec 2014 16:02:22 +0300
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <548544D7.3030509@oracle.com>
References: <5481A724.1070107@oracle.com> <5485086F.3090007@oracle.com>
	<548544D7.3030509@oracle.com>
Message-ID: <5485A15E.7030801@oracle.com>

Hi,

connection is simple: MemoryPoolMXBean::getUsage()::getUsed() returns 
long. Also, -XX:CodeCacheSegmentSize and -XX:CodeCacheMinBlockLength 
returned as long, so, most operation uses long, and basically the only 
call using int is WB::allocateCodeBlob. So, that's more logical to have 
long parameter in allocateCodeBlob. An alternative is to make some 
surrogate with basically the same code in tests, while it might be 
needed in another tests, so, it seems like moving it to WhiteBox would 
be more logical.

Thanks,
Dmitrij
> David,
>
> initially, we wanted to change WB::allocateCodeBlob to take jlong w/o 
> truncating. for that we make CodeCache::allocate to take size_t 
> instead of int, however it leads to too many changes in the product. 
> And we were sure that all these changes are safe, so it was decided to 
> make changes as smaller as possible.
>
> what do you think about the version w/ check? smth like:
>> public long allocateCodeBlob(long size, int type) {
>>  int i = (int) size;
>>  if ((long)i != size) { throw new IAE(); }
>>  return allocateCodeBlob(i, type);
>> }
>
> 8065134 was filled by Dmitrij Pochepko, and it's needed for his tests 
> JMX tests for SegmentedCodeCache[1]. so I think he can enlighten us 
> about connection.
>
> Dima,
> could you please explain connection between beans and allocateCodeBlob?
>
> [1] 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016336.html
>
> Thanks,
> Igor
>
> On 12/08/2014 05:09 AM, David Holmes wrote:
>> On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote:
>>> Hi all,
>>>
>>> please review this new small patch
>>>
>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
>>> webrev:
>>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/
>>>
>>> Problem:
>>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>>> WhiteBox::allocateCodeBlob(int, int) exist.
>>>
>>> I change previous fix to this new patch because this conversation [*]
>>>
>>> Solution:
>>>    public long allocateCodeBlob(long size, int type) {
>>>        return allocateCodeBlob((int) size, type);
>>>    }
>>
>> I still think this is a bad idea. The callsite needs to know, and show,
>> that the size it is passing will be truncated. And I still don't see a
>> connection between MX bean memory sizes and allocateCodeBlob.
>>
>> David
>>
>>
>>> Test: jprt
>>>
>>> [*]
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html 
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Tatiana


From christian.thalinger at oracle.com  Mon Dec  8 18:12:20 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 8 Dec 2014 10:12:20 -0800
Subject: Assertion failed: int pressure is incorrect
In-Reply-To: <5485A05F.9020701@redhat.com>
References: <5485A05F.9020701@redhat.com>
Message-ID: <C9F35C42-0512-4E0D-B769-4554D22D43CA@oracle.com>

[Sending to hotspot-compiler-dev; bcc?ing hotspot-dev.]

> On Dec 8, 2014, at 4:58 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> I'm occasionally seeing this:
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/scratch1/large-codecache/hotspot/src/share/vm/opto/ifg.cpp:693), pid=9212, tid=4395909313024
> #  assert(int_pressure.current_pressure() == count_int_pressure(liveout)) failed: the int pressure is incorrect
> #
> 
> Does anyone know what might cause this?  Perhaps a bug in my back
> end?  If not, can I please have some advice about how to debug it?
> 
> I'm only seeing this with a fairly recent cut of JDK9.
> 
> Thanks,
> Andrew,


From david.holmes at oracle.com  Tue Dec  9 01:10:12 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Dec 2014 11:10:12 +1000
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <5485DA7E.5000906@oracle.com>
References: <5485D68C.7040106@oracle.com> <5485DA7E.5000906@oracle.com>
Message-ID: <54864BF4.3020302@oracle.com>

On 9/12/2014 3:06 AM, Vladimir Kozlov wrote:
> The webrev is wrong, should be
>
> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.03/
>
> which looks good.

Agreed.

Thanks for your patience everyone.

David

> Thanks,
> Vladimir
>
> On 12/8/14 8:49 AM, Tatiana Pivovarova wrote:
>> Hi all,
>>
>> please review this new patch
>>
>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
>> webrev:
>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/
>>
>> Problem:
>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>> WhiteBox::allocateCodeBlob(int, int) exist.
>>
>> Solution:
>> Add new function with check:
>>
>>   156   public        long    allocateCodeBlob(long size, int type) {
>>   157       int intSize = (int) size;
>>   158       if ((long) intSize != size || size < 0) {
>>   159           throw new IllegalArgumentException(
>>   160                 "size argument has illegal value " + size);
>>   161       }
>>   162       return allocateCodeBlob( intSize, type);
>>   163   }
>>
>>
>> Test: jprt
>>
>>
>> Thanks,
>> Tatiana

From david.holmes at oracle.com  Tue Dec  9 05:39:14 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Dec 2014 15:39:14 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>
References: <542C8274.3010809@gmail.com>	<54338B70.9080709@oracle.com>	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>	<543B1FD6.3000200@oracle.com>	<543CF553.80601@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>	<547D891D.7010809@oracle.com>	<547DCCFB.3050209@gmail.com>	<54854475.20800@oracle.com>
	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>
Message-ID: <54868B02.1070408@oracle.com>

Hi Thomas,

On 8/12/2014 8:27 PM, Thomas St?fe wrote:
> Hi,
>
> I do not really like the handling of the leading pipe symbol:

To be fair to Yasumasa this aspect of the fix has been the same since 
Oct 15:

http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/

and was not flagged.

> So, we read the core_pattern, and if the pipe symbol is detected, we
> write the core pattern minus the pipe symbol but plus a leading quote to
> the output; the leading quote then serves as a info to the layer above
> in os_posix.cpp to treat this case specially. This means the logic
> spills out of the platform dependend os_linux.cpp to shared code and
> this is also difficult to read.
>
> This comes from the fact that "get_core_path()" assumes the core file is
> written to the file system. I think it just does not fit anymore, better
> would be to replace it with something like
> "os::print_core_file_location(outputStream* os)", and the OS handles
> both core path retrieval and the printing. Because then the shared code
> does not need to know whether core file gets printed traditionally or
> piped to a executable or whatever.

This sounds like a refactoring that I suggested would be too disruptive.

http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015547.html

http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015557.html

http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015573.html


David
-----

> Kind regards, Thomas
>
>
> On Mon, Dec 8, 2014 at 7:25 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Yasumasa,
>
>     I'm okay with these changes. Just a minor style nit (no need for
>     updated webrev) can you remove the blank lines in os_linux.cpp:
>
>     6011       }
>     6012
>     6013     }
>     6014
>     6015   }
>
>     6057       }
>     6058
>     6059     }
>     6060
>     6061   }
>
>     If anyone has any objections please raise them asap.
>
>     Thanks,
>     David
>
>
>     On 3/12/2014 12:30 AM, Yasumasa Suenaga wrote:
>
>         Hi David, Thomas,
>
>         I've uploaded new webrev:
>         http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__04/
>         <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.04/>
>
>                      I want to rewrite a patch as below:
>
>                        - Use async signal safety functions.
>                          fopen -> open, fgets -> read, etc.
>
>
>             This is commendable if it is practical, but error reporting
>             already
>             does many, many things that are not async-signal safe, so
>             there is no
>             need to go to extreme measures here.
>
>
>         I've used async-signal safe functions as possible.
>
>
>                        - Use O_BUFLEN for buffer size.
>                          O_BUFLEN is defined to 2000 in ostream.hpp .
>                          This macro is used in various points.
>                 VMError::coredump_message is
>                          also defined with this value.
>
>
>                 I think PATH_MAX is fine. I think O_BUFLEN was
>                 originally used as a max.
>                 length of temporary buffers to assemble an output line.
>                 And then it
>                 spread a bit. But your intend is to hold a path and
>                 using PATH_MAX
>                 clearly documents this.
>
>
>         I've used PATH_MAX again.
>
>
>                 And, to really nitpick, right now you do not handle
>                 ERANGE with
>                 get_current_path() (if the provided buffer is too
>                 small), which is
>                 probably fine because it is improbable that a path is
>                 larger than
>                 PATH_MAX. But if you change the size of the buffer to
>                 something which
>                 may be smaller than PATH_MAX (O_BUFLEN),
>                 get_current_directory() may
>                 fail.
>
>
>         If get_current_path() call is failed in get_core_path(),
>         get_core_path()
>         returns immediately with 0.
>         Caller (check_or_create_dump()) handles this result as illegal
>         state.
>
>         get_current_path() calls getcwd() only and redirects result to
>         caller.
>         So result of this function is NULL, we can judge getcwd() was
>         finished with
>         error.
>         I think it is enough.
>
>
>                 I like your patch, I think it could be a nice time safer
>                 when
>                 core_pattern is something unusual. But I also see
>                 Staffans point of
>                 too-much-complexity. So I will keep out of this
>                 discussion until the
>                 real Reviewers decided what to do :)
>
>
>             I have a hard time evaluating the merits of the patch as I
>             don't work
>             in an environment where this extra info is needed. But I
>             take it on
>             good faith that it is useful for the context Yasumasa describes.
>
>
>         I want to suggest to Java user where coredump is.
>         Modern Linux distribution(s) contains ABRT.
>         OS can dump corefile automatically despite a lack of setting
>         coredump
>         resource by user.
>
>         I'm support engineer of Java. My customer says "coredump does
>         not found.",
>         but coredump is saved by ABRT.
>         Thus I want them to know "coredump is available" through stderr and
>         hs_err immediately.
>         I belive it is first step of troubleshoot.
>
>
>         Thanks,
>
>         Yasumasa
>
>
>         (2014/12/02 18:40), David Holmes wrote:
>
>             On 1/12/2014 10:57 PM, Thomas St?fe wrote:
>
>                 Hi Yasumasa,
>
>                 On Mon, Dec 1, 2014 at 10:45 AM, Yasumasa Suenaga
>                 <yasuenag at gmail.com <mailto:yasuenag at gmail.com>
>                 <mailto:yasuenag at gmail.com <mailto:yasuenag at gmail.com>>>
>                 wrote:
>
>                      Hi Thomas, David,
>
>                      Sorry, I didn't think about async signal safety.
>
>                          That would work, VmError::report_and_die() is
>                 singlethreaded. At
>                          least the part which dumps out the core file name.
>
>
>                      I think that signal handler (in this case) may run
>                 concurrency with
>                      other thread.
>                      If another thread calls malloc(3) in JNI, C Heap
>                 corruption may
>                 occur.
>
>
>                 No, malloc(3) should be thread safe on our platforms.
>                 But this was not
>                 the point. If I understood David right, he suggested
>                 using a static
>                 buffer inside get_core_path() for assembling the core
>                 path, which would
>                 make get_core_path() thread-unsafe (multiple threads
>                 calling it would
>                 get garbled results). But as get_core_path() is only
>                 called from within
>                 VmError::report_and_die() and that section is only ever
>                 executed by one
>                 thread, Davids suggestion would still work.
>
>
>             Yes that is what I was suggesting.
>
>                      I want to rewrite a patch as below:
>
>                        - Use async signal safety functions.
>                          fopen -> open, fgets -> read, etc.
>
>
>             This is commendable if it is practical, but error reporting
>             already
>             does many, many things that are not async-signal safe, so
>             there is no
>             need to go to extreme measures here.
>
>                        - Use O_BUFLEN for buffer size.
>                          O_BUFLEN is defined to 2000 in ostream.hpp .
>                          This macro is used in various points.
>                 VMError::coredump_message is
>                          also defined with this value.
>
>
>                 I think PATH_MAX is fine. I think O_BUFLEN was
>                 originally used as a max.
>                 length of temporary buffers to assemble an output line.
>                 And then it
>                 spread a bit. But your intend is to hold a path and
>                 using PATH_MAX
>                 clearly documents this.
>                 And, to really nitpick, right now you do not handle
>                 ERANGE with
>                 get_current_path() (if the provided buffer is too
>                 small), which is
>                 probably fine because it is improbable that a path is
>                 larger than
>                 PATH_MAX. But if you change the size of the buffer to
>                 something which
>                 may be smaller than PATH_MAX (O_BUFLEN),
>                 get_current_directory() may
>                 fail.
>
>                 I like your patch, I think it could be a nice time safer
>                 when
>                 core_pattern is something unusual. But I also see
>                 Staffans point of
>                 too-much-complexity. So I will keep out of this
>                 discussion until the
>                 real Reviewers decided what to do :)
>
>
>             I have a hard time evaluating the merits of the patch as I
>             don't work
>             in an environment where this extra info is needed. But I
>             take it on
>             good faith that it is useful for the context Yasumasa describes.
>
>             David
>
>                 Kind Regards, Thomas
>
>

From thomas.stuefe at gmail.com  Tue Dec  9 08:09:15 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 9 Dec 2014 09:09:15 +0100
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <54868B02.1070408@oracle.com>
References: <542C8274.3010809@gmail.com> <54338B70.9080709@oracle.com>
	<CAGFVN2DjxGLomf6dzS5BVqnSKf-43XdEt897T7s0cV71C78r-Q@mail.gmail.com>
	<543B1FD6.3000200@oracle.com> <543CF553.80601@gmail.com>
	<543DC2BF.9050407@oracle.com> <543E80F8.3080204@gmail.com>
	<547330E5.1050708@gmail.com>
	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>
	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com> <547C079A.9020604@oracle.com>
	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
	<547C1815.6050900@oracle.com>
	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>
	<547C38AD.6050703@gmail.com>
	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
	<547D891D.7010809@oracle.com> <547DCCFB.3050209@gmail.com>
	<54854475.20800@oracle.com>
	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>
	<54868B02.1070408@oracle.com>
Message-ID: <CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>

Hi David,

On Tue, Dec 9, 2014 at 6:39 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>
>> Hi,
>>
>> I do not really like the handling of the leading pipe symbol:
>>
>
> To be fair to Yasumasa this aspect of the fix has been the same since Oct
> 15:
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/
>
> and was not flagged.


You are right, I did not read those mails close enough.


>
>
>  So, we read the core_pattern, and if the pipe symbol is detected, we
>> write the core pattern minus the pipe symbol but plus a leading quote to
>> the output; the leading quote then serves as a info to the layer above
>> in os_posix.cpp to treat this case specially. This means the logic
>> spills out of the platform dependend os_linux.cpp to shared code and
>> this is also difficult to read.
>>
>> This comes from the fact that "get_core_path()" assumes the core file is
>> written to the file system. I think it just does not fit anymore, better
>> would be to replace it with something like
>> "os::print_core_file_location(outputStream* os)", and the OS handles
>> both core path retrieval and the printing. Because then the shared code
>> does not need to know whether core file gets printed traditionally or
>> piped to a executable or whatever.
>>
>
> This sounds like a refactoring that I suggested would be too disruptive.
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-
> October/015547.html
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-
> October/015557.html
>
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-
> October/015573.html
>
>
I do not think that this would be such a big a change, but it also could be
done with another patch.

Apart from my reservations I stated above the code looks fine and is
definitly an improvement (just last week I was helplessly looking for a
core on a machine where core_pattern turned out to be a redirection to
another program).

Kind Regards, Thomas


> David

From david.holmes at oracle.com  Tue Dec  9 08:56:50 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Dec 2014 18:56:50 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>
References: <542C8274.3010809@gmail.com>	<543B1FD6.3000200@oracle.com>	<543CF553.80601@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>	<547D891D.7010809@oracle.com>	<547DCCFB.3050209@gmail.com>	<54854475.20800@oracle.com>	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>	<54868B02.1070408@oracle.com>
	<CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>
Message-ID: <5486B952.4070708@oracle.com>

Hi Thomas,

So can we take this as-is for now and file a RFE to address your concerns?

Anybody else object to that?

Thanks,
David

On 9/12/2014 6:09 PM, Thomas St?fe wrote:
> Hi David,
>
> On Tue, Dec 9, 2014 at 6:39 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>
>         Hi,
>
>         I do not really like the handling of the leading pipe symbol:
>
>
>     To be fair to Yasumasa this aspect of the fix has been the same
>     since Oct 15:
>
>     http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/
>     <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/>
>
>     and was not flagged.
>
>
> You are right, I did not read those mails close enough.
>
>
>
>         So, we read the core_pattern, and if the pipe symbol is detected, we
>         write the core pattern minus the pipe symbol but plus a leading
>         quote to
>         the output; the leading quote then serves as a info to the layer
>         above
>         in os_posix.cpp to treat this case specially. This means the logic
>         spills out of the platform dependend os_linux.cpp to shared code and
>         this is also difficult to read.
>
>         This comes from the fact that "get_core_path()" assumes the core
>         file is
>         written to the file system. I think it just does not fit
>         anymore, better
>         would be to replace it with something like
>         "os::print_core_file_location(__outputStream* os)", and the OS
>         handles
>         both core path retrieval and the printing. Because then the
>         shared code
>         does not need to know whether core file gets printed
>         traditionally or
>         piped to a executable or whatever.
>
>
>     This sounds like a refactoring that I suggested would be too disruptive.
>
>     http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html
>     <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015547.html>
>
>     http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html
>     <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015557.html>
>
>     http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html
>     <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015573.html>
>
>
> I do not think that this would be such a big a change, but it also could
> be done with another patch.
>
> Apart from my reservations I stated above the code looks fine and is
> definitly an improvement (just last week I was helplessly looking for a
> core on a machine where core_pattern turned out to be a redirection to
> another program).
>
> Kind Regards, Thomas
>
>
>     David
>

From igor.ignatyev at oracle.com  Tue Dec  9 09:34:13 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Dec 2014 12:34:13 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
Message-ID: <5486C215.2090206@oracle.com>

Staffan, by 'porting our existing tests' I didn't mean porting existing 
tests for codecache. I meant all other tests, including svc, gc, rt 
tests. many of them have iteration count as a parameter, so having a 
common way to set/get it looks needful from my point of view.

On 12/08/2014 09:59 AM, Staffan Larsen wrote:
> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>
> /Staffan
>
>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>> Hi Staffan,
>>
>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>
>> Thanks
>> Igor
>>
>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>> perhaps he has future plans for this.
>>> Igor?
>>>
>>> Thanks,
>>> Dmitrij
>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>> outside these specific tests? Should it really be part of the test
>>>> library?
>>>>
>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>
>>>>> Adding hotspot-dev for wider audience.
>>>>>> Hi,
>>>>>>
>>>>>> Please review changes for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>> Test task: JMX- tests
>>>>>> and
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>> in testlibrary for JDK-8059613
>>>>>>
>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>> testing thresholds, usage,
>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>> tests.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>
>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>
>>>>>> Additional note: this patch assumes
>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>> is fixed.
>>>>>>
>>>>>> Thanks,
>>>>>> Dmitrij
>>>
>

-- 
Igor

From tobias.hartmann at oracle.com  Tue Dec  9 09:51:40 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 09 Dec 2014 10:51:40 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com>,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>
	<20141208111859.936395@eggemoggin.niobe.net>
	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
Message-ID: <5486C62C.2040906@oracle.com>

Hi,

thanks for the feedback.

On 08.12.2014 20:46, Staffan Larsen wrote:
> 
>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote:
>>
>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com:
>>> ...
>>>
>>> This would also be a good place to discuss the structure of the test 
>>> library.
>>
>> Yes.  The various "testlibrary" directories in different repos are, at
>> the moment, a bit of a mess and in some cases appear to be redundant.
>>
>> For the present root-repo proposal:
>>
>>  - Why is it named test/testlibrary rather than test/lib, which is
>>    what's used in the jdk repo?
> 
> Probably because it?s called test/testlibrary in the hotspot repo :-)

Yes, do you prefer 'test/lib'?

> 
>>  - Why does the white-box library get its own directory?  Shouldn't
>>    all test-library classes have the same package root?
> 
> +1

I agree. I'll remove the whitebox directory.

> 
>>  - The package name "sun.hotspot" is archaic.  We should figure out a
>>    proper naming scheme for test-library packages, preferably starting
>>    with "jdk.?.
> 
> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?

Whatever you prefer.

Thanks,
Tobias

> 
>>
>>> ...
>>>
>>> Based on the discussion around microbenchmarks, it may make sense to
>>> break out the test folder to a separate repo if it starts growing.
>>> But again, perhaps this is something we can wait for and handle in the
>>> RFE. The test folder already exists in the top repo.
>>
>> The jdk/test/lib directory has been around for many years now and only
>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>> ever be much larger than that, so a separate repo would be overkill.
> 
> The corresponding directory in hotspot has 56 files and has expanded quite a bit recently. I expect some growth to continue. Many of these overlap with the files in the jdk directory, however.
> 
> /Staffan
> 

From stefan.sarne at oracle.com  Tue Dec  9 09:56:11 2014
From: stefan.sarne at oracle.com (Stefan Sarne)
Date: Tue, 09 Dec 2014 10:56:11 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <5486C62C.2040906@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com>,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>
	<20141208111859.936395@eggemoggin.niobe.net>
	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
	<5486C62C.2040906@oracle.com>
Message-ID: <5486C73B.5080206@oracle.com>


Hi,

On 2014-12-09 10:51, Tobias Hartmann wrote:
> Hi,
>
> thanks for the feedback.
>
> On 08.12.2014 20:46, Staffan Larsen wrote:
>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote:
>>>
>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com:
>>>> ...
>>>>
>>>> This would also be a good place to discuss the structure of the test
>>>> library.
>>> Yes.  The various "testlibrary" directories in different repos are, at
>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>
>>> For the present root-repo proposal:
>>>
>>>   - Why is it named test/testlibrary rather than test/lib, which is
>>>     what's used in the jdk repo?
>> Probably because it?s called test/testlibrary in the hotspot repo :-)
> Yes, do you prefer 'test/lib'?

Now sounds like a good time to align.   :)
We can update testlibrary in hotspot to the same as well I think (as a 
second step).
Let's go with test/lib.

>
>>>   - Why does the white-box library get its own directory?  Shouldn't
>>>     all test-library classes have the same package root?
>> +1
> I agree. I'll remove the whitebox directory.

Sounds good, the same package root is better.

>
>>>   - The package name "sun.hotspot" is archaic.  We should figure out a
>>>     proper naming scheme for test-library packages, preferably starting
>>>     with "jdk.?.
>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
> Whatever you prefer.

If we go with test/lib - I think jdk.testlib make sense.

Thanks
Stefan

>
> Thanks,
> Tobias
>
>>>> ...
>>>>
>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>> break out the test folder to a separate repo if it starts growing.
>>>> But again, perhaps this is something we can wait for and handle in the
>>>> RFE. The test folder already exists in the top repo.
>>> The jdk/test/lib directory has been around for many years now and only
>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>> ever be much larger than that, so a separate repo would be overkill.
>> The corresponding directory in hotspot has 56 files and has expanded quite a bit recently. I expect some growth to continue. Many of these overlap with the files in the jdk directory, however.
>>
>> /Staffan
>>


From staffan.larsen at oracle.com  Tue Dec  9 09:59:30 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 9 Dec 2014 10:59:30 +0100
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <5486C215.2090206@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
Message-ID: <F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>

But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?

/Staffan


> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
> 
> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>> 
>> /Staffan
>> 
>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>> 
>>> Hi Staffan,
>>> 
>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>> 
>>> Thanks
>>> Igor
>>> 
>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>> perhaps he has future plans for this.
>>>> Igor?
>>>> 
>>>> Thanks,
>>>> Dmitrij
>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>> outside these specific tests? Should it really be part of the test
>>>>> library?
>>>>> 
>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>> 
>>>>>> Adding hotspot-dev for wider audience.
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Please review changes for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>> Test task: JMX- tests
>>>>>>> and
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>> in testlibrary for JDK-8059613
>>>>>>> 
>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>> testing thresholds, usage,
>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>> tests.
>>>>>>> 
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>> 
>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>> 
>>>>>>> Additional note: this patch assumes
>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>> is fixed.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Dmitrij
>>>> 
>> 
> 
> -- 
> Igor


From staffan.larsen at oracle.com  Tue Dec  9 10:00:12 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 9 Dec 2014 11:00:12 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <5486C73B.5080206@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>>>
	<20141208111859.936395@eggemoggin.niobe.net>
	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
	<5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com>
Message-ID: <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>

+1

> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com> wrote:
> 
> 
> Hi,
> 
> On 2014-12-09 10:51, Tobias Hartmann wrote:
>> Hi,
>> 
>> thanks for the feedback.
>> 
>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote:
>>>> 
>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com:
>>>>> ...
>>>>> 
>>>>> This would also be a good place to discuss the structure of the test
>>>>> library.
>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>> 
>>>> For the present root-repo proposal:
>>>> 
>>>>  - Why is it named test/testlibrary rather than test/lib, which is
>>>>    what's used in the jdk repo?
>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>> Yes, do you prefer 'test/lib'?
> 
> Now sounds like a good time to align.   :)
> We can update testlibrary in hotspot to the same as well I think (as a second step).
> Let's go with test/lib.
> 
>> 
>>>>  - Why does the white-box library get its own directory?  Shouldn't
>>>>    all test-library classes have the same package root?
>>> +1
>> I agree. I'll remove the whitebox directory.
> 
> Sounds good, the same package root is better.
> 
>> 
>>>>  - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>    proper naming scheme for test-library packages, preferably starting
>>>>    with "jdk.?.
>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>> Whatever you prefer.
> 
> If we go with test/lib - I think jdk.testlib make sense.
> 
> Thanks
> Stefan
> 
>> 
>> Thanks,
>> Tobias
>> 
>>>>> ...
>>>>> 
>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>> break out the test folder to a separate repo if it starts growing.
>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>> RFE. The test folder already exists in the top repo.
>>>> The jdk/test/lib directory has been around for many years now and only
>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>> ever be much larger than that, so a separate repo would be overkill.
>>> The corresponding directory in hotspot has 56 files and has expanded quite a bit recently. I expect some growth to continue. Many of these overlap with the files in the jdk directory, however.
>>> 
>>> /Staffan


From Alan.Bateman at oracle.com  Tue Dec  9 10:08:11 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 09 Dec 2014 10:08:11 +0000
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <54856A31.9020702@oracle.com>
References: <547DCF47.9000608@oracle.com>
	<547DF563.8080509@oracle.com>	<547DF8D8.8080601@oracle.com>	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>	<547E190F.1090407@oracle.com>
	<54800E21.2050700@oracle.com>	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>	<54855234.3050400@oracle.com>	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>
	<54856A31.9020702@oracle.com>
Message-ID: <5486CA0B.4010501@oracle.com>

On 08/12/2014 09:06, Tobias Hartmann wrote:
> CC'ing to jdk9-dev for wider audience.
>
> Summary:
> The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests [2] need
> access to the Whitebox API testlibrary that is part of the hotspot repository.
>
> We therefore propose to move the Whitebox API from the hotspot repository to the
> top level repository (test/testlibrary/) in the following steps:
>
> 1) Copy testlibrary to top level repository
> 2) Adapt existing hotspot tests (> 200 tests)
> 3) Remove testlibrary from hotspot repository
>
> First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
>
> Thanks,
> Tobias
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8066625
> [2] https://bugs.openjdk.java.net/browse/JDK-8064875
>
Maybe this has been discussed previously but how do test libraries in 
the top-level repo work for test roots that are in the hotspot and jdk 
repos? Is there jtreg support for this or are you proposing @library 
../../../../../ ? I realize this might be a question for future steps 
but still useful to know where this is going.

-Alan

From igor.ignatyev at oracle.com  Tue Dec  9 10:11:08 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Dec 2014 13:11:08 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
Message-ID: <5486CABC.9090107@oracle.com>

I treat 'iteration count' as 'the number of times the test should be 
run', where by the test implies the main loop of the test. I don't 
insist that it has to be called 'ITERATION_COUNT'. if you have better 
name for this, let's use it.

another application of such a parameter is limitation of test cases 
count in the tests which iterate over set of generated test cases.

also we have tests which run several times to get an averaged value for 
some indicator (elapsed time. used memory, etc)

for all of these cases, I'd like to use one variable.

Thanks,
Igor

On 12/09/2014 12:59 PM, Staffan Larsen wrote:
> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>
> /Staffan
>
>
>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>
>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>
>>> /Staffan
>>>
>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>
>>>> Hi Staffan,
>>>>
>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>
>>>> Thanks
>>>> Igor
>>>>
>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>> perhaps he has future plans for this.
>>>>> Igor?
>>>>>
>>>>> Thanks,
>>>>> Dmitrij
>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>> outside these specific tests? Should it really be part of the test
>>>>>> library?
>>>>>>
>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>
>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review changes for
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>> Test task: JMX- tests
>>>>>>>> and
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>
>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>> testing thresholds, usage,
>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>> tests.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>
>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>
>>>>>>>> Additional note: this patch assumes
>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>> is fixed.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Dmitrij
>>>>>
>>>
>>
>> --
>> Igor
>

-- 
Igor

From staffan.larsen at oracle.com  Tue Dec  9 10:15:05 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 9 Dec 2014 11:15:05 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <5486CA0B.4010501@oracle.com>
References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com>
	<547DF8D8.8080601@oracle.com>
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>
	<547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com>
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>
	<54855234.3050400@oracle.com>
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>
	<54856A31.9020702@oracle.com> <5486CA0B.4010501@oracle.com>
Message-ID: <43F17AFB-5E36-41BF-BB29-429ECEF9D977@oracle.com>


> On 9 dec 2014, at 11:08, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/12/2014 09:06, Tobias Hartmann wrote:
>> CC'ing to jdk9-dev for wider audience.
>> 
>> Summary:
>> The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests [2] need
>> access to the Whitebox API testlibrary that is part of the hotspot repository.
>> 
>> We therefore propose to move the Whitebox API from the hotspot repository to the
>> top level repository (test/testlibrary/) in the following steps:
>> 
>> 1) Copy testlibrary to top level repository
>> 2) Adapt existing hotspot tests (> 200 tests)
>> 3) Remove testlibrary from hotspot repository
>> 
>> First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
>> 
>> Thanks,
>> Tobias
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8066625
>> [2] https://bugs.openjdk.java.net/browse/JDK-8064875
>> 
> Maybe this has been discussed previously but how do test libraries in the top-level repo work for test roots that are in the hotspot and jdk repos? Is there jtreg support for this or are you proposing @library ../../../../../ ? I realize this might be a question for future steps but still useful to know where this is going.

The suggestion is to use "@library /../../test/lib?. Using an initial slash means that the path is relative to TEST.ROOT, not to the test itself. I?m not sure if this was intended in jtreg or if it just happens to work. I?m sure we can think of cleaner approach in the future.

/Staffan


From staffan.larsen at oracle.com  Tue Dec  9 10:20:45 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 9 Dec 2014 11:20:45 +0100
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <5486CABC.9090107@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
	<5486CABC.9090107@oracle.com>
Message-ID: <CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>


> On 9 dec 2014, at 11:11, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
> 
> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
> 
> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
> 
> for all of these cases, I'd like to use one variable.

But these look like three different counters to me? And for some tests all three counter could possibly be needed.

I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. 

/Staffan

> 
> Thanks,
> Igor
> 
> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>> 
>> /Staffan
>> 
>> 
>>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>> 
>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>> 
>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>> 
>>>> /Staffan
>>>> 
>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>> 
>>>>> Hi Staffan,
>>>>> 
>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>> 
>>>>> Thanks
>>>>> Igor
>>>>> 
>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>> perhaps he has future plans for this.
>>>>>> Igor?
>>>>>> 
>>>>>> Thanks,
>>>>>> Dmitrij
>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>> library?
>>>>>>> 
>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>> 
>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Please review changes for
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>> Test task: JMX- tests
>>>>>>>>> and
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>> 
>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>> testing thresholds, usage,
>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>> tests.
>>>>>>>>> 
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>> 
>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>> 
>>>>>>>>> Additional note: this patch assumes
>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>> is fixed.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Dmitrij
>>>>>> 
>>>> 
>>> 
>>> --
>>> Igor
>> 
> 
> -- 
> Igor


From igor.ignatyev at oracle.com  Tue Dec  9 10:36:35 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Dec 2014 13:36:35 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
	<5486CABC.9090107@oracle.com>
	<CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>
Message-ID: <5486D0B3.5060209@oracle.com>

On 12/09/2014 01:20 PM, Staffan Larsen wrote:
>
>> On 9 dec 2014, at 11:11, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
>>
>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
>>
>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
>>
>> for all of these cases, I'd like to use one variable.
>
> But these look like three different counters to me? And for some tests all three counter could possibly be needed.
>
> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests.
well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having 
it in common lib?

// on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which 
turns the tests from 'limited time' mode to 'cover all combinations' one.

-- Igor
>
> /Staffan
>
>>
>> Thanks,
>> Igor
>>
>> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>>>
>>> /Staffan
>>>
>>>
>>>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>
>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>>>
>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>>>
>>>>> /Staffan
>>>>>
>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>
>>>>>> Hi Staffan,
>>>>>>
>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>>>
>>>>>> Thanks
>>>>>> Igor
>>>>>>
>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>>> perhaps he has future plans for this.
>>>>>>> Igor?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dmitrij
>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>>> library?
>>>>>>>>
>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>>>
>>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please review changes for
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>>> Test task: JMX- tests
>>>>>>>>>> and
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>>>
>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>>> testing thresholds, usage,
>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>>> tests.
>>>>>>>>>>
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>>>
>>>>>>>>>> Additional note: this patch assumes
>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>>> is fixed.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Dmitrij
>>>>>>>
>>>>>
>>>>
>>>> --
>>>> Igor
>>>
>>
>> --
>> Igor
>

From tatiana.pivovarova at oracle.com  Tue Dec  9 11:15:31 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Tue, 09 Dec 2014 14:15:31 +0300
Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int)
	method to be implemented
In-Reply-To: <54864BF4.3020302@oracle.com>
References: <5485D68C.7040106@oracle.com> <5485DA7E.5000906@oracle.com>
	<54864BF4.3020302@oracle.com>
Message-ID: <5486D9D3.8070103@oracle.com>

Hi Vladimir, David

Thank you very much for your careful review and valuable notes!

Tatiana

On 12/09/2014 04:10 AM, David Holmes wrote:
> On 9/12/2014 3:06 AM, Vladimir Kozlov wrote:
>> The webrev is wrong, should be
>>
>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.03/
>>
>> which looks good.
>
> Agreed.
>
> Thanks for your patience everyone.
>
> David
>
>> Thanks,
>> Vladimir
>>
>> On 12/8/14 8:49 AM, Tatiana Pivovarova wrote:
>>> Hi all,
>>>
>>> please review this new patch
>>>
>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134
>>> webrev:
>>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/
>>>
>>> Problem:
>>> Need WhiteBox::allocateCodeBlob(long, int), currently only
>>> WhiteBox::allocateCodeBlob(int, int) exist.
>>>
>>> Solution:
>>> Add new function with check:
>>>
>>>   156   public        long    allocateCodeBlob(long size, int type) {
>>>   157       int intSize = (int) size;
>>>   158       if ((long) intSize != size || size < 0) {
>>>   159           throw new IllegalArgumentException(
>>>   160                 "size argument has illegal value " + size);
>>>   161       }
>>>   162       return allocateCodeBlob( intSize, type);
>>>   163   }
>>>
>>>
>>> Test: jprt
>>>
>>>
>>> Thanks,
>>> Tatiana


From roland.westrelin at oracle.com  Tue Dec  9 11:49:50 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Dec 2014 12:49:50 +0100
Subject: [8u] backport of 8048170: Test
	closed/java/text/Normalizer/ConformanceTest.java failed
Message-ID: <79A63124-352F-4611-9856-7C2F65C6415B@oracle.com>

8u backport request. 8048170 was pushed to jdk9 last week and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u.

https://bugs.openjdk.java.net/browse/JDK-8048170
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e78fa38ad3a3

Roland.



From thomas.stuefe at gmail.com  Tue Dec  9 12:06:53 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 9 Dec 2014 13:06:53 +0100
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <5486B952.4070708@oracle.com>
References: <542C8274.3010809@gmail.com> <543B1FD6.3000200@oracle.com>
	<543CF553.80601@gmail.com> <543DC2BF.9050407@oracle.com>
	<543E80F8.3080204@gmail.com> <547330E5.1050708@gmail.com>
	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>
	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com> <547C079A.9020604@oracle.com>
	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
	<547C1815.6050900@oracle.com>
	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>
	<547C38AD.6050703@gmail.com>
	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
	<547D891D.7010809@oracle.com> <547DCCFB.3050209@gmail.com>
	<54854475.20800@oracle.com>
	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>
	<54868B02.1070408@oracle.com>
	<CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>
	<5486B952.4070708@oracle.com>
Message-ID: <CAA-vtUyRtwD+08BjZSZY_q5uHGnb8kmW7AZD2TSe=_0h6rgT_A@mail.gmail.com>

Yes, Sure :-) @Yasumasa : thank you for this patch!

Kind regards, Thomas
On Dec 9, 2014 9:56 AM, "David Holmes" <david.holmes at oracle.com> wrote:

> Hi Thomas,
>
> So can we take this as-is for now and file a RFE to address your concerns?
>
> Anybody else object to that?
>
> Thanks,
> David
>
> On 9/12/2014 6:09 PM, Thomas St?fe wrote:
>
>> Hi David,
>>
>> On Tue, Dec 9, 2014 at 6:39 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Thomas,
>>
>>     On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>>
>>         Hi,
>>
>>         I do not really like the handling of the leading pipe symbol:
>>
>>
>>     To be fair to Yasumasa this aspect of the fix has been the same
>>     since Oct 15:
>>
>>     http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/
>>     <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/>
>>
>>     and was not flagged.
>>
>>
>> You are right, I did not read those mails close enough.
>>
>>
>>
>>         So, we read the core_pattern, and if the pipe symbol is detected,
>> we
>>         write the core pattern minus the pipe symbol but plus a leading
>>         quote to
>>         the output; the leading quote then serves as a info to the layer
>>         above
>>         in os_posix.cpp to treat this case specially. This means the logic
>>         spills out of the platform dependend os_linux.cpp to shared code
>> and
>>         this is also difficult to read.
>>
>>         This comes from the fact that "get_core_path()" assumes the core
>>         file is
>>         written to the file system. I think it just does not fit
>>         anymore, better
>>         would be to replace it with something like
>>         "os::print_core_file_location(__outputStream* os)", and the OS
>>         handles
>>         both core path retrieval and the printing. Because then the
>>         shared code
>>         does not need to know whether core file gets printed
>>         traditionally or
>>         piped to a executable or whatever.
>>
>>
>>     This sounds like a refactoring that I suggested would be too
>> disruptive.
>>
>>     http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__
>> October/015547.html
>>     <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-
>> October/015547.html>
>>
>>     http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__
>> October/015557.html
>>     <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-
>> October/015557.html>
>>
>>     http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__
>> October/015573.html
>>     <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-
>> October/015573.html>
>>
>>
>> I do not think that this would be such a big a change, but it also could
>> be done with another patch.
>>
>> Apart from my reservations I stated above the code looks fine and is
>> definitly an improvement (just last week I was helplessly looking for a
>> core on a machine where core_pattern turned out to be a redirection to
>> another program).
>>
>> Kind Regards, Thomas
>>
>>
>>     David
>>
>>

From staffan.larsen at oracle.com  Tue Dec  9 12:22:07 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 9 Dec 2014 13:22:07 +0100
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <5486D0B3.5060209@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
	<5486CABC.9090107@oracle.com>
	<CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>
	<5486D0B3.5060209@oracle.com>
Message-ID: <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com>

I would favor a solution where the iteration count is an argument to the test instead of being a global variable.

/Staffan

> On 9 dec 2014, at 11:36, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> On 12/09/2014 01:20 PM, Staffan Larsen wrote:
>> 
>>> On 9 dec 2014, at 11:11, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>> 
>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
>>> 
>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
>>> 
>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
>>> 
>>> for all of these cases, I'd like to use one variable.
>> 
>> But these look like three different counters to me? And for some tests all three counter could possibly be needed.
>> 
>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests.
> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib?
> 
> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one.
> 
> -- Igor
>> 
>> /Staffan
>> 
>>> 
>>> Thanks,
>>> Igor
>>> 
>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>>>> 
>>>> /Staffan
>>>> 
>>>> 
>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>> 
>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>>>> 
>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>>>> 
>>>>>> /Staffan
>>>>>> 
>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Staffan,
>>>>>>> 
>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Igor
>>>>>>> 
>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>>>> perhaps he has future plans for this.
>>>>>>>> Igor?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Dmitrij
>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>>>> library?
>>>>>>>>> 
>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>>>> 
>>>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> Please review changes for
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>>>> Test task: JMX- tests
>>>>>>>>>>> and
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>>>> 
>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>>>> testing thresholds, usage,
>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>>>> tests.
>>>>>>>>>>> 
>>>>>>>>>>> Webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>>>> 
>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>>>> 
>>>>>>>>>>> Additional note: this patch assumes
>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>>>> is fixed.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dmitrij
>>>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> Igor
>>>> 
>>> 
>>> --
>>> Igor
>> 


From igor.ignatyev at oracle.com  Tue Dec  9 12:51:09 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Dec 2014 15:51:09 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
	<5486CABC.9090107@oracle.com>
	<CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>
	<5486D0B3.5060209@oracle.com>
	<0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com>
Message-ID: <5486F03D.6060608@oracle.com>

this solution doesn't allow us to change iteration count for all tests.

Igor

On 12/09/2014 03:22 PM, Staffan Larsen wrote:
> I would favor a solution where the iteration count is an argument to the test instead of being a global variable.
>
> /Staffan
>
>> On 9 dec 2014, at 11:36, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>> On 12/09/2014 01:20 PM, Staffan Larsen wrote:
>>>
>>>> On 9 dec 2014, at 11:11, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>
>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
>>>>
>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
>>>>
>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
>>>>
>>>> for all of these cases, I'd like to use one variable.
>>>
>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed.
>>>
>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests.
>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib?
>>
>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one.
>>
>> -- Igor
>>>
>>> /Staffan
>>>
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>>>>>
>>>>> /Staffan
>>>>>
>>>>>
>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>
>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>>>>>
>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>>>>>
>>>>>>> /Staffan
>>>>>>>
>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Staffan,
>>>>>>>>
>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Igor
>>>>>>>>
>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>>>>> perhaps he has future plans for this.
>>>>>>>>> Igor?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Dmitrij
>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>>>>> library?
>>>>>>>>>>
>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>>>>>
>>>>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review changes for
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>>>>> Test task: JMX- tests
>>>>>>>>>>>> and
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>>>>>
>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>>>>> testing thresholds, usage,
>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>>>>> tests.
>>>>>>>>>>>>
>>>>>>>>>>>> Webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>>>>>
>>>>>>>>>>>> Additional note: this patch assumes
>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>>>>> is fixed.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dmitrij
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Igor
>>>>>
>>>>
>>>> --
>>>> Igor
>>>
>

From yasuenag at gmail.com  Tue Dec  9 13:56:42 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 09 Dec 2014 22:56:42 +0900
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <CAA-vtUyRtwD+08BjZSZY_q5uHGnb8kmW7AZD2TSe=_0h6rgT_A@mail.gmail.com>
References: <542C8274.3010809@gmail.com>	<543DC2BF.9050407@oracle.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>	<547D891D.7010809@oracle.com>	<547DCCFB.3050209@gmail.com>	<54854475.20800@oracle.com>	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>	<54868B02.1070408@oracle.com>	<CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>	<5486B952.4070708@oracle.com>
	<CAA-vtUyRtwD+08BjZSZY_q5uHGnb8kmW7AZD2TSe=_0h6rgT_A@mail.gmail.com>
Message-ID: <5486FF9A.2050604@gmail.com>

David, Thomas,

Thank you so much!
I wait 2nd reviewer.

BTW, I'm not a committer.
So I'm also waiting a sponsor :-)

> I'm okay with these changes. Just a minor style nit (no need for updated webrev) can you remove the blank lines in os_linux.cpp:
>
> 6011       }
> 6012
> 6013     }
> 6014
> 6015   }
>
> 6057       }
> 6058
> 6059     }
> 6060
> 6061   }
>
> If anyone has any objections please raise them asap.

I will upload new webrev which is fix them after reviewing.


Thanks,

Yasumasa


(2014/12/09 21:06), Thomas St?fe wrote:
> Yes, Sure :-) @Yasumasa : thank you for this patch!
>
> Kind regards, Thomas
>
> On Dec 9, 2014 9:56 AM, "David Holmes" <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     So can we take this as-is for now and file a RFE to address your concerns?
>
>     Anybody else object to that?
>
>     Thanks,
>     David
>
>     On 9/12/2014 6:09 PM, Thomas St?fe wrote:
>
>         Hi David,
>
>         On Tue, Dec 9, 2014 at 6:39 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 Thomas,
>
>              On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>
>                  Hi,
>
>                  I do not really like the handling of the leading pipe symbol:
>
>
>              To be fair to Yasumasa this aspect of the fix has been the same
>              since Oct 15:
>
>         http://cr.openjdk.java.net/~____ysuenaga/JDK-8059586/webrev.____02/ <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/>
>              <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/ <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/>>
>
>              and was not flagged.
>
>
>         You are right, I did not read those mails close enough.
>
>
>
>                  So, we read the core_pattern, and if the pipe symbol is detected, we
>                  write the core pattern minus the pipe symbol but plus a leading
>                  quote to
>                  the output; the leading quote then serves as a info to the layer
>                  above
>                  in os_posix.cpp to treat this case specially. This means the logic
>                  spills out of the platform dependend os_linux.cpp to shared code and
>                  this is also difficult to read.
>
>                  This comes from the fact that "get_core_path()" assumes the core
>                  file is
>                  written to the file system. I think it just does not fit
>                  anymore, better
>                  would be to replace it with something like
>                  "os::print_core_file_location(____outputStream* os)", and the OS
>                  handles
>                  both core path retrieval and the printing. Because then the
>                  shared code
>                  does not need to know whether core file gets printed
>                  traditionally or
>                  piped to a executable or whatever.
>
>
>              This sounds like a refactoring that I suggested would be too disruptive.
>
>         http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015547.html <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html>
>              <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015547.html>>
>
>         http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015557.html <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html>
>              <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015557.html>>
>
>         http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015573.html <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html>
>              <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015573.html>>
>
>
>         I do not think that this would be such a big a change, but it also could
>         be done with another patch.
>
>         Apart from my reservations I stated above the code looks fine and is
>         definitly an improvement (just last week I was helplessly looking for a
>         core on a machine where core_pattern turned out to be a redirection to
>         another program).
>
>         Kind Regards, Thomas
>
>
>              David
>

From tobias.hartmann at oracle.com  Tue Dec  9 14:43:01 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 09 Dec 2014 15:43:01 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>>>
	<20141208111859.936395@eggemoggin.niobe.net>
	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
	<5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com>
	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
Message-ID: <54870A75.2000008@oracle.com>

Hi,

I just noticed that if we want to access the Whitebox API in the top level
repository we also have to adapt the native lookup code in
src/share/vm/prims/nativeLookup.cpp because it depends on the package name.

I therefore suggest to move the Whitebox API completely and adapt all tests in
the hotspot repository. Here are the corresponding webrevs:

Top level repo:
http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/

Hotspot repo:
http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/

Tested on JPRT.

Thanks,
Tobias

On 09.12.2014 11:00, Staffan Larsen wrote:
> +1
> 
>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>> <mailto:stefan.sarne at oracle.com>> wrote:
>>
>>
>> Hi,
>>
>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> thanks for the feedback.
>>>
>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>
>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com <mailto:stefan.sarne at oracle.com>:
>>>>>> ...
>>>>>>
>>>>>> This would also be a good place to discuss the structure of the test
>>>>>> library.
>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>
>>>>> For the present root-repo proposal:
>>>>>
>>>>>  - Why is it named test/testlibrary rather than test/lib, which is
>>>>>    what's used in the jdk repo?
>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>> Yes, do you prefer 'test/lib'?
>>
>> Now sounds like a good time to align.   :)
>> We can update testlibrary in hotspot to the same as well I think (as a second
>> step).
>> Let's go with test/lib.
>>
>>>
>>>>>  - Why does the white-box library get its own directory?  Shouldn't
>>>>>    all test-library classes have the same package root?
>>>> +1
>>> I agree. I'll remove the whitebox directory.
>>
>> Sounds good, the same package root is better.
>>
>>>
>>>>>  - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>    proper naming scheme for test-library packages, preferably starting
>>>>>    with "jdk.?.
>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>> Whatever you prefer.
>>
>> If we go with test/lib - I think jdk.testlib make sense.
>>
>> Thanks
>> Stefan
>>
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>>> ...
>>>>>>
>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>> RFE. The test folder already exists in the top repo.
>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>> the files in the jdk directory, however.
>>>>
>>>> /Staffan
> 

From vladimir.kozlov at oracle.com  Tue Dec  9 16:50:20 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Dec 2014 08:50:20 -0800
Subject: [8u] backport of 8048170: Test
	closed/java/text/Normalizer/ConformanceTest.java failed
In-Reply-To: <79A63124-352F-4611-9856-7C2F65C6415B@oracle.com>
References: <79A63124-352F-4611-9856-7C2F65C6415B@oracle.com>
Message-ID: <5487284C.6080002@oracle.com>

Good.

Thanks,
Vladimir

On 12/9/14 3:49 AM, Roland Westrelin wrote:
> 8u backport request. 8048170 was pushed to jdk9 last week and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u.
>
> https://bugs.openjdk.java.net/browse/JDK-8048170
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e78fa38ad3a3
>
> Roland.
>
>

From mark.reinhold at oracle.com  Tue Dec  9 17:09:30 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 09 Dec 2014 09:09:30 -0800
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <5486C73B.5080206@oracle.com>
References: <547DCF47.9000608@oracle.com>, <>, <<547DF563.8080509@oracle.com>,
	<5486C62C.2040906@oracle.com>, <5486C73B.5080206@oracle.com>
Message-ID: <20141209090930.405310@eggemoggin.niobe.net>

2014/12/9 1:56 -0800, stefan.sarne at oracle.com:
> On 2014-12-09 10:51, Tobias Hartmann wrote:
>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote:
>>>> ...
>>>> 
>>>> - Why is it named test/testlibrary rather than test/lib, which is
>>>> what's used in the jdk repo?
>>>
>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>
>> Yes, do you prefer 'test/lib'?
> 
> Now sounds like a good time to align.   :)
> We can update testlibrary in hotspot to the same as well I think (as a 
> second step).
> 
> Let's go with test/lib.

Works for me.

> ...
>>>> - The package name "sun.hotspot" is archaic.  We should figure out a
>>>> proper naming scheme for test-library packages, preferably starting
>>>> with "jdk.?.
>>>
>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>
>> Whatever you prefer.
> 
> If we go with test/lib - I think jdk.testlib make sense.

I suggest jdk.test.lib -- that way the prefix "jdk.test" can be used
in other situations where test code needs a package name.

- Mark

From dmitry.samersoff at oracle.com  Tue Dec  9 17:45:46 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 09 Dec 2014 20:45:46 +0300
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <54857B2E.8020100@oracle.com>
References: <547DCF47.9000608@oracle.com>
	<547DF563.8080509@oracle.com>	<547DF8D8.8080601@oracle.com>	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>	<547E190F.1090407@oracle.com>
	<54800E21.2050700@oracle.com>	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>	<54855234.3050400@oracle.com>	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>	<54856A31.9020702@oracle.com>
	<54857B2E.8020100@oracle.com>
Message-ID: <5487354A.8090201@oracle.com>

Stefan,

Moving tests to separate repo solves countless number of problems,
in a range from testlibrary access/development to better jprt load.

As soon as we have all tests in jtreg format, jdk/test and hotspot/test
become too large. So we have to move these tests to separate repo sooner
or later.

Is it possible to do it now?

-Dmitry

On 2014-12-08 13:19, Stefan S?rne wrote:
> 
> I think this is a good path forward.
> 
> The WhiteBox api is just the next example of test library code which we
> want to use both from the hotspot and the jdk repo. There are other
> classes which exists in both repos, which currently are copies. And just
> as expected with copies - time is spent to keep them in sync and yet
> they are not. Copy vs. share is a trade off but in this case I lean
> towards share, since this has been brought up as an issue at multiple
> times. Other examples are ProcessTools, OutputAnalyzer and friends.
> 
> If we treat the WhiteBox API as a pilot, we should create an RFE that
> follows up for the other utilities.
> This would also be a good place to discuss the structure of the test
> library.
> 
> I don't see a shared test library replacing the local ones - it would
> just a be a complement when the library code is shared.
> 
> If we do setup a shared place for this, we also should have a good way
> to handle changes to it.
> It would be easy to start here - on jdk9-dev, but if it turns out to be
> needed, we could setup a separate list.
> 
> Based on the discussion around microbenchmarks, it may make sense to
> break out the test folder to a separate repo if it starts growing.
> But again, perhaps this is something we can wait for and handle in the
> RFE. The test folder already exists in the top repo.
> 
> Cheers,
> Stefan
> 
> 
> Tobias Hartmann skrev 2014-12-08 10:06:
>> CC'ing to jdk9-dev for wider audience.
>>
>> Summary:
>> The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests
>> [2] need
>> access to the Whitebox API testlibrary that is part of the hotspot
>> repository.
>>
>> We therefore propose to move the Whitebox API from the hotspot
>> repository to the
>> top level repository (test/testlibrary/) in the following steps:
>>
>> 1) Copy testlibrary to top level repository
>> 2) Adapt existing hotspot tests (> 200 tests)
>> 3) Remove testlibrary from hotspot repository
>>
>> First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
>>
>> Thanks,
>> Tobias
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8066625
>> [2] https://bugs.openjdk.java.net/browse/JDK-8064875
>>
>> On 08.12.2014 08:37, Staffan Larsen wrote:
>>> I am for this change in principle, but before we go ahead I think
>>> this warrants a larger discussion on build-dev at ojn or jdk9-dev at ojn.
>>> We need to propose and get acceptance for this from the larger group.
>>>
>>> (I was also surprised to see a Makefile here - who calls that?)
>>>
>>> /Staffan
>>>
>>>> On 8 dec 2014, at 08:24, Tobias Hartmann
>>>> <Tobias.Hartmann at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> As we discussed off-thread I copied the Whitebox API to the top
>>>> level repository
>>>> (test/testlibrary). We will then file a RFE to adopt the hotspot
>>>> tests and
>>>> eventually remove the testlibrary from the hotspot repo.
>>>>
>>>> New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/
>>>>
>>>> Can I get reviews for this?
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> On 04.12.2014 11:29, Staffan Larsen wrote:
>>>>> I don?t know which tests you are planning to write that require
>>>>> this feature, but can the tests be put into the hotspot repo
>>>>> instead of the jdk repo so that we avoid the duplication? It seems
>>>>> like the decision for JDK-8057707 was to not duplicate the code.
>>>>>
>>>>> /Staffan
>>>>>
>>>>>> On 4 dec 2014, at 08:32, Tobias Hartmann
>>>>>> <Tobias.Hartmann at oracle.com> wrote:
>>>>>>
>>>>>> Mikael, Staffan, it looks like as if we don't have a nice solution
>>>>>> for sharing
>>>>>> the library at the moment. What do you think about having the
>>>>>> duplication as an
>>>>>> intermediate solution until we get the necessary support from
>>>>>> jtreg / jprt to
>>>>>> share the library?
>>>>>>
>>>>>> There are also other JDK tests that would benefit from having the
>>>>>> Whitebox API
>>>>>> available. For example, JDK-8057707 [1].
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>> [1]
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html
>>>>>>
>>>>>>
>>>>>> On 02.12.2014 20:54, Tobias Hartmann wrote:
>>>>>>> Hi Staffan,
>>>>>>>
>>>>>>> thanks for the feedback.
>>>>>>>
>>>>>>> On 02.12.2014 20:45, Staffan Larsen wrote:
>>>>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen
>>>>>>>>> <staffan.larsen at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann
>>>>>>>>>> <Tobias.Hartmann at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Mikael,
>>>>>>>>>>
>>>>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote:
>>>>>>>>>>> Tobias,
>>>>>>>>>>>
>>>>>>>>>>> Have you looked at what it would take to move the testlibrary
>>>>>>>>>>> somewhere where it
>>>>>>>>>>> can actually be shared instead? I think it would be extremely
>>>>>>>>>>> unfortunate to
>>>>>>>>>>> copy the code. I can't stress that enough.
>>>>>>>>>> I agree that having the testlibrary in a shared location is
>>>>>>>>>> definitely the best
>>>>>>>>>> solution. Unfortunately, I don't know how to do that since we
>>>>>>>>>> have to access the
>>>>>>>>>> library from different repositories and I don't think we want
>>>>>>>>>> to have path
>>>>>>>>>> dependencies between the repositories.
>>>>>>>>>>
>>>>>>>>>> Any suggestions?
>>>>>>>>> jtreg currently requires the testlibrary to be located in or
>>>>>>>>> under the directory with the TEST.ROOT file. To move it
>>>>>>>>> somewhere else we need to change jtreg first - and I think we
>>>>>>>>> should.
>>>>>>>> I?ve been told that it is actually possible to do this with the
>>>>>>>> current jtreg by using an ugly path such as:
>>>>>>>>
>>>>>>>>   @library /../../test/testlibrary
>>>>>>>>
>>>>>>>> I don?t think that is what we want to do?
>>>>>>> Yes, that's what I meant with "path dependencies between
>>>>>>> repositories". I don't
>>>>>>> think this is a very robust solution.
>>>>>>>
>>>>>>> Best,
>>>>>>> Tobias
>>>>>>>
>>>>>>>> /Staffan
>>>>>>>>
>>>>>>>>
>>>>>>>>> /Staffan
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias
>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Mikael
>>>>>>>>>>>
>>>>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> please review the following patch that copies the Whitebox
>>>>>>>>>>>> testlibrary to
>>>>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for
>>>>>>>>>>>> example, see [1]).
>>>>>>>>>>>>
>>>>>>>>>>>> The change leads to code duplication but in my opinion we
>>>>>>>>>>>> should favour stable
>>>>>>>>>>>> tests over code duplication here. Hopefully, there is a
>>>>>>>>>>>> solution to share the
>>>>>>>>>>>> library in the future.
>>>>>>>>>>>>
>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433
>>>>>>>>>>>> Webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Tobias
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From igor.ignatyev at oracle.com  Tue Dec  9 18:19:41 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Dec 2014 21:19:41 +0300
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <54870A75.2000008@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>,
	<54857B2E.8020100@oracle.com>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>
	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
	<54870A75.2000008@oracle.com>
Message-ID: <54873D3D.2030704@oracle.com>

Guys,

changing Whitebox package name will cause failures in the tens tests 
which and aren't co-located w/ the product.
right now, we have jigsaw m2 integrating into group repos, this also can 
lead to some failures. and I'd like not to have these failures mixed up. 
so I don't want to have whitebox renamed this and next week.
however I do want to have whitebox available in jdk and hotspot repo 
this week.

can we move whitebox to top repo now and do renaming later?

On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
> Hi,
>
> I just noticed that if we want to access the Whitebox API in the top level
> repository we also have to adapt the native lookup code in
> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>
> I therefore suggest to move the Whitebox API completely and adapt all tests in
> the hotspot repository. Here are the corresponding webrevs:
>
> Top level repo:
> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>
> Hotspot repo:
> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>
> Tested on JPRT.
>
> Thanks,
> Tobias
>
> On 09.12.2014 11:00, Staffan Larsen wrote:
>> +1
>>
>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> thanks for the feedback.
>>>>
>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>
>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com <mailto:stefan.sarne at oracle.com>:
>>>>>>> ...
>>>>>>>
>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>> library.
>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>
>>>>>> For the present root-repo proposal:
>>>>>>
>>>>>>   - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>     what's used in the jdk repo?
>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>> Yes, do you prefer 'test/lib'?
>>>
>>> Now sounds like a good time to align.   :)
>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>> step).
>>> Let's go with test/lib.
>>>
>>>>
>>>>>>   - Why does the white-box library get its own directory?  Shouldn't
>>>>>>     all test-library classes have the same package root?
>>>>> +1
>>>> I agree. I'll remove the whitebox directory.
>>>
>>> Sounds good, the same package root is better.
>>>
>>>>
>>>>>>   - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>     proper naming scheme for test-library packages, preferably starting
>>>>>>     with "jdk.?.
>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>> Whatever you prefer.
>>>
>>> If we go with test/lib - I think jdk.testlib make sense.
>>>
>>> Thanks
>>> Stefan
>>>
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>> the files in the jdk directory, however.
>>>>>
>>>>> /Staffan
>>

-- 
Igor

From stefan.sarne at oracle.com  Tue Dec  9 19:04:52 2014
From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=)
Date: Tue, 09 Dec 2014 20:04:52 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <54873D3D.2030704@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>,
	<54857B2E.8020100@oracle.com>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>
	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
	<54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com>
Message-ID: <548747D4.40805@oracle.com>


Make sense.

I am ok with delaying the name change.
There is a phase two with the bulk of the job to this anyway.
Dmitry, this is where we can have the repo discussion as well.

I think there is an interesting part here anyway.

Best regards,
Stefan

Igor Ignatyev skrev 2014-12-09 19:19:
> Guys,
>
> changing Whitebox package name will cause failures in the tens tests 
> which and aren't co-located w/ the product.
> right now, we have jigsaw m2 integrating into group repos, this also 
> can lead to some failures. and I'd like not to have these failures 
> mixed up. so I don't want to have whitebox renamed this and next week.
> however I do want to have whitebox available in jdk and hotspot repo 
> this week.
>
> can we move whitebox to top repo now and do renaming later?
>
> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> I just noticed that if we want to access the Whitebox API in the top 
>> level
>> repository we also have to adapt the native lookup code in
>> src/share/vm/prims/nativeLookup.cpp because it depends on the package 
>> name.
>>
>> I therefore suggest to move the Whitebox API completely and adapt all 
>> tests in
>> the hotspot repository. Here are the corresponding webrevs:
>>
>> Top level repo:
>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>
>> Hotspot repo:
>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>
>> Tested on JPRT.
>>
>> Thanks,
>> Tobias
>>
>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>> +1
>>>
>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>> Hi,
>>>>>
>>>>> thanks for the feedback.
>>>>>
>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>
>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com 
>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>> ...
>>>>>>>>
>>>>>>>> This would also be a good place to discuss the structure of the 
>>>>>>>> test
>>>>>>>> library.
>>>>>>> Yes.  The various "testlibrary" directories in different repos 
>>>>>>> are, at
>>>>>>> the moment, a bit of a mess and in some cases appear to be 
>>>>>>> redundant.
>>>>>>>
>>>>>>> For the present root-repo proposal:
>>>>>>>
>>>>>>>   - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>     what's used in the jdk repo?
>>>>>> Probably because it?s called test/testlibrary in the hotspot repo 
>>>>>> :-)
>>>>> Yes, do you prefer 'test/lib'?
>>>>
>>>> Now sounds like a good time to align.   :)
>>>> We can update testlibrary in hotspot to the same as well I think 
>>>> (as a second
>>>> step).
>>>> Let's go with test/lib.
>>>>
>>>>>
>>>>>>>   - Why does the white-box library get its own directory?  
>>>>>>> Shouldn't
>>>>>>>     all test-library classes have the same package root?
>>>>>> +1
>>>>> I agree. I'll remove the whitebox directory.
>>>>
>>>> Sounds good, the same package root is better.
>>>>
>>>>>
>>>>>>>   - The package name "sun.hotspot" is archaic.  We should figure 
>>>>>>> out a
>>>>>>>     proper naming scheme for test-library packages, preferably 
>>>>>>> starting
>>>>>>>     with "jdk.?.
>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>> Whatever you prefer.
>>>>
>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>
>>>> Thanks
>>>> Stefan
>>>>
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> Based on the discussion around microbenchmarks, it may make 
>>>>>>>> sense to
>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>> But again, perhaps this is something we can wait for and handle 
>>>>>>>> in the
>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>> The jdk/test/lib directory has been around for many years now 
>>>>>>> and only
>>>>>>> contains 28 files.  It seems unlikely that the root-repo 
>>>>>>> equivalent will
>>>>>>> ever be much larger than that, so a separate repo would be 
>>>>>>> overkill.
>>>>>> The corresponding directory in hotspot has 56 files and has 
>>>>>> expanded quite a
>>>>>> bit recently. I expect some growth to continue. Many of these 
>>>>>> overlap with
>>>>>> the files in the jdk directory, however.
>>>>>>
>>>>>> /Staffan
>>>
>


From stefan.sarne at oracle.com  Tue Dec  9 19:09:25 2014
From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=)
Date: Tue, 09 Dec 2014 20:09:25 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <20141209090930.405310@eggemoggin.niobe.net>
References: <547DCF47.9000608@oracle.com>, <>, <<547DF563.8080509@oracle.com>,
	<5486C62C.2040906@oracle.com>, <5486C73B.5080206@oracle.com>
	<20141209090930.405310@eggemoggin.niobe.net>
Message-ID: <548748E5.80304@oracle.com>


     Sure.

/Stefan

> I suggest jdk.test.lib -- that way the prefix "jdk.test" can be used
> in other situations where test code needs a package name.
>
> - Mark


From erik.helin at oracle.com  Tue Dec  9 19:35:51 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 09 Dec 2014 20:35:51 +0100
Subject: RFR: 8066875: VirtualSpace does not use large pages
Message-ID: <54874F17.7070303@oracle.com>

Hi all,

the fix for JDK-8049864 [0] made os::page_size_for_region slightly more 
strict since the function now demands that the given region_size is size 
aligned with respect to the chosen page_size. The reason for doing this 
was that os::page_size_for_region was used in two ways:
1. Give me a suitable page size for this amount of memory
2. Give me the largest page size for this amount of memory
The fix for JDK-8049864 fixed os::page_size_for_region for the "suitable 
page size" scenario, but is too strict for the "largest page size" 
scenario. This caused a regression in VirtualSpace::initialize, which 
only needs the largest possible page size, since 
VirtualSpace::initialize_with_granularity takes care of any alignment 
issues.

This patch adds the function os::largest_page_size_less_than and updates 
VirtualSpace::initialize to use this new function instead of 
os::page_size_for_region.

Webrev:
http://cr.openjdk.java.net/~ehelin/8066875/webrev.00/

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

Testing:
- JPRT
- Verified that the code cache now uses large pages even if
   ReservedCodeCacheSize is 241 MB (see bug for more details).
- Added new internal vm tests (also run on SPARC machine with large
   pages)

Thanks,
Erik

[0]: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b326a3e8dcab

From roland.westrelin at oracle.com  Tue Dec  9 20:08:26 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Dec 2014 21:08:26 +0100
Subject: [8u] backport of 8048170: Test
	closed/java/text/Normalizer/ConformanceTest.java failed
In-Reply-To: <5487284C.6080002@oracle.com>
References: <79A63124-352F-4611-9856-7C2F65C6415B@oracle.com>
	<5487284C.6080002@oracle.com>
Message-ID: <BDBF02AD-8582-4835-AFFC-CC494CD5D51A@oracle.com>

Thanks, Vladimir.

Roland.


From vladimir.kozlov at oracle.com  Tue Dec  9 20:19:36 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Dec 2014 12:19:36 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <546F7F42.5090100@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>
	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>
	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>
	<546F7765.1070907@redhat.com> <546F7F42.5090100@oracle.com>
Message-ID: <54875958.5010707@oracle.com>

Hi Andrew,

What is the status of these changes?
I hope you are not waiting some our response.

Regards,
Vladimir

On 11/21/14 10:06 AM, Vladimir Kozlov wrote:
> On 11/21/14 9:33 AM, Andrew Haley wrote:
>> On 11/20/2014 06:13 PM, Andrew Haley wrote:
>>> On 11/20/2014 06:05 PM, Vladimir Kozlov wrote:
>>>> I based the name on your comment:
>>>>
>>>> +  // AArch64 uses store release (which does everything we need to keep
>>>> +  // the machine in order) but we still need a compiler barrier here.
>>>
>>> Ah.  Okay, I'll have to think of a good name for it, then.
>>>
>>>> You can name it as you like. Our main suggestion is to use such Boolean
>>>> constant and normal if() statements instead of ifdef AARCH64 and
>>>> AARCH64_ONLY/NOT_AARCH64 macros in C2 code (src/share/vm/opto/* files).
>>>>
>>>> We already do similar things for PPC64 port which sets
>>>> support_IRIW_for_* constant.
>>>
>>> Okay,
>>
>> I've done something similar but more useful.  I've added an
>> experimental flag: UseBarriersForVolatile.  This defaults to true for
>> all targets, but we can override it in the back end.  That gives me
>> the chance to do some benchmarking on various AArch64 targets to see
>> which ones benefit from the new load acquire/store release
>> instructions.
>
> Okay.
>
>>
>> I have kept AARCH64_ONLY for two hunks:
>>
>> --- old/src/share/vm/opto/memnode.hpp    2014-11-21 12:09:22.766963837
>> -0500
>> +++ new/src/share/vm/opto/memnode.hpp    2014-11-21 12:09:22.546983320
>> -0500
>> @@ -503,6 +503,10 @@
>>     // Conservatively release stores of object references in order to
>>     // ensure visibility of object initialization.
>>     static inline MemOrd release_if_reference(const BasicType t) {
>> +    // AArch64 doesn't need a release store here because object
>> +    // initialization contains the necessary barriers.
>> +    AARCH64_ONLY(return unordered);
>> +
>>       const MemOrd mo = (t == T_ARRAY ||
>>                          t == T_ADDRESS || // Might be the address of
>> an object reference (`boxing').
>>                          t == T_OBJECT) ? release : unordered;
>
> This could be needed for ppc64 too, not only for IA64.
>
>>
>> --- old/src/share/vm/opto/graphKit.cpp    2014-11-21
>> 12:09:20.017207376 -0500
>> +++ new/src/share/vm/opto/graphKit.cpp    2014-11-21
>> 12:09:19.787227745 -0500
>> @@ -3813,7 +3813,8 @@
>>
>>     // Smash zero into card
>>     if( !UseConcMarkSweepGC ) {
>> -    __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release);
>> +    __ store(__ ctrl(), card_adr, zero, bt, adr_type,
>> +             NOT_AARCH64(MemNode::release)
>> AARCH64_ONLY(MemNode::unordered));
>>     } else {
>>       // Specialized path for CM store barrier
>>       __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt,
>> adr_type);
>
> Looks like PPC64 needs that. In ppc.ad:
>
>    // Use release_store for card-marking to ensure that previous
>    // oop-stores are visible before the card-mark change.
>    enc_class enc_cms_card_mark(memory mem, iRegLdst releaseFieldAddr) %{
>
>>
>> The first hunk is only required by IA64 as far as I am aware, but I
>> am nervous about making it IA64_ONLY.  The second hunk is a release
>> node which is not as far as I am aware required by any target, and
>> should simply be removed.
>>
>> This isn't a RFA because it's not tested yet, but what do you think?
>
> Since it affects ppc64 and ia64 we need to ask Goetz and Co.
> I would suggest to put both these places under platform specific
> flags/bool constant.
>
> Thanks,
> Vladimir
>
>>
>> Andrew.
>>

From david.holmes at oracle.com  Wed Dec 10 06:37:41 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Dec 2014 16:37:41 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <5486FF9A.2050604@gmail.com>
References: <542C8274.3010809@gmail.com>	<543E80F8.3080204@gmail.com>	<547330E5.1050708@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>	<547D891D.7010809@oracle.com>	<547DCCFB.3050209@gmail.com>	<54854475.20800@oracle.com>	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>	<54868B02.1070408@oracle.com>	<CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>	<5486B952.4070708@oracle.com>
	<CAA-vtUyRtwD+08BjZSZY_q5uHGnb8kmW7AZD2TSe=_0h6rgT_A@mail.gmai!
	l.com> <5486FF9A.2050604@gma! il.com>
Message-ID: <5487EA35.6070709@oracle.com>

Hi Yasumasa,

On 9/12/2014 11:56 PM, Yasumasa Suenaga wrote:
> David, Thomas,
>
> Thank you so much!
> I wait 2nd reviewer.

I'm a Reviewer and I think Thomas counts as a reviewer. Plus Staffan had 
a look too. So I think this is good to go - though I'll give it till my 
morning before finalizing it.

> BTW, I'm not a committer.
> So I'm also waiting a sponsor :-)

I will sponsor if you can prepare the changeset.

Thanks,
David

>> I'm okay with these changes. Just a minor style nit (no need for
>> updated webrev) can you remove the blank lines in os_linux.cpp:
>>
>> 6011       }
>> 6012
>> 6013     }
>> 6014
>> 6015   }
>>
>> 6057       }
>> 6058
>> 6059     }
>> 6060
>> 6061   }
>>
>> If anyone has any objections please raise them asap.
>
> I will upload new webrev which is fix them after reviewing.
>
>
> Thanks,
>
> Yasumasa
>
>
> (2014/12/09 21:06), Thomas St?fe wrote:
>> Yes, Sure :-) @Yasumasa : thank you for this patch!
>>
>> Kind regards, Thomas
>>
>> On Dec 9, 2014 9:56 AM, "David Holmes" <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Thomas,
>>
>>     So can we take this as-is for now and file a RFE to address your
>> concerns?
>>
>>     Anybody else object to that?
>>
>>     Thanks,
>>     David
>>
>>     On 9/12/2014 6:09 PM, Thomas St?fe wrote:
>>
>>         Hi David,
>>
>>         On Tue, Dec 9, 2014 at 6:39 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 Thomas,
>>
>>              On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>>
>>                  Hi,
>>
>>                  I do not really like the handling of the leading pipe
>> symbol:
>>
>>
>>              To be fair to Yasumasa this aspect of the fix has been
>> the same
>>              since Oct 15:
>>
>>
>> http://cr.openjdk.java.net/~____ysuenaga/JDK-8059586/webrev.____02/
>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/>
>>
>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/
>> <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/>>
>>
>>              and was not flagged.
>>
>>
>>         You are right, I did not read those mails close enough.
>>
>>
>>
>>                  So, we read the core_pattern, and if the pipe symbol
>> is detected, we
>>                  write the core pattern minus the pipe symbol but plus
>> a leading
>>                  quote to
>>                  the output; the leading quote then serves as a info
>> to the layer
>>                  above
>>                  in os_posix.cpp to treat this case specially. This
>> means the logic
>>                  spills out of the platform dependend os_linux.cpp to
>> shared code and
>>                  this is also difficult to read.
>>
>>                  This comes from the fact that "get_core_path()"
>> assumes the core
>>                  file is
>>                  written to the file system. I think it just does not fit
>>                  anymore, better
>>                  would be to replace it with something like
>>                  "os::print_core_file_location(____outputStream* os)",
>> and the OS
>>                  handles
>>                  both core path retrieval and the printing. Because
>> then the
>>                  shared code
>>                  does not need to know whether core file gets printed
>>                  traditionally or
>>                  piped to a executable or whatever.
>>
>>
>>              This sounds like a refactoring that I suggested would be
>> too disruptive.
>>
>>
>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015547.html
>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html>
>>
>>
>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html
>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015547.html>>
>>
>>
>>
>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015557.html
>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html>
>>
>>
>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html
>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015557.html>>
>>
>>
>>
>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015573.html
>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html>
>>
>>
>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html
>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015573.html>>
>>
>>
>>
>>         I do not think that this would be such a big a change, but it
>> also could
>>         be done with another patch.
>>
>>         Apart from my reservations I stated above the code looks fine
>> and is
>>         definitly an improvement (just last week I was helplessly
>> looking for a
>>         core on a machine where core_pattern turned out to be a
>> redirection to
>>         another program).
>>
>>         Kind Regards, Thomas
>>
>>
>>              David
>>

From aph at redhat.com  Wed Dec 10 09:06:12 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Dec 2014 09:06:12 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54875958.5010707@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>
	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>
	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>
	<546F7765.1070907@redhat.com> <546F7F42.5090100@oracle.com>
	<54875958.5010707@oracle.com>
Message-ID: <54880D04.4050605@redhat.com>

On 09/12/14 20:19, Vladimir Kozlov wrote:
> What is the status of these changes?
> I hope you are not waiting some our response.

The issue arose of the maximum size of the code cache.  I have
been working on removing the 128Mb limit.  I will post the revised
patch today.

Andrew.


From tobias.hartmann at oracle.com  Wed Dec 10 09:39:13 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 10 Dec 2014 10:39:13 +0100
Subject: RFR: 8066875: VirtualSpace does not use large pages
In-Reply-To: <54874F17.7070303@oracle.com>
References: <54874F17.7070303@oracle.com>
Message-ID: <548814C1.8010905@oracle.com>

Hi Erik,

looks good (not a reviewer).

Thanks,
Tobias

On 09.12.2014 20:35, Erik Helin wrote:
> Hi all,
> 
> the fix for JDK-8049864 [0] made os::page_size_for_region slightly more strict
> since the function now demands that the given region_size is size aligned with
> respect to the chosen page_size. The reason for doing this was that
> os::page_size_for_region was used in two ways:
> 1. Give me a suitable page size for this amount of memory
> 2. Give me the largest page size for this amount of memory
> The fix for JDK-8049864 fixed os::page_size_for_region for the "suitable page
> size" scenario, but is too strict for the "largest page size" scenario. This
> caused a regression in VirtualSpace::initialize, which only needs the largest
> possible page size, since VirtualSpace::initialize_with_granularity takes care
> of any alignment issues.
> 
> This patch adds the function os::largest_page_size_less_than and updates
> VirtualSpace::initialize to use this new function instead of
> os::page_size_for_region.
> 
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8066875/webrev.00/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8066875
> 
> Testing:
> - JPRT
> - Verified that the code cache now uses large pages even if
>   ReservedCodeCacheSize is 241 MB (see bug for more details).
> - Added new internal vm tests (also run on SPARC machine with large
>   pages)
> 
> Thanks,
> Erik
> 
> [0]: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b326a3e8dcab

From tobias.hartmann at oracle.com  Wed Dec 10 10:52:34 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 10 Dec 2014 11:52:34 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <548747D4.40805@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>,
	<54857B2E.8020100@oracle.com>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>
	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
	<54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com>
	<548747D4.40805@oracle.com>
Message-ID: <548825F2.4010900@oracle.com>

Hi,

I'm fine with postponing the renaming. I'll file a RFE for this after the change
is in. Here are the new webrevs for moving only:

Top level repo:
http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/

Hotspot repo:
http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/

If there are no objections I would like to push the change soon.

Thanks,
Tobias

On 09.12.2014 20:04, Stefan S?rne wrote:
> 
> Make sense.
> 
> I am ok with delaying the name change.
> There is a phase two with the bulk of the job to this anyway.
> Dmitry, this is where we can have the repo discussion as well.
> 
> I think there is an interesting part here anyway.
> 
> Best regards,
> Stefan
> 
> Igor Ignatyev skrev 2014-12-09 19:19:
>> Guys,
>>
>> changing Whitebox package name will cause failures in the tens tests which and
>> aren't co-located w/ the product.
>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>> to some failures. and I'd like not to have these failures mixed up. so I don't
>> want to have whitebox renamed this and next week.
>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>
>> can we move whitebox to top repo now and do renaming later?
>>
>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> I just noticed that if we want to access the Whitebox API in the top level
>>> repository we also have to adapt the native lookup code in
>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>
>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>> the hotspot repository. Here are the corresponding webrevs:
>>>
>>> Top level repo:
>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>
>>> Hotspot repo:
>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>
>>> Tested on JPRT.
>>>
>>> Thanks,
>>> Tobias
>>>
>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>> +1
>>>>
>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> thanks for the feedback.
>>>>>>
>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>
>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>> library.
>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>
>>>>>>>> For the present root-repo proposal:
>>>>>>>>
>>>>>>>>   - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>     what's used in the jdk repo?
>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>> Yes, do you prefer 'test/lib'?
>>>>>
>>>>> Now sounds like a good time to align.   :)
>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>> step).
>>>>> Let's go with test/lib.
>>>>>
>>>>>>
>>>>>>>>   - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>     all test-library classes have the same package root?
>>>>>>> +1
>>>>>> I agree. I'll remove the whitebox directory.
>>>>>
>>>>> Sounds good, the same package root is better.
>>>>>
>>>>>>
>>>>>>>>   - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>     proper naming scheme for test-library packages, preferably starting
>>>>>>>>     with "jdk.?.
>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>> Whatever you prefer.
>>>>>
>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>
>>>>> Thanks
>>>>> Stefan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>> the files in the jdk directory, however.
>>>>>>>
>>>>>>> /Staffan
>>>>
>>
> 

From staffan.larsen at oracle.com  Wed Dec 10 10:54:45 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 10 Dec 2014 11:54:45 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <548825F2.4010900@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <,
	> <54857B2E.8020100@oracle.com> <>>>>>
	<20141208111859.936395@eggemoggin.niobe.net>
	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
	<5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com>
	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
	<54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com>
	<548747D4.40805@oracle.com> <548825F2.4010900@oracle.com>
Message-ID: <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>

I think we agreed to use jdk.test.lib as the package name (one dot more).

/Staffan

> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
> 
> Hi,
> 
> I'm fine with postponing the renaming. I'll file a RFE for this after the change
> is in. Here are the new webrevs for moving only:
> 
> Top level repo:
> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
> 
> Hotspot repo:
> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
> 
> If there are no objections I would like to push the change soon.
> 
> Thanks,
> Tobias
> 
> On 09.12.2014 20:04, Stefan S?rne wrote:
>> 
>> Make sense.
>> 
>> I am ok with delaying the name change.
>> There is a phase two with the bulk of the job to this anyway.
>> Dmitry, this is where we can have the repo discussion as well.
>> 
>> I think there is an interesting part here anyway.
>> 
>> Best regards,
>> Stefan
>> 
>> Igor Ignatyev skrev 2014-12-09 19:19:
>>> Guys,
>>> 
>>> changing Whitebox package name will cause failures in the tens tests which and
>>> aren't co-located w/ the product.
>>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>>> to some failures. and I'd like not to have these failures mixed up. so I don't
>>> want to have whitebox renamed this and next week.
>>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>> 
>>> can we move whitebox to top repo now and do renaming later?
>>> 
>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>> Hi,
>>>> 
>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>> repository we also have to adapt the native lookup code in
>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>> 
>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>>> the hotspot repository. Here are the corresponding webrevs:
>>>> 
>>>> Top level repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>> 
>>>> Hotspot repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>> 
>>>> Tested on JPRT.
>>>> 
>>>> Thanks,
>>>> Tobias
>>>> 
>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>> +1
>>>>> 
>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> thanks for the feedback.
>>>>>>> 
>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>> ...
>>>>>>>>>> 
>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>> library.
>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>> 
>>>>>>>>> For the present root-repo proposal:
>>>>>>>>> 
>>>>>>>>>  - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>    what's used in the jdk repo?
>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>> 
>>>>>> Now sounds like a good time to align.   :)
>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>>> step).
>>>>>> Let's go with test/lib.
>>>>>> 
>>>>>>> 
>>>>>>>>>  - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>    all test-library classes have the same package root?
>>>>>>>> +1
>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>> 
>>>>>> Sounds good, the same package root is better.
>>>>>> 
>>>>>>> 
>>>>>>>>>  - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>    proper naming scheme for test-library packages, preferably starting
>>>>>>>>>    with "jdk.?.
>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>> Whatever you prefer.
>>>>>> 
>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>> 
>>>>>> Thanks
>>>>>> Stefan
>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>> 
>>>>>>>>>> ...
>>>>>>>>>> 
>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>>> the files in the jdk directory, however.
>>>>>>>> 
>>>>>>>> /Staffan
>>>>> 
>>> 
>> 


From tobias.hartmann at oracle.com  Wed Dec 10 10:55:14 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 10 Dec 2014 11:55:14 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <548825F2.4010900@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>,
	<547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>,
	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>,
	<54855234.3050400@oracle.com>,
	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>,
	<54856A31.9020702@oracle.com>,
	<54857B2E.8020100@oracle.com>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>	<54870A75.2000008@oracle.com>
	<54873D3D.2030704@oracle.com>	<548747D4.40805@oracle.com>
	<548825F2.4010900@oracle.com>
Message-ID: <54882692.2000702@oracle.com>

Sorry, I sent the wrong webrev link for the top level repository:

http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/

Tobias

On 10.12.2014 11:52, Tobias Hartmann wrote:
> Hi,
> 
> I'm fine with postponing the renaming. I'll file a RFE for this after the change
> is in. Here are the new webrevs for moving only:
> 
> Top level repo:
> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
> 
> Hotspot repo:
> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
> 
> If there are no objections I would like to push the change soon.
> 
> Thanks,
> Tobias
> 
> On 09.12.2014 20:04, Stefan S?rne wrote:
>>
>> Make sense.
>>
>> I am ok with delaying the name change.
>> There is a phase two with the bulk of the job to this anyway.
>> Dmitry, this is where we can have the repo discussion as well.
>>
>> I think there is an interesting part here anyway.
>>
>> Best regards,
>> Stefan
>>
>> Igor Ignatyev skrev 2014-12-09 19:19:
>>> Guys,
>>>
>>> changing Whitebox package name will cause failures in the tens tests which and
>>> aren't co-located w/ the product.
>>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>>> to some failures. and I'd like not to have these failures mixed up. so I don't
>>> want to have whitebox renamed this and next week.
>>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>>
>>> can we move whitebox to top repo now and do renaming later?
>>>
>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>> repository we also have to adapt the native lookup code in
>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>
>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>
>>>> Top level repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>
>>>> Hotspot repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>
>>>> Tested on JPRT.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>> +1
>>>>>
>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> thanks for the feedback.
>>>>>>>
>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>> library.
>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>
>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>
>>>>>>>>>   - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>     what's used in the jdk repo?
>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>
>>>>>> Now sounds like a good time to align.   :)
>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>>> step).
>>>>>> Let's go with test/lib.
>>>>>>
>>>>>>>
>>>>>>>>>   - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>     all test-library classes have the same package root?
>>>>>>>> +1
>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>
>>>>>> Sounds good, the same package root is better.
>>>>>>
>>>>>>>
>>>>>>>>>   - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>     proper naming scheme for test-library packages, preferably starting
>>>>>>>>>     with "jdk.?.
>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>> Whatever you prefer.
>>>>>>
>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>
>>>>>> Thanks
>>>>>> Stefan
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>>> the files in the jdk directory, however.
>>>>>>>>
>>>>>>>> /Staffan
>>>>>
>>>
>>

From tobias.hartmann at oracle.com  Wed Dec 10 10:56:56 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 10 Dec 2014 11:56:56 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <,
	> <54857B2E.8020100@oracle.com> <>>>>>
	<20141208111859.936395@eggemoggin.niobe.net>
	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
	<5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com>
	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
	<54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com>
	<548747D4.40805@oracle.com> <548825F2.4010900@oracle.com>
	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>
Message-ID: <548826F8.4040100@oracle.com>


On 10.12.2014 11:54, Staffan Larsen wrote:
> I think we agreed to use jdk.test.lib as the package name (one dot more).

Yes, but as Igor suggested we postpone the renaming and first only move it.

I've also sent the wrong link. This is the right one:

http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/

Thanks,
Tobias

> 
> /Staffan
> 
>> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>
>> Hi,
>>
>> I'm fine with postponing the renaming. I'll file a RFE for this after the change
>> is in. Here are the new webrevs for moving only:
>>
>> Top level repo:
>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>
>> Hotspot repo:
>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>
>> If there are no objections I would like to push the change soon.
>>
>> Thanks,
>> Tobias
>>
>> On 09.12.2014 20:04, Stefan S?rne wrote:
>>>
>>> Make sense.
>>>
>>> I am ok with delaying the name change.
>>> There is a phase two with the bulk of the job to this anyway.
>>> Dmitry, this is where we can have the repo discussion as well.
>>>
>>> I think there is an interesting part here anyway.
>>>
>>> Best regards,
>>> Stefan
>>>
>>> Igor Ignatyev skrev 2014-12-09 19:19:
>>>> Guys,
>>>>
>>>> changing Whitebox package name will cause failures in the tens tests which and
>>>> aren't co-located w/ the product.
>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>>>> to some failures. and I'd like not to have these failures mixed up. so I don't
>>>> want to have whitebox renamed this and next week.
>>>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>>>
>>>> can we move whitebox to top repo now and do renaming later?
>>>>
>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>>> Hi,
>>>>>
>>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>>> repository we also have to adapt the native lookup code in
>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>>
>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>>
>>>>> Top level repo:
>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>
>>>>> Hotspot repo:
>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>>
>>>>> Tested on JPRT.
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>>> +1
>>>>>>
>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> thanks for the feedback.
>>>>>>>>
>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>>> library.
>>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>>
>>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>>
>>>>>>>>>>  - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>>    what's used in the jdk repo?
>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>>
>>>>>>> Now sounds like a good time to align.   :)
>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>>>> step).
>>>>>>> Let's go with test/lib.
>>>>>>>
>>>>>>>>
>>>>>>>>>>  - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>>    all test-library classes have the same package root?
>>>>>>>>> +1
>>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>>
>>>>>>> Sounds good, the same package root is better.
>>>>>>>
>>>>>>>>
>>>>>>>>>>  - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>>    proper naming scheme for test-library packages, preferably starting
>>>>>>>>>>    with "jdk.?.
>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>>> Whatever you prefer.
>>>>>>>
>>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Stefan
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>>>> the files in the jdk directory, however.
>>>>>>>>>
>>>>>>>>> /Staffan
>>>>>>
>>>>
>>>
> 

From aph at redhat.com  Wed Dec 10 10:59:10 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Dec 2014 10:59:10 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54880D04.4050605@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>
	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>
	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>
	<546F7765.1070907@redhat.com> <546F7F42.5090100@oracle.com>
	<54875958.5010707@oracle.com> <54880D04.4050605@redhat.com>
Message-ID: <5488277E.9080502@redhat.com>

http://cr.openjdk.java.net/~aph/aarch64-8064611-5/

I think that I have addressed every point that has been made on this
rather long thread.  The most important change is that the AArch64
port now no longer requires a code cache limit of 128Mb, but I have
still included an arch-specific way to limit the default code cache
size.  The logic behind this is that the extra trampoline stubs (and
the far branches in non-trampoline case) significantly bloat the
generated code and cause us to reach the point where we have to use
the trampolines more quickly.

So, there are now two #defines which can be overridden by targets:
CODE_CACHE_DEFAULT_LIMIT and CODE_CACHE_SIZE_LIMIT.

Thanks,
Andrew.


From david.holmes at oracle.com  Wed Dec 10 11:22:27 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Dec 2014 21:22:27 +1000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <CA+3eh11re+mv2uqOgeerDHzW9EtiLV+_=LAWnBCMvTOEoRHQpg@mail.gmail.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>
	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>
	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>
	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>
	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>
	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>
	<546F7F42.5090100@oracle.com>
	<CA+3eh11re+mv2uqOgeerDHzW9EtiLV+_=LAWnBCMvTOEoRHQpg@mail.gmail.com>
Message-ID: <54882CF3.40709@oracle.com>

On 28/11/2014 11:41 PM, Volker Simonis wrote:
> Hi,
>
> I think Goetz answered to the remaining questions a few days ago:
>
> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2014-November/001855.html
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016199.html
>
> but for some reason his mail doesn't appear in this mail thread.
>
> As he wrote, the release store into the card table in graphKit.cpp
> isn't needed and we've just removed in in our internal version a few
> weeks ago as well.

Has anyone from hotspot team confirmed that analysis? I haven't seen 
anything to that effect and I'm wary of making this kind of change to 
shared code.

Thanks,
David

> The first one in memnode.hpp is indeed only needed on IA64 so your
> solution with AARCH64_ONLY is OK for us.
>
> Regards,
> Volker
>
> On Fri, Nov 21, 2014 at 7:06 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> On 11/21/14 9:33 AM, Andrew Haley wrote:
>>>
>>> On 11/20/2014 06:13 PM, Andrew Haley wrote:
>>>>
>>>> On 11/20/2014 06:05 PM, Vladimir Kozlov wrote:
>>>>>
>>>>> I based the name on your comment:
>>>>>
>>>>> +  // AArch64 uses store release (which does everything we need to keep
>>>>> +  // the machine in order) but we still need a compiler barrier here.
>>>>
>>>>
>>>> Ah.  Okay, I'll have to think of a good name for it, then.
>>>>
>>>>> You can name it as you like. Our main suggestion is to use such Boolean
>>>>> constant and normal if() statements instead of ifdef AARCH64 and
>>>>> AARCH64_ONLY/NOT_AARCH64 macros in C2 code (src/share/vm/opto/* files).
>>>>>
>>>>> We already do similar things for PPC64 port which sets
>>>>> support_IRIW_for_* constant.
>>>>
>>>>
>>>> Okay,
>>>
>>>
>>> I've done something similar but more useful.  I've added an
>>> experimental flag: UseBarriersForVolatile.  This defaults to true for
>>> all targets, but we can override it in the back end.  That gives me
>>> the chance to do some benchmarking on various AArch64 targets to see
>>> which ones benefit from the new load acquire/store release
>>> instructions.
>>
>>
>> Okay.
>>
>>>
>>> I have kept AARCH64_ONLY for two hunks:
>>>
>>> --- old/src/share/vm/opto/memnode.hpp   2014-11-21 12:09:22.766963837
>>> -0500
>>> +++ new/src/share/vm/opto/memnode.hpp   2014-11-21 12:09:22.546983320
>>> -0500
>>> @@ -503,6 +503,10 @@
>>>      // Conservatively release stores of object references in order to
>>>      // ensure visibility of object initialization.
>>>      static inline MemOrd release_if_reference(const BasicType t) {
>>> +    // AArch64 doesn't need a release store here because object
>>> +    // initialization contains the necessary barriers.
>>> +    AARCH64_ONLY(return unordered);
>>> +
>>>        const MemOrd mo = (t == T_ARRAY ||
>>>                           t == T_ADDRESS || // Might be the address of an
>>> object reference (`boxing').
>>>                           t == T_OBJECT) ? release : unordered;
>>
>>
>> This could be needed for ppc64 too, not only for IA64.
>>
>>>
>>> --- old/src/share/vm/opto/graphKit.cpp  2014-11-21 12:09:20.017207376
>>> -0500
>>> +++ new/src/share/vm/opto/graphKit.cpp  2014-11-21 12:09:19.787227745
>>> -0500
>>> @@ -3813,7 +3813,8 @@
>>>
>>>      // Smash zero into card
>>>      if( !UseConcMarkSweepGC ) {
>>> -    __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release);
>>> +    __ store(__ ctrl(), card_adr, zero, bt, adr_type,
>>> +             NOT_AARCH64(MemNode::release)
>>> AARCH64_ONLY(MemNode::unordered));
>>>      } else {
>>>        // Specialized path for CM store barrier
>>>        __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt,
>>> adr_type);
>>
>>
>> Looks like PPC64 needs that. In ppc.ad:
>>
>>    // Use release_store for card-marking to ensure that previous
>>    // oop-stores are visible before the card-mark change.
>>    enc_class enc_cms_card_mark(memory mem, iRegLdst releaseFieldAddr) %{
>>
>>>
>>> The first hunk is only required by IA64 as far as I am aware, but I
>>> am nervous about making it IA64_ONLY.  The second hunk is a release
>>> node which is not as far as I am aware required by any target, and
>>> should simply be removed.
>>>
>>> This isn't a RFA because it's not tested yet, but what do you think?
>>
>>
>> Since it affects ppc64 and ia64 we need to ask Goetz and Co.
>> I would suggest to put both these places under platform specific flags/bool
>> constant.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Andrew.
>>>
>>

From david.holmes at oracle.com  Wed Dec 10 11:34:29 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Dec 2014 21:34:29 +1000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5488277E.9080502@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>
	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>
	<54880D04.4050605@redhat.com> <5488277E.9080502@redhat.com>
Message-ID: <54882FC5.6010906@oracle.com>

On 10/12/2014 8:59 PM, Andrew Haley wrote:
> http://cr.openjdk.java.net/~aph/aarch64-8064611-5/

src/share/vm/opto/memnode.hpp

Won't the unconditional return for aarch64 cause unreachable code warnings?

src/share/vm/opto/parse3.cpp
src/share/vm/opto/library_call.cpp

I'm not a C2 person but it seems strange to me that in one place if not 
using barriers for volatile you do nothing; whereas in the other place 
you insert Op_MemBarCPUOrder ??

src/share/vm/runtime/globals.hpp

Shouldn't UseBarriersForVolatile only be false on aarch64 ??

Thanks,
David

> I think that I have addressed every point that has been made on this
> rather long thread.  The most important change is that the AArch64
> port now no longer requires a code cache limit of 128Mb, but I have
> still included an arch-specific way to limit the default code cache
> size.  The logic behind this is that the extra trampoline stubs (and
> the far branches in non-trampoline case) significantly bloat the
> generated code and cause us to reach the point where we have to use
> the trampolines more quickly.
>
> So, there are now two #defines which can be overridden by targets:
> CODE_CACHE_DEFAULT_LIMIT and CODE_CACHE_SIZE_LIMIT.
>
> Thanks,
> Andrew.
>

From aph at redhat.com  Wed Dec 10 12:07:58 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Dec 2014 12:07:58 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54882CF3.40709@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<CA+3eh11re+mv2uqOgeerDHzW9EtiLV+_=LAWnBCMvTOEoRHQpg@mail.gmail.com>
	<54882CF3.40709@oracle.com>
Message-ID: <5488379E.9010200@redhat.com>

On 12/10/2014 11:22 AM, David Holmes wrote:
> On 28/11/2014 11:41 PM, Volker Simonis wrote:
>> Hi,
>>
>> I think Goetz answered to the remaining questions a few days ago:
>>
>> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2014-November/001855.html
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016199.html
>>
>> but for some reason his mail doesn't appear in this mail thread.
>>
>> As he wrote, the release store into the card table in graphKit.cpp
>> isn't needed and we've just removed in in our internal version a few
>> weeks ago as well.
> 
> Has anyone from hotspot team confirmed that analysis? I haven't seen 
> anything to that effect and I'm wary of making this kind of change to 
> shared code.

The change comes from Goetz; no-one from the HotSpot team knew why it
was there, so they said "ask Goetz", and he said it was a mistake.
And besides that, if this releasing store was really needed there
would have to be MemBars for the ports which don't have store release
instructions, but there are none.

I am, of course, perfectly happy to leave it as ifndef(AARCH64), but
this has been rejected.

Andrew.



From david.holmes at oracle.com  Wed Dec 10 12:24:03 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Dec 2014 22:24:03 +1000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5488379E.9010200@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<CA+3eh11re+mv2uqOgeerDHzW9EtiLV+_=LAWnBCMvTOEoRHQpg@mail.gmail.com>
	<54882CF3.40709@oracle.com> <5488379E.9010200@redhat.com>
Message-ID: <54883B63.9040806@oracle.com>

On 10/12/2014 10:07 PM, Andrew Haley wrote:
> On 12/10/2014 11:22 AM, David Holmes wrote:
>> On 28/11/2014 11:41 PM, Volker Simonis wrote:
>>> Hi,
>>>
>>> I think Goetz answered to the remaining questions a few days ago:
>>>
>>> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2014-November/001855.html
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016199.html
>>>
>>> but for some reason his mail doesn't appear in this mail thread.
>>>
>>> As he wrote, the release store into the card table in graphKit.cpp
>>> isn't needed and we've just removed in in our internal version a few
>>> weeks ago as well.
>>
>> Has anyone from hotspot team confirmed that analysis? I haven't seen
>> anything to that effect and I'm wary of making this kind of change to
>> shared code.
>
> The change comes from Goetz; no-one from the HotSpot team knew why it
> was there, so they said "ask Goetz", and he said it was a mistake.

Got it - PPC64 added it, but it wasn't actually needed.

Thanks,
David


> And besides that, if this releasing store was really needed there
> would have to be MemBars for the ports which don't have store release
> instructions, but there are none.
>
> I am, of course, perfectly happy to leave it as ifndef(AARCH64), but
> this has been rejected.
>
> Andrew.
>
>

From aph at redhat.com  Wed Dec 10 12:12:05 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Dec 2014 12:12:05 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54882FC5.6010906@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>
	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>
	<54880D04.4050605@redhat.com> <5488277E.9080502@redhat.com>
	<54882FC5.6010906@oracle.com>
Message-ID: <54883895.1000609@redhat.com>

On 12/10/2014 11:34 AM, David Holmes wrote:
> On 10/12/2014 8:59 PM, Andrew Haley wrote:
>> http://cr.openjdk.java.net/~aph/aarch64-8064611-5/
> 
> src/share/vm/opto/memnode.hpp
> 
> Won't the unconditional return for aarch64 cause unreachable code warnings?

Not for me, but I can add an else if you like.

> src/share/vm/opto/parse3.cpp
> src/share/vm/opto/library_call.cpp
> 
> I'm not a C2 person but it seems strange to me that in one place if not 
> using barriers for volatile you do nothing; whereas in the other place 
> you insert Op_MemBarCPUOrder ??
> 
> src/share/vm/runtime/globals.hpp

That's a fair comment.  Unfortunately C2 breaks if there are only CPU
barriers here, so I have to elide them in the back end.  It is very
unfortunate, but there are many places where C2 makes assumptions
about the ideal graphs generated by the front end.

> Shouldn't UseBarriersForVolatile only be false on aarch64 ??

Oh gosh, however did I miss that?  <red face>

Thanks,
Andrew.

From goetz.lindenmaier at sap.com  Wed Dec 10 13:09:06 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 10 Dec 2014 13:09:06 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5488379E.9010200@redhat.com>
References: <54625D3D.4000007@redhat.com>
	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>
	<54632ABA.5000706@redhat.com>
	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>
	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>
	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>
	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>
	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>
	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>
	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>
	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>
	<CA+3eh11re+mv2uqOgeerDHzW9EtiLV+_=LAWnBCMvTOEoRHQpg@mail.gmail.com>
	<54882CF3.40709@oracle.com> <5488379E.9010200@redhat.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF3DE1F@DEWDFEMB12A.global.corp.sap>

Hi,

yes, we verified that this release is not needed.  And it was introduced by us.

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley
Sent: Mittwoch, 10. Dezember 2014 13:08
To: David Holmes; Volker Simonis; Vladimir Kozlov
Cc: ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers
Subject: Re: AARCH64: 8064611: Changes to HotSpot shared code

On 12/10/2014 11:22 AM, David Holmes wrote:
> On 28/11/2014 11:41 PM, Volker Simonis wrote:
>> Hi,
>>
>> I think Goetz answered to the remaining questions a few days ago:
>>
>> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2014-November/001855.html
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-November/016199.html
>>
>> but for some reason his mail doesn't appear in this mail thread.
>>
>> As he wrote, the release store into the card table in graphKit.cpp
>> isn't needed and we've just removed in in our internal version a few
>> weeks ago as well.
> 
> Has anyone from hotspot team confirmed that analysis? I haven't seen 
> anything to that effect and I'm wary of making this kind of change to 
> shared code.

The change comes from Goetz; no-one from the HotSpot team knew why it
was there, so they said "ask Goetz", and he said it was a mistake.
And besides that, if this releasing store was really needed there
would have to be MemBars for the ports which don't have store release
instructions, but there are none.

I am, of course, perfectly happy to leave it as ifndef(AARCH64), but
this has been rejected.

Andrew.



From yasuenag at gmail.com  Wed Dec 10 14:44:19 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 10 Dec 2014 23:44:19 +0900
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <5487EA35.6070709@oracle.com>
References: <542C8274.3010809@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>	<547D891D.7010809@oracle.com>	<547DCCFB.3050209@gmail.com>	<54854475.20800@oracle.com>	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>	<54868B02.1070408@oracle.com>	<CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>	<5486B952.4070708@oracle.com>
	<CAA-vtUyRtwD+08BjZSZY_q5uHGnb8kmW7AZD2TSe=_0h6rgT_A@mail.gmai!
	l.com> <5486FF9A.2050604@gma! il.com> <5487EA35.6070709@oracle.com>
Message-ID: <54885C43.4060500@gmail.com>

Hi David,

> I will sponsor if you can prepare the changeset.

Thank you so much!
I've uploaded webrev which contains fixes for your comment.
http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.05/

Could you push this patch?


Thanks,

Yasumasa


(2014/12/10 15:37), David Holmes wrote:
> Hi Yasumasa,
>
> On 9/12/2014 11:56 PM, Yasumasa Suenaga wrote:
>> David, Thomas,
>>
>> Thank you so much!
>> I wait 2nd reviewer.
>
> I'm a Reviewer and I think Thomas counts as a reviewer. Plus Staffan had a look too. So I think this is good to go - though I'll give it till my morning before finalizing it.
>
>> BTW, I'm not a committer.
>> So I'm also waiting a sponsor :-)
>
> I will sponsor if you can prepare the changeset.
>
> Thanks,
> David
>
>>> I'm okay with these changes. Just a minor style nit (no need for
>>> updated webrev) can you remove the blank lines in os_linux.cpp:
>>>
>>> 6011       }
>>> 6012
>>> 6013     }
>>> 6014
>>> 6015   }
>>>
>>> 6057       }
>>> 6058
>>> 6059     }
>>> 6060
>>> 6061   }
>>>
>>> If anyone has any objections please raise them asap.
>>
>> I will upload new webrev which is fix them after reviewing.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> (2014/12/09 21:06), Thomas St?fe wrote:
>>> Yes, Sure :-) @Yasumasa : thank you for this patch!
>>>
>>> Kind regards, Thomas
>>>
>>> On Dec 9, 2014 9:56 AM, "David Holmes" <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>     Hi Thomas,
>>>
>>>     So can we take this as-is for now and file a RFE to address your
>>> concerns?
>>>
>>>     Anybody else object to that?
>>>
>>>     Thanks,
>>>     David
>>>
>>>     On 9/12/2014 6:09 PM, Thomas St?fe wrote:
>>>
>>>         Hi David,
>>>
>>>         On Tue, Dec 9, 2014 at 6:39 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 Thomas,
>>>
>>>              On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>>>
>>>                  Hi,
>>>
>>>                  I do not really like the handling of the leading pipe
>>> symbol:
>>>
>>>
>>>              To be fair to Yasumasa this aspect of the fix has been
>>> the same
>>>              since Oct 15:
>>>
>>>
>>> http://cr.openjdk.java.net/~____ysuenaga/JDK-8059586/webrev.____02/
>>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/>
>>>
>>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/
>>> <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/>>
>>>
>>>              and was not flagged.
>>>
>>>
>>>         You are right, I did not read those mails close enough.
>>>
>>>
>>>
>>>                  So, we read the core_pattern, and if the pipe symbol
>>> is detected, we
>>>                  write the core pattern minus the pipe symbol but plus
>>> a leading
>>>                  quote to
>>>                  the output; the leading quote then serves as a info
>>> to the layer
>>>                  above
>>>                  in os_posix.cpp to treat this case specially. This
>>> means the logic
>>>                  spills out of the platform dependend os_linux.cpp to
>>> shared code and
>>>                  this is also difficult to read.
>>>
>>>                  This comes from the fact that "get_core_path()"
>>> assumes the core
>>>                  file is
>>>                  written to the file system. I think it just does not fit
>>>                  anymore, better
>>>                  would be to replace it with something like
>>>                  "os::print_core_file_location(____outputStream* os)",
>>> and the OS
>>>                  handles
>>>                  both core path retrieval and the printing. Because
>>> then the
>>>                  shared code
>>>                  does not need to know whether core file gets printed
>>>                  traditionally or
>>>                  piped to a executable or whatever.
>>>
>>>
>>>              This sounds like a refactoring that I suggested would be
>>> too disruptive.
>>>
>>>
>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015547.html
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html>
>>>
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html
>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015547.html>>
>>>
>>>
>>>
>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015557.html
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html>
>>>
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html
>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015557.html>>
>>>
>>>
>>>
>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015573.html
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html>
>>>
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html
>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015573.html>>
>>>
>>>
>>>
>>>         I do not think that this would be such a big a change, but it
>>> also could
>>>         be done with another patch.
>>>
>>>         Apart from my reservations I stated above the code looks fine
>>> and is
>>>         definitly an improvement (just last week I was helplessly
>>> looking for a
>>>         core on a machine where core_pattern turned out to be a
>>> redirection to
>>>         another program).
>>>
>>>         Kind Regards, Thomas
>>>
>>>
>>>              David
>>>

From aph at redhat.com  Wed Dec 10 14:50:15 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Dec 2014 14:50:15 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54883895.1000609@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com>
Message-ID: <54885DA7.4010003@redhat.com>

On 12/10/2014 12:12 PM, Andrew Haley wrote:
> On 12/10/2014 11:34 AM, David Holmes wrote:
>> On 10/12/2014 8:59 PM, Andrew Haley wrote:
>>> http://cr.openjdk.java.net/~aph/aarch64-8064611-5/
>>
>> src/share/vm/opto/memnode.hpp
>>
>> Won't the unconditional return for aarch64 cause unreachable code warnings?
> 
> Not for me, but I can add an else if you like.
> 
>> src/share/vm/opto/parse3.cpp
>> src/share/vm/opto/library_call.cpp
>>
>> I'm not a C2 person but it seems strange to me that in one place if not 
>> using barriers for volatile you do nothing; whereas in the other place 
>> you insert Op_MemBarCPUOrder ??
>>
>> src/share/vm/runtime/globals.hpp
> 
> That's a fair comment.  Unfortunately C2 breaks if there are only CPU
> barriers here, so I have to elide them in the back end.  It is very
> unfortunate, but there are many places where C2 makes assumptions
> about the ideal graphs generated by the front end.
> 
>> Shouldn't UseBarriersForVolatile only be false on aarch64 ??
> 
> Oh gosh, however did I miss that?  <red face>

Fixed thusly:

http://cr.openjdk.java.net/~aph/aarch64-8064611-7/

Thanks,
Andrew.


From max.ockner at oracle.com  Wed Dec 10 16:56:55 2014
From: max.ockner at oracle.com (Max Ockner)
Date: Wed, 10 Dec 2014 11:56:55 -0500
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <548547B4.7000205@oracle.com>
References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com>
	<545CF033.4010503@oracle.com> <54619729.30704@oracle.com>
	<546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com>
	<5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com>
Message-ID: <54887B57.2050201@oracle.com>

New webrev: http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/

I have addressed dan's suggestions. I also removed unnecessary "this->" 
occurrences from the assert statements.

Though I realize that I have unnecessarily duplicated code in my tests, 
I do not want to combine the tests into one right now because (1) They 
work as they are, (2) They can fail independently, (3) The amount of 
code needed to run all four tests in one file without crashing out after 
the first failure is not as small as you might think, and (4) I want to 
commit this before someone else messes with the locks to avoid more 
merge conflicts.  To be clear, I am not opposed to fixing this 
separately if people think it is important, but I prefer to put it off 
until the bulk of the fix is committed.

Does this look ready?

Thanks for your help,
Max O



On 12/8/2014 1:39 AM, David Holmes wrote:
> Hi Max,
>
> Just a nit with the tests - it seems to me we should be able to write 
> a single Java class that can process all four combinations rather than 
> duplicating the bulk of the code.
>
> Thanks,
> David
>
> On 5/12/2014 7:50 AM, Max Ockner wrote:
>> Hello once again...
>> I have a new (and suggestively titled) webrev:
>> http://cr.openjdk.java.net/~coleenp/8047290final/
>>
>> Ran aurora tests.
>>
>> Here is a list of "sometimes" locks:
>>
>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>> "CompactibleFreeListSpace._lock"
>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>
>> "freelist par lock"
>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>
>> "SR_lock"                            share/vm/runtime/thread.cpp
>> "CMS_markBitMap_lock"
>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 
>>
>>
>>
>> The remaining "sometimes" locks can be found in
>> share/vm/runtime/mutexLocker.cpp:
>>
>> ParGCRareEvent_lock
>> Safepoint_lock
>> Threads_lock
>> VMOperationQueue_lock
>> VMOperationRequest_lock
>> Terminator_lock
>> Heap_lock
>> Compile_lock
>> PeriodicTask_lock
>> JfrStacktrace_lock
>>
>>
>> Thanks,
>> Max Ockner
>>
>>
>>
>>
>> On 11/25/2014 3:03 AM, David Holmes wrote:
>>> Hi Max,
>>>
>>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>>> Hello again,
>>>>
>>>> I have made changes based on all comments. There is now a pair of 
>>>> assert
>>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>>
>>> Is there an updated webrev?
>>>
>>>> caught another lock that I had to change to "sometimes", but the 
>>>> assert
>>>> that caught this lock was not in wait. There are currently no locks 
>>>> that
>>>> use try to pass an incorrect safepoint check argument to wait().
>>>> Instead, gcbasher did not catch this lock last time, when the only
>>>> asserts were in lock and lock_without_safepoint. This lock is
>>>> "CMS_markBitMap_lock" in
>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. 
>>>>
>>>>
>>>> I'm guessing that it was not caught by the tests because this 
>>>> section of
>>>> code is not reached very often. My initial inspection failed to catch
>>>> this lock because it is passed around between various structures and
>>>> renamed 4 times. I have not yet found a good way to check for this
>>>> situation, even with a debugger.
>>>>
>>>> Are there any tests which actually manage to hit every line of code?
>>>
>>> No. There is too much code that is dependent on low-level details of
>>> the GC used, the compilation strategy, plus the set of runtime flags
>>> used (and whether product or fastdebug). That's why we have lots of
>>> tests run in lots of different ways, to try to get coverage.
>>>
>>>> How should I handle this situation where I can't rely on the tests 
>>>> that
>>>> I have run to tell me if I have missed something?
>>>> At what point can I assume that everything is OK?
>>>
>>> Difficult to answer in general - there are a number of recommended
>>> test suites used by the runtime team, but your changes will also
>>> impact GC and compiler code and so may not get exercised by the
>>> runtime test suites (unless run with various compiler and GC options).
>>> Perhaps an ad-hoc test run similar to nightlies? Or you push after the
>>> weekly snapshot so as to maximise nightly testing, and if there are
>>> issues exposed then you have time to address them or revert the fix.
>>>
>>> Cheers,
>>> David
>>>
>>>> Thanks,
>>>> Max Ockner
>>>>
>>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>>> Hi Max,
>>>>>
>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>>> Hello all,
>>>>>> I have made these additonal changes:
>>>>>> -Moved the assert() statements into the lock and
>>>>>> lock_without_safepoint
>>>>>> methods.
>>>>>> -Changed Monitor::SafepointAllowed to 
>>>>>> Monitor::SafepointCheckRequired
>>>>>> -Changed the Monitor::SafepointCheckRequired values for several 
>>>>>> locks
>>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>>> MutexLocker, some were locked were locked without any MutexLocker* )
>>>>>>
>>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>>
>>>>> Generally this is all okay - a few style and other nits below.
>>>>>
>>>>> However you missed adding an assert in Monitor::wait to check if the
>>>>> no_safepoint_check flag was being used correctly for the current
>>>>> monitor.
>>>>>
>>>>> Specific comments:
>>>>>
>>>>> src/share/vm/runtime/mutex.hpp
>>>>>
>>>>> This comment is no longer accurate with the moved check location:
>>>>>
>>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>>> + // to ensure consistent checking for each lock.
>>>>>
>>>>> The same goes for other references to MutexLockerEx in the enum
>>>>> description.
>>>>>
>>>>> Also copyright year needs updating.
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/mutex.cpp
>>>>>
>>>>>  898   //Ensure
>>>>>  961   //Ensure
>>>>>
>>>>> Space needed after //
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>
>>>>> +  var = new type(Mutex::pri, #var,
>>>>> vm_block,safepoint_check_allowed); \
>>>>>
>>>>> space needed after comma in k,s
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>>
>>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Additional testing:
>>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>>> jtreg jfr tests
>>>>>>
>>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>>
>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>> "SLTMonitor" 
>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>> "CompactibleFreeListSpace._lock"
>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>
>>>>>>
>>>>>>
>>>>>> "freelist par lock"
>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>
>>>>>>
>>>>>>
>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>
>>>>>> The remaining "sometimes" locks can be found in
>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>
>>>>>> ParGCRareEvent_lock
>>>>>> Safepoint_lock
>>>>>> Threads_lock
>>>>>> VMOperationQueue_lock
>>>>>> VMOperationRequest_lock
>>>>>> Terminator_lock
>>>>>> Heap_lock
>>>>>> Compile_lock
>>>>>> PeriodicTask_lock
>>>>>> JfrStacktrace_lock
>>>>>>
>>>>>> I have not checked the validity of the "sometimes" locks, and I
>>>>>> believe
>>>>>> that this should be a different project.
>>>>>>
>>>>>> Thanks for your help!
>>>>>> Max Ockner
>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>>> Hi Max,
>>>>>>>
>>>>>>> This is looking good.
>>>>>>>
>>>>>>> A few high-level initial comments:
>>>>>>>
>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>>
>>>>>>> Why are the checks in MutexLocker when the state is maintained 
>>>>>>> in the
>>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>>> check in the mutex/monitor methods.
>>>>>>>
>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is good.
>>>>>>> But
>>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>>> safepoints should never be held when a thread blocks at a 
>>>>>>> safepoint -
>>>>>>> is there some way to easily check that? I was surprised how many
>>>>>>> locks
>>>>>>> are actually not checking for safepoints.
>>>>>>>
>>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>>> inconsistently and incorrectly?
>>>>>>>
>>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>>> Threads_lock with a safepoint check and a safepoint has been
>>>>>>> requested
>>>>>>> :) ).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> David
>>>>>>>
>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>>
>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or without a
>>>>>>>> safepoint check.
>>>>>>>> In some cases, a particular lock must either safepoint check
>>>>>>>> always or
>>>>>>>> never to avoid deadlocking.
>>>>>>>> Some other locks have semantics which allow them to avoid 
>>>>>>>> deadlocks
>>>>>>>> despite having a safepoint check only some of the time.
>>>>>>>> All locks that are OK having inconsistent safepoint checks have 
>>>>>>>> been
>>>>>>>> marked. All locks that should never safepoint check and all locks
>>>>>>>> that
>>>>>>>> should always safepoint check have also been marked.
>>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>>> check,
>>>>>>>> the lock's safepointAllowed marker is checked to ensure consistent
>>>>>>>> safepoint checking.
>>>>>>>>
>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>>
>>>>>>>> Tested with:
>>>>>>>>      jprt "-testset hotspot"
>>>>>>>>      jtreg hotspot
>>>>>>>>      vm.quick.testlist
>>>>>>>>
>>>>>>>> Whitebox tests:
>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test
>>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test
>>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code
>>>>>>>> should not assert. (Lock is properly acquired with no safepoint
>>>>>>>> check)
>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code
>>>>>>>> should not assert. (Lock is properly acquired with safepoint 
>>>>>>>> check)
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Max
>>>>>>>>
>>>>>>
>>>>
>>


From david.holmes at oracle.com  Wed Dec 10 20:27:47 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 11 Dec 2014 06:27:47 +1000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54885DA7.4010003@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
Message-ID: <5488ACC3.9070404@oracle.com>

On 11/12/2014 12:50 AM, Andrew Haley wrote:
> On 12/10/2014 12:12 PM, Andrew Haley wrote:
>> On 12/10/2014 11:34 AM, David Holmes wrote:
>>> On 10/12/2014 8:59 PM, Andrew Haley wrote:
>>>> http://cr.openjdk.java.net/~aph/aarch64-8064611-5/
>>>
>>> src/share/vm/opto/memnode.hpp
>>>
>>> Won't the unconditional return for aarch64 cause unreachable code warnings?
>>
>> Not for me, but I can add an else if you like.
>>
>>> src/share/vm/opto/parse3.cpp
>>> src/share/vm/opto/library_call.cpp
>>>
>>> I'm not a C2 person but it seems strange to me that in one place if not
>>> using barriers for volatile you do nothing; whereas in the other place
>>> you insert Op_MemBarCPUOrder ??
>>>
>>> src/share/vm/runtime/globals.hpp
>>
>> That's a fair comment.  Unfortunately C2 breaks if there are only CPU
>> barriers here, so I have to elide them in the back end.  It is very
>> unfortunate, but there are many places where C2 makes assumptions
>> about the ideal graphs generated by the front end.
>>
>>> Shouldn't UseBarriersForVolatile only be false on aarch64 ??
>>
>> Oh gosh, however did I miss that?  <red face>
>
> Fixed thusly:
>
> http://cr.openjdk.java.net/~aph/aarch64-8064611-7/

If I had paid more attention to this earlier I would have suggested 
reversing the sense of the UseBarriersForVolatile flag 
(ElideBarriersForVolatiles?) because it makes it seem like using 
barriers for volatiles is experimental - which of course it isn't.

Also this seems C2 specific so shouldn't it be defined in c2_globals.hpp?

Thanks,
David

> Thanks,
> Andrew.
>

From aph at redhat.com  Wed Dec 10 20:44:19 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Dec 2014 20:44:19 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5488ACC3.9070404@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com>
Message-ID: <5488B0A3.7020003@redhat.com>

On 12/10/2014 08:27 PM, David Holmes wrote:
> If I had paid more attention to this earlier I would have suggested 
> reversing the sense of the UseBarriersForVolatile flag 
> (ElideBarriersForVolatiles?) because it makes it seem like using 
> barriers for volatiles is experimental - which of course it isn't.

OK.

> Also this seems C2 specific so shouldn't it be defined in c2_globals.hpp?

Sure.  This is the Patch That Never Ends, after all.  :-)

Let's see what the other reviewers say, and I'll wrap it all together.

Thanks,
Andrew.


From david.holmes at oracle.com  Wed Dec 10 20:48:26 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 11 Dec 2014 06:48:26 +1000
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <54887B57.2050201@oracle.com>
References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com>
	<545CF033.4010503@oracle.com> <54619729.30704@oracle.com>
	<546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com>
	<5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com>
	<54887B57.2050201@oracle.com>
Message-ID: <5488B19A.7080801@oracle.com>

On 11/12/2014 2:56 AM, Max Ockner wrote:
> New webrev: http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/
>
> I have addressed dan's suggestions. I also removed unnecessary "this->"
> occurrences from the assert statements.
>
> Though I realize that I have unnecessarily duplicated code in my tests,
> I do not want to combine the tests into one right now because (1) They
> work as they are, (2) They can fail independently, (3) The amount of
> code needed to run all four tests in one file without crashing out after
> the first failure is not as small as you might think, and (4) I want to
> commit this before someone else messes with the locks to avoid more
> merge conflicts.  To be clear, I am not opposed to fixing this
> separately if people think it is important, but I prefer to put it off
> until the bulk of the fix is committed.

I wasn't expecting the tests to always try to run the four variations if 
one failed. While there are some parts of the tests suites that do 
handle that I don't see it in the hotspot tests. But your call and this 
can be deferred.

> Does this look ready?

Yes.

Thanks,
David

> Thanks for your help,
> Max O
>
>
>
> On 12/8/2014 1:39 AM, David Holmes wrote:
>> Hi Max,
>>
>> Just a nit with the tests - it seems to me we should be able to write
>> a single Java class that can process all four combinations rather than
>> duplicating the bulk of the code.
>>
>> Thanks,
>> David
>>
>> On 5/12/2014 7:50 AM, Max Ockner wrote:
>>> Hello once again...
>>> I have a new (and suggestively titled) webrev:
>>> http://cr.openjdk.java.net/~coleenp/8047290final/
>>>
>>> Ran aurora tests.
>>>
>>> Here is a list of "sometimes" locks:
>>>
>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>> "CompactibleFreeListSpace._lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>
>>> "freelist par lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>
>>> "SR_lock"                            share/vm/runtime/thread.cpp
>>> "CMS_markBitMap_lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>>>
>>>
>>>
>>> The remaining "sometimes" locks can be found in
>>> share/vm/runtime/mutexLocker.cpp:
>>>
>>> ParGCRareEvent_lock
>>> Safepoint_lock
>>> Threads_lock
>>> VMOperationQueue_lock
>>> VMOperationRequest_lock
>>> Terminator_lock
>>> Heap_lock
>>> Compile_lock
>>> PeriodicTask_lock
>>> JfrStacktrace_lock
>>>
>>>
>>> Thanks,
>>> Max Ockner
>>>
>>>
>>>
>>>
>>> On 11/25/2014 3:03 AM, David Holmes wrote:
>>>> Hi Max,
>>>>
>>>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>>>> Hello again,
>>>>>
>>>>> I have made changes based on all comments. There is now a pair of
>>>>> assert
>>>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>>>
>>>> Is there an updated webrev?
>>>>
>>>>> caught another lock that I had to change to "sometimes", but the
>>>>> assert
>>>>> that caught this lock was not in wait. There are currently no locks
>>>>> that
>>>>> use try to pass an incorrect safepoint check argument to wait().
>>>>> Instead, gcbasher did not catch this lock last time, when the only
>>>>> asserts were in lock and lock_without_safepoint. This lock is
>>>>> "CMS_markBitMap_lock" in
>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.
>>>>>
>>>>>
>>>>> I'm guessing that it was not caught by the tests because this
>>>>> section of
>>>>> code is not reached very often. My initial inspection failed to catch
>>>>> this lock because it is passed around between various structures and
>>>>> renamed 4 times. I have not yet found a good way to check for this
>>>>> situation, even with a debugger.
>>>>>
>>>>> Are there any tests which actually manage to hit every line of code?
>>>>
>>>> No. There is too much code that is dependent on low-level details of
>>>> the GC used, the compilation strategy, plus the set of runtime flags
>>>> used (and whether product or fastdebug). That's why we have lots of
>>>> tests run in lots of different ways, to try to get coverage.
>>>>
>>>>> How should I handle this situation where I can't rely on the tests
>>>>> that
>>>>> I have run to tell me if I have missed something?
>>>>> At what point can I assume that everything is OK?
>>>>
>>>> Difficult to answer in general - there are a number of recommended
>>>> test suites used by the runtime team, but your changes will also
>>>> impact GC and compiler code and so may not get exercised by the
>>>> runtime test suites (unless run with various compiler and GC options).
>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push after the
>>>> weekly snapshot so as to maximise nightly testing, and if there are
>>>> issues exposed then you have time to address them or revert the fix.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Max Ockner
>>>>>
>>>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>>>> Hi Max,
>>>>>>
>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>>>> Hello all,
>>>>>>> I have made these additonal changes:
>>>>>>> -Moved the assert() statements into the lock and
>>>>>>> lock_without_safepoint
>>>>>>> methods.
>>>>>>> -Changed Monitor::SafepointAllowed to
>>>>>>> Monitor::SafepointCheckRequired
>>>>>>> -Changed the Monitor::SafepointCheckRequired values for several
>>>>>>> locks
>>>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>>>> MutexLocker, some were locked were locked without any MutexLocker* )
>>>>>>>
>>>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>>>
>>>>>> Generally this is all okay - a few style and other nits below.
>>>>>>
>>>>>> However you missed adding an assert in Monitor::wait to check if the
>>>>>> no_safepoint_check flag was being used correctly for the current
>>>>>> monitor.
>>>>>>
>>>>>> Specific comments:
>>>>>>
>>>>>> src/share/vm/runtime/mutex.hpp
>>>>>>
>>>>>> This comment is no longer accurate with the moved check location:
>>>>>>
>>>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>>>> + // to ensure consistent checking for each lock.
>>>>>>
>>>>>> The same goes for other references to MutexLockerEx in the enum
>>>>>> description.
>>>>>>
>>>>>> Also copyright year needs updating.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutex.cpp
>>>>>>
>>>>>>  898   //Ensure
>>>>>>  961   //Ensure
>>>>>>
>>>>>> Space needed after //
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>>
>>>>>> +  var = new type(Mutex::pri, #var,
>>>>>> vm_block,safepoint_check_allowed); \
>>>>>>
>>>>>> space needed after comma in k,s
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>>>
>>>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Additional testing:
>>>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>>>> jtreg jfr tests
>>>>>>>
>>>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>>>
>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>>> "SLTMonitor"
>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>>> "CompactibleFreeListSpace._lock"
>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "freelist par lock"
>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>>
>>>>>>> The remaining "sometimes" locks can be found in
>>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>>
>>>>>>> ParGCRareEvent_lock
>>>>>>> Safepoint_lock
>>>>>>> Threads_lock
>>>>>>> VMOperationQueue_lock
>>>>>>> VMOperationRequest_lock
>>>>>>> Terminator_lock
>>>>>>> Heap_lock
>>>>>>> Compile_lock
>>>>>>> PeriodicTask_lock
>>>>>>> JfrStacktrace_lock
>>>>>>>
>>>>>>> I have not checked the validity of the "sometimes" locks, and I
>>>>>>> believe
>>>>>>> that this should be a different project.
>>>>>>>
>>>>>>> Thanks for your help!
>>>>>>> Max Ockner
>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>>>> Hi Max,
>>>>>>>>
>>>>>>>> This is looking good.
>>>>>>>>
>>>>>>>> A few high-level initial comments:
>>>>>>>>
>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>>>
>>>>>>>> Why are the checks in MutexLocker when the state is maintained
>>>>>>>> in the
>>>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>>>> check in the mutex/monitor methods.
>>>>>>>>
>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is good.
>>>>>>>> But
>>>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>>>> safepoints should never be held when a thread blocks at a
>>>>>>>> safepoint -
>>>>>>>> is there some way to easily check that? I was surprised how many
>>>>>>>> locks
>>>>>>>> are actually not checking for safepoints.
>>>>>>>>
>>>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>>>> inconsistently and incorrectly?
>>>>>>>>
>>>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>>>> Threads_lock with a safepoint check and a safepoint has been
>>>>>>>> requested
>>>>>>>> :) ).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>>>
>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or without a
>>>>>>>>> safepoint check.
>>>>>>>>> In some cases, a particular lock must either safepoint check
>>>>>>>>> always or
>>>>>>>>> never to avoid deadlocking.
>>>>>>>>> Some other locks have semantics which allow them to avoid
>>>>>>>>> deadlocks
>>>>>>>>> despite having a safepoint check only some of the time.
>>>>>>>>> All locks that are OK having inconsistent safepoint checks have
>>>>>>>>> been
>>>>>>>>> marked. All locks that should never safepoint check and all locks
>>>>>>>>> that
>>>>>>>>> should always safepoint check have also been marked.
>>>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>>>> check,
>>>>>>>>> the lock's safepointAllowed marker is checked to ensure consistent
>>>>>>>>> safepoint checking.
>>>>>>>>>
>>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>>>
>>>>>>>>> Tested with:
>>>>>>>>>      jprt "-testset hotspot"
>>>>>>>>>      jtreg hotspot
>>>>>>>>>      vm.quick.testlist
>>>>>>>>>
>>>>>>>>> Whitebox tests:
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test
>>>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test
>>>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code
>>>>>>>>> should not assert. (Lock is properly acquired with no safepoint
>>>>>>>>> check)
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code
>>>>>>>>> should not assert. (Lock is properly acquired with safepoint
>>>>>>>>> check)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>

From coleen.phillimore at oracle.com  Wed Dec 10 21:00:30 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 10 Dec 2014 16:00:30 -0500
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <54887B57.2050201@oracle.com>
References: <543EB71A.8000403@oracle.com>
	<543F174F.7040204@oracle.com>	<545CF033.4010503@oracle.com>
	<54619729.30704@oracle.com>	<546E638E.2020208@oracle.com>
	<547437EF.5010806@oracle.com>	<5480D73F.7070907@oracle.com>
	<548547B4.7000205@oracle.com> <54887B57.2050201@oracle.com>
Message-ID: <5488B46E.8090005@oracle.com>


Hi Max,

You have addressed all of my issues with this change, so it's reviewed 
by me also.

Coleen

On 12/10/14, 11:56 AM, Max Ockner wrote:
> New webrev: http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/
>
> I have addressed dan's suggestions. I also removed unnecessary 
> "this->" occurrences from the assert statements.
>
> Though I realize that I have unnecessarily duplicated code in my 
> tests, I do not want to combine the tests into one right now because 
> (1) They work as they are, (2) They can fail independently, (3) The 
> amount of code needed to run all four tests in one file without 
> crashing out after the first failure is not as small as you might 
> think, and (4) I want to commit this before someone else messes with 
> the locks to avoid more merge conflicts. To be clear, I am not opposed 
> to fixing this separately if people think it is important, but I 
> prefer to put it off until the bulk of the fix is committed.
>
> Does this look ready?
>
> Thanks for your help,
> Max O
>
>
>
> On 12/8/2014 1:39 AM, David Holmes wrote:
>> Hi Max,
>>
>> Just a nit with the tests - it seems to me we should be able to write 
>> a single Java class that can process all four combinations rather 
>> than duplicating the bulk of the code.
>>
>> Thanks,
>> David
>>
>> On 5/12/2014 7:50 AM, Max Ockner wrote:
>>> Hello once again...
>>> I have a new (and suggestively titled) webrev:
>>> http://cr.openjdk.java.net/~coleenp/8047290final/
>>>
>>> Ran aurora tests.
>>>
>>> Here is a list of "sometimes" locks:
>>>
>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>> "CompactibleFreeListSpace._lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>
>>> "freelist par lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>
>>> "SR_lock" share/vm/runtime/thread.cpp
>>> "CMS_markBitMap_lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 
>>>
>>>
>>>
>>> The remaining "sometimes" locks can be found in
>>> share/vm/runtime/mutexLocker.cpp:
>>>
>>> ParGCRareEvent_lock
>>> Safepoint_lock
>>> Threads_lock
>>> VMOperationQueue_lock
>>> VMOperationRequest_lock
>>> Terminator_lock
>>> Heap_lock
>>> Compile_lock
>>> PeriodicTask_lock
>>> JfrStacktrace_lock
>>>
>>>
>>> Thanks,
>>> Max Ockner
>>>
>>>
>>>
>>>
>>> On 11/25/2014 3:03 AM, David Holmes wrote:
>>>> Hi Max,
>>>>
>>>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>>>> Hello again,
>>>>>
>>>>> I have made changes based on all comments. There is now a pair of 
>>>>> assert
>>>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>>>
>>>> Is there an updated webrev?
>>>>
>>>>> caught another lock that I had to change to "sometimes", but the 
>>>>> assert
>>>>> that caught this lock was not in wait. There are currently no 
>>>>> locks that
>>>>> use try to pass an incorrect safepoint check argument to wait().
>>>>> Instead, gcbasher did not catch this lock last time, when the only
>>>>> asserts were in lock and lock_without_safepoint. This lock is
>>>>> "CMS_markBitMap_lock" in
>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. 
>>>>>
>>>>>
>>>>> I'm guessing that it was not caught by the tests because this 
>>>>> section of
>>>>> code is not reached very often. My initial inspection failed to catch
>>>>> this lock because it is passed around between various structures and
>>>>> renamed 4 times. I have not yet found a good way to check for this
>>>>> situation, even with a debugger.
>>>>>
>>>>> Are there any tests which actually manage to hit every line of code?
>>>>
>>>> No. There is too much code that is dependent on low-level details of
>>>> the GC used, the compilation strategy, plus the set of runtime flags
>>>> used (and whether product or fastdebug). That's why we have lots of
>>>> tests run in lots of different ways, to try to get coverage.
>>>>
>>>>> How should I handle this situation where I can't rely on the tests 
>>>>> that
>>>>> I have run to tell me if I have missed something?
>>>>> At what point can I assume that everything is OK?
>>>>
>>>> Difficult to answer in general - there are a number of recommended
>>>> test suites used by the runtime team, but your changes will also
>>>> impact GC and compiler code and so may not get exercised by the
>>>> runtime test suites (unless run with various compiler and GC options).
>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push after the
>>>> weekly snapshot so as to maximise nightly testing, and if there are
>>>> issues exposed then you have time to address them or revert the fix.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Max Ockner
>>>>>
>>>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>>>> Hi Max,
>>>>>>
>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>>>> Hello all,
>>>>>>> I have made these additonal changes:
>>>>>>> -Moved the assert() statements into the lock and
>>>>>>> lock_without_safepoint
>>>>>>> methods.
>>>>>>> -Changed Monitor::SafepointAllowed to 
>>>>>>> Monitor::SafepointCheckRequired
>>>>>>> -Changed the Monitor::SafepointCheckRequired values for several 
>>>>>>> locks
>>>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>>>> MutexLocker, some were locked were locked without any 
>>>>>>> MutexLocker* )
>>>>>>>
>>>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>>>
>>>>>> Generally this is all okay - a few style and other nits below.
>>>>>>
>>>>>> However you missed adding an assert in Monitor::wait to check if the
>>>>>> no_safepoint_check flag was being used correctly for the current
>>>>>> monitor.
>>>>>>
>>>>>> Specific comments:
>>>>>>
>>>>>> src/share/vm/runtime/mutex.hpp
>>>>>>
>>>>>> This comment is no longer accurate with the moved check location:
>>>>>>
>>>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>>>> + // to ensure consistent checking for each lock.
>>>>>>
>>>>>> The same goes for other references to MutexLockerEx in the enum
>>>>>> description.
>>>>>>
>>>>>> Also copyright year needs updating.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutex.cpp
>>>>>>
>>>>>>  898   //Ensure
>>>>>>  961   //Ensure
>>>>>>
>>>>>> Space needed after //
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>>
>>>>>> +  var = new type(Mutex::pri, #var,
>>>>>> vm_block,safepoint_check_allowed); \
>>>>>>
>>>>>> space needed after comma in k,s
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>>>
>>>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Additional testing:
>>>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>>>> jtreg jfr tests
>>>>>>>
>>>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>>>
>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>>> "SLTMonitor" 
>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>>> "CompactibleFreeListSpace._lock"
>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "freelist par lock"
>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>>
>>>>>>> The remaining "sometimes" locks can be found in
>>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>>
>>>>>>> ParGCRareEvent_lock
>>>>>>> Safepoint_lock
>>>>>>> Threads_lock
>>>>>>> VMOperationQueue_lock
>>>>>>> VMOperationRequest_lock
>>>>>>> Terminator_lock
>>>>>>> Heap_lock
>>>>>>> Compile_lock
>>>>>>> PeriodicTask_lock
>>>>>>> JfrStacktrace_lock
>>>>>>>
>>>>>>> I have not checked the validity of the "sometimes" locks, and I
>>>>>>> believe
>>>>>>> that this should be a different project.
>>>>>>>
>>>>>>> Thanks for your help!
>>>>>>> Max Ockner
>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>>>> Hi Max,
>>>>>>>>
>>>>>>>> This is looking good.
>>>>>>>>
>>>>>>>> A few high-level initial comments:
>>>>>>>>
>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>>>
>>>>>>>> Why are the checks in MutexLocker when the state is maintained 
>>>>>>>> in the
>>>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>>>> check in the mutex/monitor methods.
>>>>>>>>
>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is good.
>>>>>>>> But
>>>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>>>> safepoints should never be held when a thread blocks at a 
>>>>>>>> safepoint -
>>>>>>>> is there some way to easily check that? I was surprised how many
>>>>>>>> locks
>>>>>>>> are actually not checking for safepoints.
>>>>>>>>
>>>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>>>> inconsistently and incorrectly?
>>>>>>>>
>>>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>>>> Threads_lock with a safepoint check and a safepoint has been
>>>>>>>> requested
>>>>>>>> :) ).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>>>
>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or 
>>>>>>>>> without a
>>>>>>>>> safepoint check.
>>>>>>>>> In some cases, a particular lock must either safepoint check
>>>>>>>>> always or
>>>>>>>>> never to avoid deadlocking.
>>>>>>>>> Some other locks have semantics which allow them to avoid 
>>>>>>>>> deadlocks
>>>>>>>>> despite having a safepoint check only some of the time.
>>>>>>>>> All locks that are OK having inconsistent safepoint checks 
>>>>>>>>> have been
>>>>>>>>> marked. All locks that should never safepoint check and all locks
>>>>>>>>> that
>>>>>>>>> should always safepoint check have also been marked.
>>>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>>>> check,
>>>>>>>>> the lock's safepointAllowed marker is checked to ensure 
>>>>>>>>> consistent
>>>>>>>>> safepoint checking.
>>>>>>>>>
>>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>>>
>>>>>>>>> Tested with:
>>>>>>>>>      jprt "-testset hotspot"
>>>>>>>>>      jtreg hotspot
>>>>>>>>>      vm.quick.testlist
>>>>>>>>>
>>>>>>>>> Whitebox tests:
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: 
>>>>>>>>> Test
>>>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: 
>>>>>>>>> Test
>>>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: 
>>>>>>>>> code
>>>>>>>>> should not assert. (Lock is properly acquired with no safepoint
>>>>>>>>> check)
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: 
>>>>>>>>> code
>>>>>>>>> should not assert. (Lock is properly acquired with safepoint 
>>>>>>>>> check)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>


From daniel.daugherty at oracle.com  Wed Dec 10 21:11:33 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 10 Dec 2014 14:11:33 -0700
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <54887B57.2050201@oracle.com>
References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com>
	<545CF033.4010503@oracle.com> <54619729.30704@oracle.com>
	<546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com>
	<5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com>
	<54887B57.2050201@oracle.com>
Message-ID: <5488B705.6060203@oracle.com>

On 12/10/14 9:56 AM, Max Ockner wrote:
> New webrev: http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/

Thumbs up! No need for a re-review if you address any of the
formatting comments below.

Repeat from last time (I've seen trailing white space in this
round; haven't checked for the other jcheck-ish things).

- jcheck is going to complain about some of your lines that
   have trailing white space:

   $ grep -n '  *$' `cat files.list`
   $ grep -n '\t' `cat files.list`

   Don't know if you have any tabs, but I included that one also.
   Not all platforms like '\t' for the grep parameter.

- jcheck may also complain about the blank lines at the end
   of the new tests

src/share/vm/runtime/mutex.hpp
     line 197:           SafepointCheckRequired safepoint_check_required 
=  _safepoint_check_always);
         One space too many after the '='.

         Also, I see an extra space at the end of the line; jcheck
         will not be happy.

src/share/vm/runtime/mutex.cpp
     No comments.

src/share/vm/runtime/mutexLocker.cpp
     line 174:   }
         Should be moved left by two spaces (i.e., one indent to the
         left of the code block above it).

src/share/vm/runtime/thread.cpp
     No comments.

src/share/vm/runtime/vmThread.cpp
     No comments.

src/os/aix/vm/osThread_aix.cpp
     No comments.

src/os/bsd/vm/osThread_bsd.cpp
     No comments.

src/os/linux/vm/osThread_linux.cpp
     No comments.

src/share/vm/classfile/classLoaderData.cpp
     No comments.

src/share/vm/memory/metaspace.cpp
     No comments.

src/share/vm/runtime/vm_operations.cpp
     No comments.

src/share/vm/memory/sharedHeap.cpp
     No comments.

src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
     No comments.

src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
     line 6391:   _lock(mutex_rank >= 0 ? new Mutex(mutex_rank, 
mutex_name, true ,
         Extra space before the last comma.

src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
     No comments.

src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
     No comments.

src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
     No comments.

src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
     No comments.

src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
     No comments.

src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
     No comments.

src/share/vm/services/diagnosticFramework.cpp
     No comments.

src/share/vm/services/memoryManager.cpp
     No comments.

src/share/vm/utilities/decoder.cpp
     No comments.

src/share/vm/utilities/events.hpp
     No comments.

src/share/vm/utilities/workgroup.cpp
     No comments.

src/share/vm/prims/whitebox.cpp
     line 1045: WB_END
         Please add a blank line after this line.

test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
     No comments.

test/runtime/Safepoint/AssertSafepointCheckConsistency1.java
     line 42: WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, 
true);
         Java code indent is four spaces.

test/runtime/Safepoint/AssertSafepointCheckConsistency2.java
     line 42: WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, 
false);
         Java code indent is four spaces.

test/runtime/Safepoint/AssertSafepointCheckConsistency3.java
     line 42: WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, 
true);
         Java code indent is four spaces.

test/runtime/Safepoint/AssertSafepointCheckConsistency4.java
     line 42: WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, 
false);
         Java code indent is four spaces.

Dan



>
> I have addressed dan's suggestions. I also removed unnecessary 
> "this->" occurrences from the assert statements.
>
> Though I realize that I have unnecessarily duplicated code in my 
> tests, I do not want to combine the tests into one right now because 
> (1) They work as they are, (2) They can fail independently, (3) The 
> amount of code needed to run all four tests in one file without 
> crashing out after the first failure is not as small as you might 
> think, and (4) I want to commit this before someone else messes with 
> the locks to avoid more merge conflicts. To be clear, I am not opposed 
> to fixing this separately if people think it is important, but I 
> prefer to put it off until the bulk of the fix is committed.
>
> Does this look ready?
>
> Thanks for your help,
> Max O
>
>
>
> On 12/8/2014 1:39 AM, David Holmes wrote:
>> Hi Max,
>>
>> Just a nit with the tests - it seems to me we should be able to write 
>> a single Java class that can process all four combinations rather 
>> than duplicating the bulk of the code.
>>
>> Thanks,
>> David
>>
>> On 5/12/2014 7:50 AM, Max Ockner wrote:
>>> Hello once again...
>>> I have a new (and suggestively titled) webrev:
>>> http://cr.openjdk.java.net/~coleenp/8047290final/
>>>
>>> Ran aurora tests.
>>>
>>> Here is a list of "sometimes" locks:
>>>
>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>> "CompactibleFreeListSpace._lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>
>>> "freelist par lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>
>>> "SR_lock" share/vm/runtime/thread.cpp
>>> "CMS_markBitMap_lock"
>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 
>>>
>>>
>>>
>>> The remaining "sometimes" locks can be found in
>>> share/vm/runtime/mutexLocker.cpp:
>>>
>>> ParGCRareEvent_lock
>>> Safepoint_lock
>>> Threads_lock
>>> VMOperationQueue_lock
>>> VMOperationRequest_lock
>>> Terminator_lock
>>> Heap_lock
>>> Compile_lock
>>> PeriodicTask_lock
>>> JfrStacktrace_lock
>>>
>>>
>>> Thanks,
>>> Max Ockner
>>>
>>>
>>>
>>>
>>> On 11/25/2014 3:03 AM, David Holmes wrote:
>>>> Hi Max,
>>>>
>>>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>>>> Hello again,
>>>>>
>>>>> I have made changes based on all comments. There is now a pair of 
>>>>> assert
>>>>> statements in the Monitor/Mutex wait() methods. When I reran tests, I
>>>>
>>>> Is there an updated webrev?
>>>>
>>>>> caught another lock that I had to change to "sometimes", but the 
>>>>> assert
>>>>> that caught this lock was not in wait. There are currently no 
>>>>> locks that
>>>>> use try to pass an incorrect safepoint check argument to wait().
>>>>> Instead, gcbasher did not catch this lock last time, when the only
>>>>> asserts were in lock and lock_without_safepoint. This lock is
>>>>> "CMS_markBitMap_lock" in
>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. 
>>>>>
>>>>>
>>>>> I'm guessing that it was not caught by the tests because this 
>>>>> section of
>>>>> code is not reached very often. My initial inspection failed to catch
>>>>> this lock because it is passed around between various structures and
>>>>> renamed 4 times. I have not yet found a good way to check for this
>>>>> situation, even with a debugger.
>>>>>
>>>>> Are there any tests which actually manage to hit every line of code?
>>>>
>>>> No. There is too much code that is dependent on low-level details of
>>>> the GC used, the compilation strategy, plus the set of runtime flags
>>>> used (and whether product or fastdebug). That's why we have lots of
>>>> tests run in lots of different ways, to try to get coverage.
>>>>
>>>>> How should I handle this situation where I can't rely on the tests 
>>>>> that
>>>>> I have run to tell me if I have missed something?
>>>>> At what point can I assume that everything is OK?
>>>>
>>>> Difficult to answer in general - there are a number of recommended
>>>> test suites used by the runtime team, but your changes will also
>>>> impact GC and compiler code and so may not get exercised by the
>>>> runtime test suites (unless run with various compiler and GC options).
>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push after the
>>>> weekly snapshot so as to maximise nightly testing, and if there are
>>>> issues exposed then you have time to address them or revert the fix.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Max Ockner
>>>>>
>>>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>>>> Hi Max,
>>>>>>
>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>>>> Hello all,
>>>>>>> I have made these additonal changes:
>>>>>>> -Moved the assert() statements into the lock and
>>>>>>> lock_without_safepoint
>>>>>>> methods.
>>>>>>> -Changed Monitor::SafepointAllowed to 
>>>>>>> Monitor::SafepointCheckRequired
>>>>>>> -Changed the Monitor::SafepointCheckRequired values for several 
>>>>>>> locks
>>>>>>> which were locked outside of a MutexLockerEx (some were locked with
>>>>>>> MutexLocker, some were locked were locked without any 
>>>>>>> MutexLocker* )
>>>>>>>
>>>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>>>
>>>>>> Generally this is all okay - a few style and other nits below.
>>>>>>
>>>>>> However you missed adding an assert in Monitor::wait to check if the
>>>>>> no_safepoint_check flag was being used correctly for the current
>>>>>> monitor.
>>>>>>
>>>>>> Specific comments:
>>>>>>
>>>>>> src/share/vm/runtime/mutex.hpp
>>>>>>
>>>>>> This comment is no longer accurate with the moved check location:
>>>>>>
>>>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>>>> + // to ensure consistent checking for each lock.
>>>>>>
>>>>>> The same goes for other references to MutexLockerEx in the enum
>>>>>> description.
>>>>>>
>>>>>> Also copyright year needs updating.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutex.cpp
>>>>>>
>>>>>>  898   //Ensure
>>>>>>  961   //Ensure
>>>>>>
>>>>>> Space needed after //
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>>
>>>>>> +  var = new type(Mutex::pri, #var,
>>>>>> vm_block,safepoint_check_allowed); \
>>>>>>
>>>>>> space needed after comma in k,s
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>>>
>>>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Additional testing:
>>>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>>>> jtreg jfr tests
>>>>>>>
>>>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>>>
>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>>> "SLTMonitor" 
>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>>> "CompactibleFreeListSpace._lock"
>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "freelist par lock"
>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>>
>>>>>>> The remaining "sometimes" locks can be found in
>>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>>
>>>>>>> ParGCRareEvent_lock
>>>>>>> Safepoint_lock
>>>>>>> Threads_lock
>>>>>>> VMOperationQueue_lock
>>>>>>> VMOperationRequest_lock
>>>>>>> Terminator_lock
>>>>>>> Heap_lock
>>>>>>> Compile_lock
>>>>>>> PeriodicTask_lock
>>>>>>> JfrStacktrace_lock
>>>>>>>
>>>>>>> I have not checked the validity of the "sometimes" locks, and I
>>>>>>> believe
>>>>>>> that this should be a different project.
>>>>>>>
>>>>>>> Thanks for your help!
>>>>>>> Max Ockner
>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>>>> Hi Max,
>>>>>>>>
>>>>>>>> This is looking good.
>>>>>>>>
>>>>>>>> A few high-level initial comments:
>>>>>>>>
>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>>>
>>>>>>>> Why are the checks in MutexLocker when the state is maintained 
>>>>>>>> in the
>>>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, and
>>>>>>>> wait(<safepoint checking flag>) ? I would have expected to see the
>>>>>>>> check in the mutex/monitor methods.
>>>>>>>>
>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is good.
>>>>>>>> But
>>>>>>>> another part of this is that a monitor/mutex that never checks for
>>>>>>>> safepoints should never be held when a thread blocks at a 
>>>>>>>> safepoint -
>>>>>>>> is there some way to easily check that? I was surprised how many
>>>>>>>> locks
>>>>>>>> are actually not checking for safepoints.
>>>>>>>>
>>>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>>>> inconsistently and incorrectly?
>>>>>>>>
>>>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>>>> Threads_lock with a safepoint check and a safepoint has been
>>>>>>>> requested
>>>>>>>> :) ).
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>>>
>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or 
>>>>>>>>> without a
>>>>>>>>> safepoint check.
>>>>>>>>> In some cases, a particular lock must either safepoint check
>>>>>>>>> always or
>>>>>>>>> never to avoid deadlocking.
>>>>>>>>> Some other locks have semantics which allow them to avoid 
>>>>>>>>> deadlocks
>>>>>>>>> despite having a safepoint check only some of the time.
>>>>>>>>> All locks that are OK having inconsistent safepoint checks 
>>>>>>>>> have been
>>>>>>>>> marked. All locks that should never safepoint check and all locks
>>>>>>>>> that
>>>>>>>>> should always safepoint check have also been marked.
>>>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>>>> check,
>>>>>>>>> the lock's safepointAllowed marker is checked to ensure 
>>>>>>>>> consistent
>>>>>>>>> safepoint checking.
>>>>>>>>>
>>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>>>
>>>>>>>>> Tested with:
>>>>>>>>>      jprt "-testset hotspot"
>>>>>>>>>      jtreg hotspot
>>>>>>>>>      vm.quick.testlist
>>>>>>>>>
>>>>>>>>> Whitebox tests:
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: 
>>>>>>>>> Test
>>>>>>>>> expects Assert ("This lock should always have a safepoint check")
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: 
>>>>>>>>> Test
>>>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: 
>>>>>>>>> code
>>>>>>>>> should not assert. (Lock is properly acquired with no safepoint
>>>>>>>>> check)
>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: 
>>>>>>>>> code
>>>>>>>>> should not assert. (Lock is properly acquired with safepoint 
>>>>>>>>> check)
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>


From jesper.wilhelmsson at oracle.com  Thu Dec 11 00:26:55 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 11 Dec 2014 01:26:55 +0100
Subject: Disallow flags with extra characters appended
In-Reply-To: <5481B580.9000807@oracle.com>
References: <54810CB1.2060207@oracle.com>	<54812AA1.10308@oracle.com>	<54816C8A.1000401@oracle.com>	<54817D16.9000609@oracle.com>	<54817E58.4040208@oracle.com>
	<5481B580.9000807@oracle.com>
Message-ID: <5488E4CF.1050409@oracle.com>

Update:

The bug has now been reopened with Christian T?rnqvist's blessing.

David, did you have further comments on the updated version?
(Link from the review thread in the runtime list:
http://cr.openjdk.java.net/~jwilhelm/6522873/webrev.00/ )

Thanks!
/Jesper


Jesper Wilhelmsson skrev 5/12/14 14:39:
> Hi,
>
> In the hope that JDK-6522873 will be reopened I'm sending a proper RFR to the
> runtime list. Thanks David for your initial review, I have updated the change as
> you suggested. I also found a few more flags that should be covered by this
> change. A full list of flags is available in the RFR.
>
> Thanks,
> /Jesper
>
> Ioi Lam skrev 5/12/14 10:43:
>>
>> On 12/5/14, 1:38 AM, David Holmes wrote:
>>> On 5/12/2014 6:27 PM, Jesper Wilhelmsson wrote:
>>>> Hi David,
>>>>
>>>> Thanks for the pointer to JDK-6522873!
>>>>
>>>> Not fixing this with the motivation "due to the risk of breaking
>>>> existing applications/scripts that already has the incorrect options
>>>> specified" is ridiculous imho.
>>>>
>>>> As I wrote in the bug just now:
>>>> We have to stop being so scared about fixing bugs. Fixing a bug like
>>>> this in a major version (9) should cause minimal problems since people
>>>> will have to re-certify their applications and change the command lines
>>>> anyway to upgrade from 8 to 9.
>>>>
>>>> Fixing this bug will make some people go "Oh, I made a typo" and fix it.
>>>> Not fixing this bug will make people go "Hey, we have been running with
>>>> the wrong settings for two years!! Why didn't this $#%@#$# VM say
>>>> something?!?!"
>>>
>>> I tend to agree that fixing this in a major release like 9 seems to be not
>>> unreasonable. However it is easy to under estimate the compatibility aspect of
>>> simple changes - even though that can be very frustrating. Given most of the
>>> -X options are pretty useless I don't see this as likely being a major
>>> problem. Even so I come down slightly on the side of fixing it.
>>>
>>> And as you note 4514888 already fixed this in 5 and we seem to have regressed
>>> since then.
>>>
>> I think it's reasonable to fix for 9. Since there's a compatibility concern, we
>> should get a CCC approval. Also, maybe a
>> -XX:+DontComplainAboutRubbishAfterOptionsSinceIamTooLazyToFixMyScripts flag for
>> backwards compatibility? People who are truly lazy can just add this in their
>> JAVA_OPTS environment variable.
>>
>> - Ioi
>>> David
>>>
>>>> Dear runtime team, please consider reopening this bug.
>>>>
>>>> Thanks,
>>>> /Jesper
>>>>
>>>>
>>>> David Holmes skrev 5/12/14 04:46:
>>>>> Hi Jesper,
>>>>>
>>>>> On 5/12/2014 11:38 AM, Jesper Wilhelmsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Today some (not all) flags are accepted even though they have random
>>>>>> characters appended to them. Some examples are -Xconcgc, -Xcomp,
>>>>>> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted when
>>>>>> written for instance -Xconcgcnoway, -Xcomposer, -Xboundthreadstodogs or
>>>>>> -XX:+AlwaysTenureAtBlueMoon
>>>>>>
>>>>>> There is a potential problem here since we will also accept things like
>>>>>> -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of
>>>>>> course without running with G1).
>>>>>>
>>>>>> I have a suggestion for a fix here:
>>>>>> http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/
>>>>>>
>>>>>> Would this be an acceptable solution?
>>>>>
>>>>> I'm somewhat surprised the single name version of match_option didn't
>>>>> also have the _tail_allowed flag - seems rather unbalanced. But what
>>>>> you have is cleaner I think. Though I would suggest moving you new
>>>>> version:
>>>>>
>>>>>  static bool match_option(const JavaVMOption *option, const char* name) {
>>>>>
>>>>> to immediately after the tail version (and before the _tail_allowed
>>>>> multi-name version), which a suitable comment added.
>>>>>
>>>>> That said ...
>>>>>
>>>>>> I couldn't find one, but since this has been around for quite some time
>>>>>> I wonder if there is a bug for this already. If not I'll create one.
>>>>>
>>>>> ... this has already been rejected
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-6522873
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thanks,
>>>>>> /Jesper
>>>>>>
>>>>
>>

From david.holmes at oracle.com  Thu Dec 11 01:30:58 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 11 Dec 2014 11:30:58 +1000
Subject: Disallow flags with extra characters appended
In-Reply-To: <5488E4CF.1050409@oracle.com>
References: <54810CB1.2060207@oracle.com>	<54812AA1.10308@oracle.com>	<54816C8A.1000401@oracle.com>	<54817D16.9000609@oracle.com>	<54817E58.4040208@oracle.com>
	<5481B580.9000807@oracle.com> <5488E4CF.1050409@oracle.com>
Message-ID: <5488F3D2.3020004@oracle.com>

On 11/12/2014 10:26 AM, Jesper Wilhelmsson wrote:
> Update:
>
> The bug has now been reopened with Christian T?rnqvist's blessing.
>
> David, did you have further comments on the updated version?

No. I just replied to the review thread. Sorry it slipped through the 
cracks.

David

> (Link from the review thread in the runtime list:
> http://cr.openjdk.java.net/~jwilhelm/6522873/webrev.00/ )
>
> Thanks!
> /Jesper
>
>
> Jesper Wilhelmsson skrev 5/12/14 14:39:
>> Hi,
>>
>> In the hope that JDK-6522873 will be reopened I'm sending a proper RFR
>> to the
>> runtime list. Thanks David for your initial review, I have updated the
>> change as
>> you suggested. I also found a few more flags that should be covered by
>> this
>> change. A full list of flags is available in the RFR.
>>
>> Thanks,
>> /Jesper
>>
>> Ioi Lam skrev 5/12/14 10:43:
>>>
>>> On 12/5/14, 1:38 AM, David Holmes wrote:
>>>> On 5/12/2014 6:27 PM, Jesper Wilhelmsson wrote:
>>>>> Hi David,
>>>>>
>>>>> Thanks for the pointer to JDK-6522873!
>>>>>
>>>>> Not fixing this with the motivation "due to the risk of breaking
>>>>> existing applications/scripts that already has the incorrect options
>>>>> specified" is ridiculous imho.
>>>>>
>>>>> As I wrote in the bug just now:
>>>>> We have to stop being so scared about fixing bugs. Fixing a bug like
>>>>> this in a major version (9) should cause minimal problems since people
>>>>> will have to re-certify their applications and change the command
>>>>> lines
>>>>> anyway to upgrade from 8 to 9.
>>>>>
>>>>> Fixing this bug will make some people go "Oh, I made a typo" and
>>>>> fix it.
>>>>> Not fixing this bug will make people go "Hey, we have been running
>>>>> with
>>>>> the wrong settings for two years!! Why didn't this $#%@#$# VM say
>>>>> something?!?!"
>>>>
>>>> I tend to agree that fixing this in a major release like 9 seems to
>>>> be not
>>>> unreasonable. However it is easy to under estimate the compatibility
>>>> aspect of
>>>> simple changes - even though that can be very frustrating. Given
>>>> most of the
>>>> -X options are pretty useless I don't see this as likely being a major
>>>> problem. Even so I come down slightly on the side of fixing it.
>>>>
>>>> And as you note 4514888 already fixed this in 5 and we seem to have
>>>> regressed
>>>> since then.
>>>>
>>> I think it's reasonable to fix for 9. Since there's a compatibility
>>> concern, we
>>> should get a CCC approval. Also, maybe a
>>> -XX:+DontComplainAboutRubbishAfterOptionsSinceIamTooLazyToFixMyScripts flag
>>> for
>>> backwards compatibility? People who are truly lazy can just add this
>>> in their
>>> JAVA_OPTS environment variable.
>>>
>>> - Ioi
>>>> David
>>>>
>>>>> Dear runtime team, please consider reopening this bug.
>>>>>
>>>>> Thanks,
>>>>> /Jesper
>>>>>
>>>>>
>>>>> David Holmes skrev 5/12/14 04:46:
>>>>>> Hi Jesper,
>>>>>>
>>>>>> On 5/12/2014 11:38 AM, Jesper Wilhelmsson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Today some (not all) flags are accepted even though they have random
>>>>>>> characters appended to them. Some examples are -Xconcgc, -Xcomp,
>>>>>>> -Xboundthreads, -XX:+AlwaysTenure etc which will also be accepted
>>>>>>> when
>>>>>>> written for instance -Xconcgcnoway, -Xcomposer,
>>>>>>> -Xboundthreadstodogs or
>>>>>>> -XX:+AlwaysTenureAtBlueMoon
>>>>>>>
>>>>>>> There is a potential problem here since we will also accept
>>>>>>> things like
>>>>>>> -XX:+ExtendedDTraceProbes-XX:+UseG1GC without saying a word (and of
>>>>>>> course without running with G1).
>>>>>>>
>>>>>>> I have a suggestion for a fix here:
>>>>>>> http://cr.openjdk.java.net/~jwilhelm/commandLineFlag/webrev.00/
>>>>>>>
>>>>>>> Would this be an acceptable solution?
>>>>>>
>>>>>> I'm somewhat surprised the single name version of match_option didn't
>>>>>> also have the _tail_allowed flag - seems rather unbalanced. But what
>>>>>> you have is cleaner I think. Though I would suggest moving you new
>>>>>> version:
>>>>>>
>>>>>>  static bool match_option(const JavaVMOption *option, const char*
>>>>>> name) {
>>>>>>
>>>>>> to immediately after the tail version (and before the _tail_allowed
>>>>>> multi-name version), which a suitable comment added.
>>>>>>
>>>>>> That said ...
>>>>>>
>>>>>>> I couldn't find one, but since this has been around for quite
>>>>>>> some time
>>>>>>> I wonder if there is a bug for this already. If not I'll create one.
>>>>>>
>>>>>> ... this has already been rejected
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-6522873
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Thanks,
>>>>>>> /Jesper
>>>>>>>
>>>>>
>>>

From vladimir.kozlov at oracle.com  Thu Dec 11 04:24:23 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 10 Dec 2014 20:24:23 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5488B0A3.7020003@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
Message-ID: <54891C77.2080404@oracle.com>

On 12/10/14 12:44 PM, Andrew Haley wrote:
> On 12/10/2014 08:27 PM, David Holmes wrote:
>> If I had paid more attention to this earlier I would have suggested
>> reversing the sense of the UseBarriersForVolatile flag
>> (ElideBarriersForVolatiles?) because it makes it seem like using
>> barriers for volatiles is experimental - which of course it isn't.
>
> OK.
>
>> Also this seems C2 specific so shouldn't it be defined in c2_globals.hpp?
>
> Sure.  This is the Patch That Never Ends, after all.  :-)
>
> Let's see what the other reviewers say, and I'll wrap it all together.
>
> Thanks,
> Andrew.
>

I agree with David about reversing flag and putting it into c2_globals.hpp. But, please, confirm that you left volatile 
barriers generated by C1 compiler (in c1_LIR_Generator.cpp) as they are - I don't see any changes there.

One thing left is barriers for volatile loads - there is inconsistency of code in library_call.cpp and parse3.cpp. We 
discussed it already before.
If you want to remove MemBarAcquire for volatile loads then, please, also change code in Parse::do_get_xxx() in parse3.cpp.
If not, the code in library_call.cpp should avoid membars only for stores:

      // For Stores, place a memory ordering barrier now.
      if (is_store) {
-      insert_mem_bar(Op_MemBarRelease);
+      insert_mem_bar(ElideBarriersForVolatiles ? Op_MemBarCPUOrder : Op_MemBarRelease);
      } else {
        if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
          insert_mem_bar(Op_MemBarVolatile);
        }
      }


    if (is_volatile) {
      if (!is_store) {
        insert_mem_bar(Op_MemBarAcquire);
      } else {
        if (!support_IRIW_for_not_multiple_copy_atomic_cpu) {
-        insert_mem_bar(Op_MemBarVolatile);
+        insert_mem_bar(ElideBarriersForVolatiles ? Op_MemBarCPUOrder : Op_MemBarVolatile);
        }
      }
    }


Thanks,
Vladimir


From dean.long at oracle.com  Thu Dec 11 05:58:15 2014
From: dean.long at oracle.com (Dean Long)
Date: Wed, 10 Dec 2014 21:58:15 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54891C77.2080404@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>	<54883895.1000609@redhat.com>
	<54885DA7.4010003@redhat.com>	<5488ACC3.9070404@oracle.com>
	<5488B0A3.7020003@redhat.com> <54891C77.2080404@oracle.com>
Message-ID: <54893277.6020609@oracle.com>

On 12/10/2014 8:24 PM, Vladimir Kozlov wrote:
> On 12/10/14 12:44 PM, Andrew Haley wrote:
>> On 12/10/2014 08:27 PM, David Holmes wrote:
>>> If I had paid more attention to this earlier I would have suggested
>>> reversing the sense of the UseBarriersForVolatile flag
>>> (ElideBarriersForVolatiles?) because it makes it seem like using
>>> barriers for volatiles is experimental - which of course it isn't.
>>
>> OK.
>>
>>> Also this seems C2 specific so shouldn't it be defined in 
>>> c2_globals.hpp?
>>
>> Sure.  This is the Patch That Never Ends, after all.  :-)
>>
>> Let's see what the other reviewers say, and I'll wrap it all together.
>>
>> Thanks,
>> Andrew.
>>
>
> I agree with David about reversing flag and putting it into 
> c2_globals.hpp. But, please, confirm that you left volatile barriers 
> generated by C1 compiler (in c1_LIR_Generator.cpp) as they are - I 
> don't see any changes there.
>
> One thing left is barriers for volatile loads - there is inconsistency 
> of code in library_call.cpp and parse3.cpp. We discussed it already 
> before.
> If you want to remove MemBarAcquire for volatile loads then, please, 
> also change code in Parse::do_get_xxx() in parse3.cpp.

Let me see if I'm on the same page.  Would that be something like:

  272   // If reference is volatile, prevent following memory ops from
  273   // floating up past the volatile read.  Also prevents commoning
  274   // another volatile read.
  275   if (field->is_volatile()) {
  276     // Memory barrier includes bogus read of value to force load BEFORE membar
  277     insert_mem_bar(ElideBarriersForVolatiles ? Op_MemBarCPUOrder : Op_MemBarAcquire, ld);
  278   }

?  Does the "bogus read" comment and extra "ld" arg still apply if 
Op_MemBarCPUOrder is used?

dl

> If not, the code in library_call.cpp should avoid membars only for 
> stores:
>
>      // For Stores, place a memory ordering barrier now.
>      if (is_store) {
> -      insert_mem_bar(Op_MemBarRelease);
> +      insert_mem_bar(ElideBarriersForVolatiles ? Op_MemBarCPUOrder : 
> Op_MemBarRelease);
>      } else {
>        if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>          insert_mem_bar(Op_MemBarVolatile);
>        }
>      }
>
>
>    if (is_volatile) {
>      if (!is_store) {
>        insert_mem_bar(Op_MemBarAcquire);
>      } else {
>        if (!support_IRIW_for_not_multiple_copy_atomic_cpu) {
> -        insert_mem_bar(Op_MemBarVolatile);
> +        insert_mem_bar(ElideBarriersForVolatiles ? Op_MemBarCPUOrder 
> : Op_MemBarVolatile);
>        }
>      }
>    }
>
>
> Thanks,
> Vladimir
>


From vladimir.kozlov at oracle.com  Thu Dec 11 06:44:57 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 10 Dec 2014 22:44:57 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54893277.6020609@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>	<54883895.1000609@redhat.com>
	<54885DA7.4010003@redhat.com>	<5488ACC3.9070404@oracle.com>
	<5488B0A3.7020003@redhat.com> <54891C77.2080404@oracle.com>
	<54893277.6020609@oracle.com>
Message-ID: <54893D69.1080609@oracle.com>

On 12/10/14 9:58 PM, Dean Long wrote:
> On 12/10/2014 8:24 PM, Vladimir Kozlov wrote:
>> On 12/10/14 12:44 PM, Andrew Haley wrote:
>>> On 12/10/2014 08:27 PM, David Holmes wrote:
>>>> If I had paid more attention to this earlier I would have suggested
>>>> reversing the sense of the UseBarriersForVolatile flag
>>>> (ElideBarriersForVolatiles?) because it makes it seem like using
>>>> barriers for volatiles is experimental - which of course it isn't.
>>>
>>> OK.
>>>
>>>> Also this seems C2 specific so shouldn't it be defined in c2_globals.hpp?
>>>
>>> Sure.  This is the Patch That Never Ends, after all.  :-)
>>>
>>> Let's see what the other reviewers say, and I'll wrap it all together.
>>>
>>> Thanks,
>>> Andrew.
>>>
>>
>> I agree with David about reversing flag and putting it into c2_globals.hpp. But, please, confirm that you left
>> volatile barriers generated by C1 compiler (in c1_LIR_Generator.cpp) as they are - I don't see any changes there.
>>
>> One thing left is barriers for volatile loads - there is inconsistency of code in library_call.cpp and parse3.cpp. We
>> discussed it already before.
>> If you want to remove MemBarAcquire for volatile loads then, please, also change code in Parse::do_get_xxx() in
>> parse3.cpp.
>
> Let me see if I'm on the same page.  Would that be something like:
>
>   272   // If reference is volatile, prevent following memory ops from
>   273   // floating up past the volatile read.  Also prevents commoning
>   274   // another volatile read.
>   275   if (field->is_volatile()) {
>   276     // Memory barrier includes bogus read of value to force load BEFORE membar
>   277     insert_mem_bar(ElideBarriersForVolatiles ? Op_MemBarCPUOrder : Op_MemBarAcquire, ld);
>   278   }
>
> ?  Does the "bogus read" comment and extra "ld" arg still apply if Op_MemBarCPUOrder is used?

It is there to be able remove membar if an object from which we load does not escape. See MemBarNode::Ideal().
So we can extend MemBarNode::Ideal() for MemBarCPUOrder case. Or don't add edge to 'ld' from the start - I think it is 
preferable.

Vladimir

>
> dl
>
>> If not, the code in library_call.cpp should avoid membars only for stores:
>>
>>      // For Stores, place a memory ordering barrier now.
>>      if (is_store) {
>> -      insert_mem_bar(Op_MemBarRelease);
>> +      insert_mem_bar(ElideBarriersForVolatiles ? Op_MemBarCPUOrder : Op_MemBarRelease);
>>      } else {
>>        if (support_IRIW_for_not_multiple_copy_atomic_cpu) {
>>          insert_mem_bar(Op_MemBarVolatile);
>>        }
>>      }
>>
>>
>>    if (is_volatile) {
>>      if (!is_store) {
>>        insert_mem_bar(Op_MemBarAcquire);
>>      } else {
>>        if (!support_IRIW_for_not_multiple_copy_atomic_cpu) {
>> -        insert_mem_bar(Op_MemBarVolatile);
>> +        insert_mem_bar(ElideBarriersForVolatiles ? Op_MemBarCPUOrder : Op_MemBarVolatile);
>>        }
>>      }
>>    }
>>
>>
>> Thanks,
>> Vladimir
>>
>

From bengt.rutisson at oracle.com  Thu Dec 11 08:12:13 2014
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 11 Dec 2014 09:12:13 +0100
Subject: RFR: 8062672: JVM crashes during GC on various asserts which
	checks that HeapWord ptr is an oop
In-Reply-To: <5485B46C.2020509@oracle.com>
References: <5481825E.4080602@oracle.com> <548231FE.5090301@oracle.com>
	<5485B46C.2020509@oracle.com>
Message-ID: <548951DD.3070407@oracle.com>


Hi Stefan,

With the changes you propose based on Jon's review this looks good to me.

Thanks,
Bengt


On 12/8/14 3:23 PM, Stefan Johansson wrote:
> Thanks for looking at this Jon,
>
> On 2014-12-05 23:30, Jon Masamitsu wrote:
>> Stefan,
>>
>> Changes look good.
>>
>> Would you like to explicitly check the return from
>> fgets() against NULL?  Your call.
>>
> I see that all other while(fgets...) checks for != NULL so I will add it.
>> What do you think of an assert after the call to fgets() to
>> check the length of the returned string.
>>
>> assert(strnlen(line, 1023) < 1023, "buffer line[1024] is too small.");
>>
>> Too paranoid?
> I like adding an assert, but using strnlen feels a little paranoid 
> since fgets promise to add '\0' at the end even if the line is longer 
> than the buffer. So I plan to add this assert:
> assert(strlen(line) < sizeof(line) - 1, "buffer line[1024] is too 
> small.");
>
> Thanks,
> Stefan
>>
>> Reviewed.
>>
>> Jon
>>
>> On 12/5/2014 2:01 AM, Stefan Johansson wrote:
>>> Hi,
>>>
>>> Please review this fix for the linux-sparc issue described in:
>>> https://bugs.openjdk.java.net/browse/JDK-8062672
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~sjohanss/8062672/hotspot.00/
>>>
>>> Summary:
>>> This fix is based on 7u-dev because the most linux-sparc testing is 
>>> done for that release and also because it's unclear if we have time 
>>> to move the fix the normal way through 9 and 8u before going into 
>>> 7u. But the main reason is that it would be good to get testing of 
>>> the fix in 7u before porting it to 8u and 9.
>>>
>>> The fix it self is fairly simple, after JDK-8029190 was backported 
>>> the condition for disabling UseMemSetInBOT changed from is_niagara() 
>>> to has_blk_init(). This worked well for solaris-sparc but on 
>>> linux-sparc we previously only set the niagara feature bits, so this 
>>> change adds support for detecting blk_init support on linux-sparc.
>>>
>>> Testing:
>>> Crashes/asserts was reproducible without the fix and after the fix 
>>> none have been observed. Also verified that UseMemSetInBOT now is 
>>> set to false as it should be.
>>>
>>> Thanks,
>>> Stefan
>>
>


From tobias.hartmann at oracle.com  Thu Dec 11 08:22:18 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 11 Dec 2014 09:22:18 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <548826F8.4040100@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com>
	<>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>
	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>	<54870A75.2000008@oracle.com>
	<54873D3D.2030704@oracle.com>	<548747D4.40805@oracle.com>
	<548825F2.4010900@oracle.com>	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>
	<548826F8.4040100@oracle.com>
Message-ID: <5489543A.7020300@oracle.com>

Hi,

are you fine with these changes? We will do the renaming with a separate change.

http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/

Thanks,
Tobias

On 10.12.2014 11:56, Tobias Hartmann wrote:
> 
> On 10.12.2014 11:54, Staffan Larsen wrote:
>> I think we agreed to use jdk.test.lib as the package name (one dot more).
> 
> Yes, but as Igor suggested we postpone the renaming and first only move it.
> 
> I've also sent the wrong link. This is the right one:
> 
> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
> 
> Thanks,
> Tobias
> 
>>
>> /Staffan
>>
>>> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change
>>> is in. Here are the new webrevs for moving only:
>>>
>>> Top level repo:
>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>
>>> Hotspot repo:
>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>>
>>> If there are no objections I would like to push the change soon.
>>>
>>> Thanks,
>>> Tobias
>>>
>>> On 09.12.2014 20:04, Stefan S?rne wrote:
>>>>
>>>> Make sense.
>>>>
>>>> I am ok with delaying the name change.
>>>> There is a phase two with the bulk of the job to this anyway.
>>>> Dmitry, this is where we can have the repo discussion as well.
>>>>
>>>> I think there is an interesting part here anyway.
>>>>
>>>> Best regards,
>>>> Stefan
>>>>
>>>> Igor Ignatyev skrev 2014-12-09 19:19:
>>>>> Guys,
>>>>>
>>>>> changing Whitebox package name will cause failures in the tens tests which and
>>>>> aren't co-located w/ the product.
>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't
>>>>> want to have whitebox renamed this and next week.
>>>>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>>>>
>>>>> can we move whitebox to top repo now and do renaming later?
>>>>>
>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>>>> repository we also have to adapt the native lookup code in
>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>>>
>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>>>
>>>>>> Top level repo:
>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>>
>>>>>> Hotspot repo:
>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>>>
>>>>>> Tested on JPRT.
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>>>> +1
>>>>>>>
>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> thanks for the feedback.
>>>>>>>>>
>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>>>> library.
>>>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>>>
>>>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>>>
>>>>>>>>>>>  - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>>>    what's used in the jdk repo?
>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>>>
>>>>>>>> Now sounds like a good time to align.   :)
>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>>>>> step).
>>>>>>>> Let's go with test/lib.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>  - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>>>    all test-library classes have the same package root?
>>>>>>>>>> +1
>>>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>>>
>>>>>>>> Sounds good, the same package root is better.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>  - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>>>    proper naming scheme for test-library packages, preferably starting
>>>>>>>>>>>    with "jdk.?.
>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>>>> Whatever you prefer.
>>>>>>>>
>>>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Tobias
>>>>>>>>>
>>>>>>>>>>>> ...
>>>>>>>>>>>>
>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>>>>> the files in the jdk directory, however.
>>>>>>>>>>
>>>>>>>>>> /Staffan
>>>>>>>
>>>>>
>>>>
>>

From stefan.sarne at oracle.com  Thu Dec 11 08:33:42 2014
From: stefan.sarne at oracle.com (Stefan Sarne)
Date: Thu, 11 Dec 2014 09:33:42 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <5489543A.7020300@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com>
	<>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>
	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>	<54870A75.2000008@oracle.com>
	<54873D3D.2030704@oracle.com>	<548747D4.40805@oracle.com>
	<548825F2.4010900@oracle.com>	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>
	<548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com>
Message-ID: <548956E6.4030001@oracle.com>


Quick check  - it looks as expected with the updated paths in tests - I 
am ok with this.
But take it for what it is - I am not a reviewer.

Thanks for your patience, while we figure out how we want to do this.

Best regards,
Stefan

On 2014-12-11 09:22, Tobias Hartmann wrote:
> Hi,
>
> are you fine with these changes? We will do the renaming with a separate change.
>
> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>
> Thanks,
> Tobias
>
> On 10.12.2014 11:56, Tobias Hartmann wrote:
>> On 10.12.2014 11:54, Staffan Larsen wrote:
>>> I think we agreed to use jdk.test.lib as the package name (one dot more).
>> Yes, but as Igor suggested we postpone the renaming and first only move it.
>>
>> I've also sent the wrong link. This is the right one:
>>
>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>>
>> Thanks,
>> Tobias
>>
>>> /Staffan
>>>
>>>> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change
>>>> is in. Here are the new webrevs for moving only:
>>>>
>>>> Top level repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>
>>>> Hotspot repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>>>
>>>> If there are no objections I would like to push the change soon.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> On 09.12.2014 20:04, Stefan S?rne wrote:
>>>>> Make sense.
>>>>>
>>>>> I am ok with delaying the name change.
>>>>> There is a phase two with the bulk of the job to this anyway.
>>>>> Dmitry, this is where we can have the repo discussion as well.
>>>>>
>>>>> I think there is an interesting part here anyway.
>>>>>
>>>>> Best regards,
>>>>> Stefan
>>>>>
>>>>> Igor Ignatyev skrev 2014-12-09 19:19:
>>>>>> Guys,
>>>>>>
>>>>>> changing Whitebox package name will cause failures in the tens tests which and
>>>>>> aren't co-located w/ the product.
>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't
>>>>>> want to have whitebox renamed this and next week.
>>>>>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>>>>>
>>>>>> can we move whitebox to top repo now and do renaming later?
>>>>>>
>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>>>>> repository we also have to adapt the native lookup code in
>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>>>>
>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>>>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>>>>
>>>>>>> Top level repo:
>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>>>
>>>>>>> Hotspot repo:
>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>>>>
>>>>>>> Tested on JPRT.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>>
>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> thanks for the feedback.
>>>>>>>>>>
>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>>>>> library.
>>>>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>>>>
>>>>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>>>>
>>>>>>>>>>>>   - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>>>>     what's used in the jdk repo?
>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>>>> Now sounds like a good time to align.   :)
>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>>>>>> step).
>>>>>>>>> Let's go with test/lib.
>>>>>>>>>
>>>>>>>>>>>>   - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>>>>     all test-library classes have the same package root?
>>>>>>>>>>> +1
>>>>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>>>> Sounds good, the same package root is better.
>>>>>>>>>
>>>>>>>>>>>>   - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>>>>     proper naming scheme for test-library packages, preferably starting
>>>>>>>>>>>>     with "jdk.?.
>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>>>>> Whatever you prefer.
>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Stefan
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias
>>>>>>>>>>
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>>>>>> the files in the jdk directory, however.
>>>>>>>>>>>
>>>>>>>>>>> /Staffan


From igor.veresov at oracle.com  Thu Dec 11 08:43:56 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 11 Dec 2014 00:43:56 -0800
Subject: [8u] 8066900: Array Out Of Bounds Exception causes variable corruption
Message-ID: <2B10D236-DB6C-4F9F-91A6-36F395AB3840@oracle.com>

This is P1, and needs to be backported. The jdk9 changeset applies without conflict.

Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ <http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/>
JBS: https://bugs.openjdk.java.net/browse/JDK-8066900 <https://bugs.openjdk.java.net/browse/JDK-8066900>
JDK9 changeset:  http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf3499dc002a <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf3499dc002a>

Thanks,
igor

From roland.westrelin at oracle.com  Thu Dec 11 08:44:57 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 11 Dec 2014 09:44:57 +0100
Subject: [8u] 8066900: Array Out Of Bounds Exception causes variable
	corruption
In-Reply-To: <2B10D236-DB6C-4F9F-91A6-36F395AB3840@oracle.com>
References: <2B10D236-DB6C-4F9F-91A6-36F395AB3840@oracle.com>
Message-ID: <F472A759-ADF3-452F-8E4D-713B7954907B@oracle.com>

Looks good.

Roland.

> On Dec 11, 2014, at 9:43 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
> This is P1, and needs to be backported. The jdk9 changeset applies without conflict.
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ <http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8066900 <https://bugs.openjdk.java.net/browse/JDK-8066900>
> JDK9 changeset:  http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf3499dc002a <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf3499dc002a>
> 
> Thanks,
> igor


From stefan.johansson at oracle.com  Thu Dec 11 08:48:54 2014
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 11 Dec 2014 09:48:54 +0100
Subject: RFR: 8062672: JVM crashes during GC on various asserts which
	checks that HeapWord ptr is an oop
In-Reply-To: <548951DD.3070407@oracle.com>
References: <5481825E.4080602@oracle.com> <548231FE.5090301@oracle.com>
	<5485B46C.2020509@oracle.com> <548951DD.3070407@oracle.com>
Message-ID: <54895A76.8030901@oracle.com>

Thanks for the reviews Jon and Bengt,

Stefan

On 2014-12-11 09:12, Bengt Rutisson wrote:
>
> Hi Stefan,
>
> With the changes you propose based on Jon's review this looks good to me.
>
> Thanks,
> Bengt
>
>
> On 12/8/14 3:23 PM, Stefan Johansson wrote:
>> Thanks for looking at this Jon,
>>
>> On 2014-12-05 23:30, Jon Masamitsu wrote:
>>> Stefan,
>>>
>>> Changes look good.
>>>
>>> Would you like to explicitly check the return from
>>> fgets() against NULL?  Your call.
>>>
>> I see that all other while(fgets...) checks for != NULL so I will add 
>> it.
>>> What do you think of an assert after the call to fgets() to
>>> check the length of the returned string.
>>>
>>> assert(strnlen(line, 1023) < 1023, "buffer line[1024] is too small.");
>>>
>>> Too paranoid?
>> I like adding an assert, but using strnlen feels a little paranoid 
>> since fgets promise to add '\0' at the end even if the line is longer 
>> than the buffer. So I plan to add this assert:
>> assert(strlen(line) < sizeof(line) - 1, "buffer line[1024] is too 
>> small.");
>>
>> Thanks,
>> Stefan
>>>
>>> Reviewed.
>>>
>>> Jon
>>>
>>> On 12/5/2014 2:01 AM, Stefan Johansson wrote:
>>>> Hi,
>>>>
>>>> Please review this fix for the linux-sparc issue described in:
>>>> https://bugs.openjdk.java.net/browse/JDK-8062672
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~sjohanss/8062672/hotspot.00/
>>>>
>>>> Summary:
>>>> This fix is based on 7u-dev because the most linux-sparc testing is 
>>>> done for that release and also because it's unclear if we have time 
>>>> to move the fix the normal way through 9 and 8u before going into 
>>>> 7u. But the main reason is that it would be good to get testing of 
>>>> the fix in 7u before porting it to 8u and 9.
>>>>
>>>> The fix it self is fairly simple, after JDK-8029190 was backported 
>>>> the condition for disabling UseMemSetInBOT changed from 
>>>> is_niagara() to has_blk_init(). This worked well for solaris-sparc 
>>>> but on linux-sparc we previously only set the niagara feature bits, 
>>>> so this change adds support for detecting blk_init support on 
>>>> linux-sparc.
>>>>
>>>> Testing:
>>>> Crashes/asserts was reproducible without the fix and after the fix 
>>>> none have been observed. Also verified that UseMemSetInBOT now is 
>>>> set to false as it should be.
>>>>
>>>> Thanks,
>>>> Stefan
>>>
>>
>


From igor.ignatyev at oracle.com  Thu Dec 11 08:50:04 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 11 Dec 2014 11:50:04 +0300
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <5489543A.7020300@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <, >
	<54857B2E.8020100@oracle.com>	<>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>	<54870A75.2000008@oracle.com>	<54873D3D.2030704@oracle.com>	<548747D4.40805@oracle.com>	<548825F2.4010900@oracle.com>	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>	<548826F8.4040100@oracle.com>
	<5489543A.7020300@oracle.com>
Message-ID: <54895ABC.70208@oracle.com>

Tobias,

/test/lib/Makefile
  years in copyright should be updated

otherwise LGTM

Thanks,
Igor

On 12/11/2014 11:22 AM, Tobias Hartmann wrote:
> Hi,
>
> are you fine with these changes? We will do the renaming with a separate change.
>
> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>
> Thanks,
> Tobias
>
> On 10.12.2014 11:56, Tobias Hartmann wrote:
>>
>> On 10.12.2014 11:54, Staffan Larsen wrote:
>>> I think we agreed to use jdk.test.lib as the package name (one dot more).
>>
>> Yes, but as Igor suggested we postpone the renaming and first only move it.
>>
>> I've also sent the wrong link. This is the right one:
>>
>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>>
>> Thanks,
>> Tobias
>>
>>>
>>> /Staffan
>>>
>>>> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change
>>>> is in. Here are the new webrevs for moving only:
>>>>
>>>> Top level repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>
>>>> Hotspot repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>>>
>>>> If there are no objections I would like to push the change soon.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> On 09.12.2014 20:04, Stefan S?rne wrote:
>>>>>
>>>>> Make sense.
>>>>>
>>>>> I am ok with delaying the name change.
>>>>> There is a phase two with the bulk of the job to this anyway.
>>>>> Dmitry, this is where we can have the repo discussion as well.
>>>>>
>>>>> I think there is an interesting part here anyway.
>>>>>
>>>>> Best regards,
>>>>> Stefan
>>>>>
>>>>> Igor Ignatyev skrev 2014-12-09 19:19:
>>>>>> Guys,
>>>>>>
>>>>>> changing Whitebox package name will cause failures in the tens tests which and
>>>>>> aren't co-located w/ the product.
>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't
>>>>>> want to have whitebox renamed this and next week.
>>>>>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>>>>>
>>>>>> can we move whitebox to top repo now and do renaming later?
>>>>>>
>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>>>>> repository we also have to adapt the native lookup code in
>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>>>>
>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>>>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>>>>
>>>>>>> Top level repo:
>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>>>
>>>>>>> Hotspot repo:
>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>>>>
>>>>>>> Tested on JPRT.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>>
>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> thanks for the feedback.
>>>>>>>>>>
>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>>>>> library.
>>>>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>>>>
>>>>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>>>>
>>>>>>>>>>>>   - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>>>>     what's used in the jdk repo?
>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>>>>
>>>>>>>>> Now sounds like a good time to align.   :)
>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>>>>>> step).
>>>>>>>>> Let's go with test/lib.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>   - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>>>>     all test-library classes have the same package root?
>>>>>>>>>>> +1
>>>>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>>>>
>>>>>>>>> Sounds good, the same package root is better.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>   - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>>>>     proper naming scheme for test-library packages, preferably starting
>>>>>>>>>>>>     with "jdk.?.
>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>>>>> Whatever you prefer.
>>>>>>>>>
>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Stefan
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias
>>>>>>>>>>
>>>>>>>>>>>>> ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>>>>>> the files in the jdk directory, however.
>>>>>>>>>>>
>>>>>>>>>>> /Staffan
>>>>>>>>
>>>>>>
>>>>>
>>>

-- 
Igor

From igor.veresov at oracle.com  Thu Dec 11 08:50:48 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 11 Dec 2014 00:50:48 -0800
Subject: [8u] 8066900: Array Out Of Bounds Exception causes variable
	corruption
In-Reply-To: <F472A759-ADF3-452F-8E4D-713B7954907B@oracle.com>
References: <2B10D236-DB6C-4F9F-91A6-36F395AB3840@oracle.com>
	<F472A759-ADF3-452F-8E4D-713B7954907B@oracle.com>
Message-ID: <9789BDB6-D95E-4067-8183-CC2A462E6A4C@oracle.com>

Thanks, Roland!

igor

> On Dec 11, 2014, at 12:44 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
> 
> Looks good.
> 
> Roland.
> 
>> On Dec 11, 2014, at 9:43 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
>> 
>> This is P1, and needs to be backported. The jdk9 changeset applies without conflict.
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ <http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8066900 <https://bugs.openjdk.java.net/browse/JDK-8066900>
>> JDK9 changeset:  http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf3499dc002a <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf3499dc002a>
>> 
>> Thanks,
>> igor
> 


From aph at redhat.com  Thu Dec 11 08:54:35 2014
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Dec 2014 08:54:35 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54891C77.2080404@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com>
Message-ID: <54895BCB.5060502@redhat.com>

On 11/12/14 04:24, Vladimir Kozlov wrote:
> On 12/10/14 12:44 PM, Andrew Haley wrote:
>> On 12/10/2014 08:27 PM, David Holmes wrote:
>>> If I had paid more attention to this earlier I would have suggested
>>> reversing the sense of the UseBarriersForVolatile flag
>>> (ElideBarriersForVolatiles?) because it makes it seem like using
>>> barriers for volatiles is experimental - which of course it isn't.
>>
>> OK.
>>
>>> Also this seems C2 specific so shouldn't it be defined in c2_globals.hpp?
>>
>> Sure.  This is the Patch That Never Ends, after all.  :-)
>>
>> Let's see what the other reviewers say, and I'll wrap it all together.
>>
>> Thanks,
>> Andrew.
>>
> 
> I agree with David about reversing flag and putting it into
> c2_globals.hpp. But, please, confirm that you left volatile barriers
> generated by C1 compiler (in c1_LIR_Generator.cpp) as they are - I
> don't see any changes there.

I have left barriers in C1 as they are.

> One thing left is barriers for volatile loads - there is
> inconsistency of code in library_call.cpp and parse3.cpp. We
> discussed it already before.

Right, but as I said to David, those barriers cannot be removed from
volatile loads without destabilizing C2.  The dependencies between the
front end and the innards of C2 are unfortunate, but we are where we
are.  I elide the unnecessary load barrier in the back end, so the
generated code is consistently using load acquire and store release.

> If you want to remove MemBarAcquire for volatile loads then, please,
> also change code in Parse::do_get_xxx() in parse3.cpp.

I can't, because C2 breaks.  Do you think this is a bug, or just a
rather pathological dependency between the front- and middle-ends?

Andrew.

From staffan.larsen at oracle.com  Thu Dec 11 09:02:32 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 11 Dec 2014 10:02:32 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <5489543A.7020300@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <,
	> <54857B2E.8020100@oracle.com> <>>>>>
	<20141208111859.936395@eggemoggin.niobe.net>
	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
	<5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com>
	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
	<54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com>
	<548747D4.40805@oracle.com> <548825F2.4010900@oracle.com>
	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>
	<548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com>
Message-ID: <891F1C17-337D-4E33-9BD0-9CB246C1A203@oracle.com>

Looks good!

Have we filed a bug for the rename? I assume you have run the changed tests and verified that they do not fail?

Thanks,
/Staffan


> On 11 dec 2014, at 09:22, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
> 
> Hi,
> 
> are you fine with these changes? We will do the renaming with a separate change.
> 
> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
> 
> Thanks,
> Tobias
> 
> On 10.12.2014 11:56, Tobias Hartmann wrote:
>> 
>> On 10.12.2014 11:54, Staffan Larsen wrote:
>>> I think we agreed to use jdk.test.lib as the package name (one dot more).
>> 
>> Yes, but as Igor suggested we postpone the renaming and first only move it.
>> 
>> I've also sent the wrong link. This is the right one:
>> 
>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>> 
>> Thanks,
>> Tobias
>> 
>>> 
>>> /Staffan
>>> 
>>>> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change
>>>> is in. Here are the new webrevs for moving only:
>>>> 
>>>> Top level repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>> 
>>>> Hotspot repo:
>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>>> 
>>>> If there are no objections I would like to push the change soon.
>>>> 
>>>> Thanks,
>>>> Tobias
>>>> 
>>>> On 09.12.2014 20:04, Stefan S?rne wrote:
>>>>> 
>>>>> Make sense.
>>>>> 
>>>>> I am ok with delaying the name change.
>>>>> There is a phase two with the bulk of the job to this anyway.
>>>>> Dmitry, this is where we can have the repo discussion as well.
>>>>> 
>>>>> I think there is an interesting part here anyway.
>>>>> 
>>>>> Best regards,
>>>>> Stefan
>>>>> 
>>>>> Igor Ignatyev skrev 2014-12-09 19:19:
>>>>>> Guys,
>>>>>> 
>>>>>> changing Whitebox package name will cause failures in the tens tests which and
>>>>>> aren't co-located w/ the product.
>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't
>>>>>> want to have whitebox renamed this and next week.
>>>>>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>>>>> 
>>>>>> can we move whitebox to top repo now and do renaming later?
>>>>>> 
>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>>>>> repository we also have to adapt the native lookup code in
>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>>>> 
>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>>>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>>>> 
>>>>>>> Top level repo:
>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>>> 
>>>>>>> Hotspot repo:
>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>>>> 
>>>>>>> Tested on JPRT.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>> 
>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>>>>> +1
>>>>>>>> 
>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> thanks for the feedback.
>>>>>>>>>> 
>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>>>>> library.
>>>>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>>>> 
>>>>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>>>> 
>>>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>>>>   what's used in the jdk repo?
>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>>>> 
>>>>>>>>> Now sounds like a good time to align.   :)
>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>>>>>> step).
>>>>>>>>> Let's go with test/lib.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>>>>   all test-library classes have the same package root?
>>>>>>>>>>> +1
>>>>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>>>> 
>>>>>>>>> Sounds good, the same package root is better.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>>>>   proper naming scheme for test-library packages, preferably starting
>>>>>>>>>>>>   with "jdk.?.
>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>>>>> Whatever you prefer.
>>>>>>>>> 
>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Stefan
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias
>>>>>>>>>> 
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>>>>>> the files in the jdk directory, however.
>>>>>>>>>>> 
>>>>>>>>>>> /Staffan
>>>>>>>> 
>>>>>> 
>>>>> 
>>> 


From staffan.larsen at oracle.com  Thu Dec 11 09:05:28 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 11 Dec 2014 10:05:28 +0100
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <5486F03D.6060608@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
	<5486CABC.9090107@oracle.com>
	<CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>
	<5486D0B3.5060209@oracle.com>
	<0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com>
	<5486F03D.6060608@oracle.com>
Message-ID: <B02FCEDA-E6AE-4BBB-912B-1040C934F988@oracle.com>

In UsageThresholdExceededSeveralTimesTest you have specified -Dcom.oracle.java.testlibrary.iterations=10 in the test - this will also mean that you cannot override it from outside. So same result.

/Staffan

> On 9 dec 2014, at 13:51, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> this solution doesn't allow us to change iteration count for all tests.
> 
> Igor
> 
> On 12/09/2014 03:22 PM, Staffan Larsen wrote:
>> I would favor a solution where the iteration count is an argument to the test instead of being a global variable.
>> 
>> /Staffan
>> 
>>> On 9 dec 2014, at 11:36, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>> 
>>> On 12/09/2014 01:20 PM, Staffan Larsen wrote:
>>>> 
>>>>> On 9 dec 2014, at 11:11, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>> 
>>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
>>>>> 
>>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
>>>>> 
>>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
>>>>> 
>>>>> for all of these cases, I'd like to use one variable.
>>>> 
>>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed.
>>>> 
>>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests.
>>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib?
>>> 
>>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one.
>>> 
>>> -- Igor
>>>> 
>>>> /Staffan
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Igor
>>>>> 
>>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>>>>>> 
>>>>>> /Staffan
>>>>>> 
>>>>>> 
>>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>> 
>>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>>>>>> 
>>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>>>>>> 
>>>>>>>> /Staffan
>>>>>>>> 
>>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Staffan,
>>>>>>>>> 
>>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Igor
>>>>>>>>> 
>>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>>>>>> perhaps he has future plans for this.
>>>>>>>>>> Igor?
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Dmitrij
>>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>>>>>> library?
>>>>>>>>>>> 
>>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Please review changes for
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>>>>>> Test task: JMX- tests
>>>>>>>>>>>>> and
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>>>>>> 
>>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>>>>>> testing thresholds, usage,
>>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>>>>>> tests.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Additional note: this patch assumes
>>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>>>>>> is fixed.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Dmitrij
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Igor
>>>>>> 
>>>>> 
>>>>> --
>>>>> Igor
>>>> 
>> 


From vladimir.kozlov at oracle.com  Thu Dec 11 09:19:03 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 01:19:03 -0800
Subject: [8u] 8066900: Array Out Of Bounds Exception causes variable
	corruption
In-Reply-To: <2B10D236-DB6C-4F9F-91A6-36F395AB3840@oracle.com>
References: <2B10D236-DB6C-4F9F-91A6-36F395AB3840@oracle.com>
Message-ID: <54896187.7050705@oracle.com>

Good.

Vladimir

On 12/11/14 12:43 AM, Igor Veresov wrote:
> This is P1, and needs to be backported. The jdk9 changeset applies without conflict.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ <http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8066900 <https://bugs.openjdk.java.net/browse/JDK-8066900>
> JDK9 changeset:  http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf3499dc002a <http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf3499dc002a>
>
> Thanks,
> igor
>

From vladimir.kozlov at oracle.com  Thu Dec 11 09:38:10 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 01:38:10 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54895BCB.5060502@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com> <54895BCB.5060502@redhat.com>
Message-ID: <54896602.6000809@oracle.com>

On 12/11/14 12:54 AM, Andrew Haley wrote:
> On 11/12/14 04:24, Vladimir Kozlov wrote:
>> On 12/10/14 12:44 PM, Andrew Haley wrote:
>>> On 12/10/2014 08:27 PM, David Holmes wrote:
>>>> If I had paid more attention to this earlier I would have suggested
>>>> reversing the sense of the UseBarriersForVolatile flag
>>>> (ElideBarriersForVolatiles?) because it makes it seem like using
>>>> barriers for volatiles is experimental - which of course it isn't.
>>>
>>> OK.
>>>
>>>> Also this seems C2 specific so shouldn't it be defined in c2_globals.hpp?
>>>
>>> Sure.  This is the Patch That Never Ends, after all.  :-)
>>>
>>> Let's see what the other reviewers say, and I'll wrap it all together.
>>>
>>> Thanks,
>>> Andrew.
>>>
>>
>> I agree with David about reversing flag and putting it into
>> c2_globals.hpp. But, please, confirm that you left volatile barriers
>> generated by C1 compiler (in c1_LIR_Generator.cpp) as they are - I
>> don't see any changes there.
>
> I have left barriers in C1 as they are.

Okay.

>
>> One thing left is barriers for volatile loads - there is
>> inconsistency of code in library_call.cpp and parse3.cpp. We
>> discussed it already before.
>
> Right, but as I said to David, those barriers cannot be removed from
> volatile loads without destabilizing C2.  The dependencies between the
> front end and the innards of C2 are unfortunate, but we are where we
> are.  I elide the unnecessary load barrier in the back end, so the
> generated code is consistently using load acquire and store release.
>
>> If you want to remove MemBarAcquire for volatile loads then, please,
>> also change code in Parse::do_get_xxx() in parse3.cpp.
>
> I can't, because C2 breaks.  Do you think this is a bug, or just a
> rather pathological dependency between the front- and middle-ends?

Most likely bug. If you eliminate barriers in all places where we generate volatile load and stores they should look 
like normal mem ops in Ideal graph - this should work. I can try it tomorrow to see what happens. I assume you mean "C2 
breaks" is crash during compilation. Do you have special test to show that?

Thanks,
Vladimir

>
> Andrew.
>

From igor.ignatyev at oracle.com  Thu Dec 11 09:39:23 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 11 Dec 2014 12:39:23 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <B02FCEDA-E6AE-4BBB-912B-1040C934F988@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
	<5486CABC.9090107@oracle.com>
	<CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>
	<5486D0B3.5060209@oracle.com>
	<0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com>
	<5486F03D.6060608@oracle.com>
	<B02FCEDA-E6AE-4BBB-912B-1040C934F988@oracle.com>
Message-ID: <5489664B.50904@oracle.com>

Staffan,

nope, since external flags append to the flags specified it a test, we 
will get '-Dc.o.j.t.iterations=10 -Dc.o.j.t.iterations=<new_value>' and 
the value of this property will be <new_value>.

Thanks,
Igor

On 12/11/2014 12:05 PM, Staffan Larsen wrote:
> In UsageThresholdExceededSeveralTimesTest you have specified -Dcom.oracle.java.testlibrary.iterations=10 in the test - this will also mean that you cannot override it from outside. So same result.
>
> /Staffan
>
>> On 9 dec 2014, at 13:51, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>> this solution doesn't allow us to change iteration count for all tests.
>>
>> Igor
>>
>> On 12/09/2014 03:22 PM, Staffan Larsen wrote:
>>> I would favor a solution where the iteration count is an argument to the test instead of being a global variable.
>>>
>>> /Staffan
>>>
>>>> On 9 dec 2014, at 11:36, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>
>>>> On 12/09/2014 01:20 PM, Staffan Larsen wrote:
>>>>>
>>>>>> On 9 dec 2014, at 11:11, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>
>>>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
>>>>>>
>>>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
>>>>>>
>>>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
>>>>>>
>>>>>> for all of these cases, I'd like to use one variable.
>>>>>
>>>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed.
>>>>>
>>>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests.
>>>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib?
>>>>
>>>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one.
>>>>
>>>> -- Igor
>>>>>
>>>>> /Staffan
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Igor
>>>>>>
>>>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>>>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>>>>>>>
>>>>>>> /Staffan
>>>>>>>
>>>>>>>
>>>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>>>>>>>
>>>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>>>>>>>
>>>>>>>>> /Staffan
>>>>>>>>>
>>>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Staffan,
>>>>>>>>>>
>>>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>>>>>>> perhaps he has future plans for this.
>>>>>>>>>>> Igor?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dmitrij
>>>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>>>>>>> library?
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review changes for
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>>>>>>> Test task: JMX- tests
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>>>>>>> testing thresholds, usage,
>>>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Additional note: this patch assumes
>>>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>>>>>>> is fixed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Dmitrij
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Igor
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Igor
>>>>>
>>>
>

From hs at tagtraum.com  Thu Dec 11 09:56:52 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 11 Dec 2014 10:56:52 +0100
Subject: Addition to web bug JI-9017423
Message-ID: <C8A49FEE-B7BA-45D9-A3B4-899C45457DDA@tagtraum.com>

Hey there!

I just filed web bug JI-9017423 (review id).
Just after I filed it, I noticed that all crash logs I received regarding this bug share a commonality. The VM region involved in the crash refers to a mapped .mp3 file. So they all look like this:

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       0x000000000000000a, 0x000000018c4af000

VM Regions Near 0x18c4af000:
    mapped file            000000018c428000-000000018c4a0000 [  480K] rw-/rwx SM=COW  /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/English.lproj/Localized.rsrc
--> mapped file            000000018c4a0000-000000018c4cc000 [  176K] r--/r-x SM=PRV  /Volumes/VOLUME/*/*.mp3
    IOKit                  000000018c4e9000-000000018c51c000 [  204K] rw-/rw- SM=SHM 

And as a matter of fact, the part of the program in which the crash occurs, does parse through a bunch of .mp3 files.
So perhaps this is not a Hotspot problem after all, but a memory mapped file problem or a combination of both.

Could someone please attach this information to the bug report?

Thank you,

-hendrik

From staffan.larsen at oracle.com  Thu Dec 11 10:00:32 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 11 Dec 2014 11:00:32 +0100
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <5489664B.50904@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
	<5486CABC.9090107@oracle.com>
	<CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>
	<5486D0B3.5060209@oracle.com>
	<0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com>
	<5486F03D.6060608@oracle.com>
	<B02FCEDA-E6AE-4BBB-912B-1040C934F988@oracle.com>
	<5489664B.50904@oracle.com>
Message-ID: <DA1BA1CF-26CE-4BA8-8245-7713324348C1@oracle.com>


> On 11 dec 2014, at 10:39, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> Staffan,
> 
> nope, since external flags append to the flags specified it a test, we will get '-Dc.o.j.t.iterations=10 -Dc.o.j.t.iterations=<new_value>' and the value of this property will be <new_value>.

I thought so too, but when I tested, external flags (-vmoption) were pre-pended.

/Staffan

> 
> Thanks,
> Igor
> 
> On 12/11/2014 12:05 PM, Staffan Larsen wrote:
>> In UsageThresholdExceededSeveralTimesTest you have specified -Dcom.oracle.java.testlibrary.iterations=10 in the test - this will also mean that you cannot override it from outside. So same result.
>> 
>> /Staffan
>> 
>>> On 9 dec 2014, at 13:51, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>> 
>>> this solution doesn't allow us to change iteration count for all tests.
>>> 
>>> Igor
>>> 
>>> On 12/09/2014 03:22 PM, Staffan Larsen wrote:
>>>> I would favor a solution where the iteration count is an argument to the test instead of being a global variable.
>>>> 
>>>> /Staffan
>>>> 
>>>>> On 9 dec 2014, at 11:36, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>> 
>>>>> On 12/09/2014 01:20 PM, Staffan Larsen wrote:
>>>>>> 
>>>>>>> On 9 dec 2014, at 11:11, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>> 
>>>>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
>>>>>>> 
>>>>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
>>>>>>> 
>>>>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
>>>>>>> 
>>>>>>> for all of these cases, I'd like to use one variable.
>>>>>> 
>>>>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed.
>>>>>> 
>>>>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests.
>>>>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib?
>>>>> 
>>>>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one.
>>>>> 
>>>>> -- Igor
>>>>>> 
>>>>>> /Staffan
>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Igor
>>>>>>> 
>>>>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>>>>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>>>>>>>> 
>>>>>>>> /Staffan
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>>>>>>>> 
>>>>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>>>>>>>> 
>>>>>>>>>> /Staffan
>>>>>>>>>> 
>>>>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Staffan,
>>>>>>>>>>> 
>>>>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks
>>>>>>>>>>> Igor
>>>>>>>>>>> 
>>>>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>>>>>>>> perhaps he has future plans for this.
>>>>>>>>>>>> Igor?
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Dmitrij
>>>>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>>>>>>>> library?
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Please review changes for
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>>>>>>>> Test task: JMX- tests
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>>>>>>>> testing thresholds, usage,
>>>>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Additional note: this patch assumes
>>>>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>>>>>>>> is fixed.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Dmitrij
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Igor
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Igor
>>>>>> 
>>>> 
>> 


From stefan.karlsson at oracle.com  Thu Dec 11 10:20:11 2014
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 11 Dec 2014 11:20:11 +0100
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <547F1C6E.1070701@oracle.com>
References: <547F1C6E.1070701@oracle.com>
Message-ID: <54896FDB.2010902@oracle.com>

Hi all,

FYI, this patch is being backported to 8u40. The JDK 9 Nighly testing 
looks good and the patch applies cleanly to 8u40.

StefanK

On 2014-12-03 15:21, Stefan Karlsson wrote:
> Hi all,
>
> Please, review this patch to fix an issue where the GC encounters an 
> InstanceKlass before it has come far enough in the class loading process.
>
> Some background to the fix:
>
> When the JVM loads classes it has to keep track of the allocated 
> Metadata, and in the event of an exception deallocate the Metadata. 
> The ClassFileParser saves the Metadata pointers so that it knows what 
> needs to be deallocated. When the class loading has come far enough 
> there's a point were the GC can take over the ownership of the 
> Metadata and do deallocation of the both the InstanceKlass and the 
> Metadata, if needed. At that point the Metadata pointers in the 
> ClassFileParser are cleared and transfered over to the InstanceKlass.
>
> Most Metadata allocations happen before the InstanceKlass is 
> allocated, but the Annotations are allocated after the InstanceKlass 
> but before the transferal and clearing of the Metadata pointers in the 
> ClassFileParser. If the GC stops when allocating the Annotations, it 
> will likely find this InstanceKlass and assume that the Metadata are 
> correctly setup. This is exactly what's happening in the bug report. 
> The GC finds that the _methods array, unexpectedly, points to NULL.
>
> The proposed solution to this problem is to allocate the Annotations 
> before the InstanceKlass is allocated.
>
> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8065634
>
> Testing:
> JPRT, parallel_class_loading testlist, Aurora adhoc run
>
> Thanks,
> StefanK


From mikael.gerdin at oracle.com  Thu Dec 11 10:28:38 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 11 Dec 2014 11:28:38 +0100
Subject: Addition to web bug JI-9017423
In-Reply-To: <C8A49FEE-B7BA-45D9-A3B4-899C45457DDA@tagtraum.com>
References: <C8A49FEE-B7BA-45D9-A3B4-899C45457DDA@tagtraum.com>
Message-ID: <548971D6.7080408@oracle.com>

Hi Hendrik,

On 2014-12-11 10:56, Hendrik Schreiber wrote:
> Hey there!
>
> I just filed web bug JI-9017423 (review id).
> Just after I filed it, I noticed that all crash logs I received regarding this bug share a commonality. The VM region involved in the crash refers to a mapped .mp3 file. So they all look like this:
>
> Exception Type:        EXC_BAD_ACCESS (SIGABRT)
> Exception Codes:       0x000000000000000a, 0x000000018c4af000
>
> VM Regions Near 0x18c4af000:
>      mapped file            000000018c428000-000000018c4a0000 [  480K] rw-/rwx SM=COW  /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Resources/English.lproj/Localized.rsrc
> --> mapped file            000000018c4a0000-000000018c4cc000 [  176K] r--/r-x SM=PRV  /Volumes/VOLUME/*/*.mp3
>      IOKit                  000000018c4e9000-000000018c51c000 [  204K] rw-/rw- SM=SHM
>
> And as a matter of fact, the part of the program in which the crash occurs, does parse through a bunch of .mp3 files.
> So perhaps this is not a Hotspot problem after all, but a memory mapped file problem or a combination of both.
>
> Could someone please attach this information to the bug report?

I attached the information to
https://bugs.openjdk.java.net/browse/JI-9017423

If you can find a hs_err_<pid>.log file that would be very useful as well.

/Mikael

>
> Thank you,
>
> -hendrik
>

From hs at tagtraum.com  Thu Dec 11 10:30:53 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 11 Dec 2014 11:30:53 +0100
Subject: Addition to web bug JI-9017423
In-Reply-To: <548971D6.7080408@oracle.com>
References: <C8A49FEE-B7BA-45D9-A3B4-899C45457DDA@tagtraum.com>
	<548971D6.7080408@oracle.com>
Message-ID: <41D8C3E0-150B-4963-A35D-3CB6D09FCB01@tagtraum.com>

> 
> I attached the information to
> https://bugs.openjdk.java.net/browse/JI-9017423

Thanks, Mikael. 

> 
> If you can find a hs_err_<pid>.log file that would be very useful as well.

Do those exist on OS X?

-hendrik


From aph at redhat.com  Thu Dec 11 10:32:12 2014
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Dec 2014 10:32:12 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54896602.6000809@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com> <54895BCB.5060502@redhat.com>
	<54896602.6000809@oracle.com>
Message-ID: <548972AC.100@redhat.com>

On 12/11/2014 09:38 AM, Vladimir Kozlov wrote:
> Most likely bug. If you eliminate barriers in all places where we generate volatile load and stores they should look 
> like normal mem ops in Ideal graph - this should work. I can try it tomorrow to see what happens. I assume you mean "C2 
> breaks" is crash during compilation. Do you have special test to show that?

I'll try to reproduce it.  I think it was compiling Netbeans, so it
might be difficult to get a reproducer.

Andrew.


From mikael.gerdin at oracle.com  Thu Dec 11 10:35:15 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 11 Dec 2014 11:35:15 +0100
Subject: Addition to web bug JI-9017423
In-Reply-To: <41D8C3E0-150B-4963-A35D-3CB6D09FCB01@tagtraum.com>
References: <C8A49FEE-B7BA-45D9-A3B4-899C45457DDA@tagtraum.com>	<548971D6.7080408@oracle.com>
	<41D8C3E0-150B-4963-A35D-3CB6D09FCB01@tagtraum.com>
Message-ID: <54897363.8030306@oracle.com>

On 2014-12-11 11:30, Hendrik Schreiber wrote:
>>
>> I attached the information to
>> https://bugs.openjdk.java.net/browse/JI-9017423
>
> Thanks, Mikael.
>
>>
>> If you can find a hs_err_<pid>.log file that would be very useful as well.
>
> Do those exist on OS X?

AFAIK one should have been created by VMError::report_and_die before it 
calls abort() which triggers the OS X error report.

/Mikael

>
> -hendrik
>

From goetz.lindenmaier at sap.com  Thu Dec 11 11:05:07 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 11 Dec 2014 11:05:07 +0000
Subject: RFR(M): 8066964: ppc64: argument and return type profiling, fix
	problem with popframe
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>

Hi,

I please need reviews for this change.

This patch adds the ppc implementation for argument and return type profiling, and fixes a problem with popframe.
Besides that, it contains a row of minor improvements, e.g. to pass some hotspot jtreg tests.

The change is ppc/aix only.  I would like to get it to jdk8u60 or 40.
http://cr.openjdk.java.net/~goetz/webrevs/8066964-typeProf/webrev.01/


Best regards,
  Goetz.



From aph at redhat.com  Thu Dec 11 11:30:14 2014
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Dec 2014 11:30:14 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54896602.6000809@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com> <54895BCB.5060502@redhat.com>
	<54896602.6000809@oracle.com>
Message-ID: <54898046.3070105@redhat.com>

On 12/11/2014 09:38 AM, Vladimir Kozlov wrote:
>> I can't, because C2 breaks.  Do you think this is a bug, or just a
>> > rather pathological dependency between the front- and middle-ends?
>
> Most likely bug. If you eliminate barriers in all places where we
> generate volatile load and stores they should look like normal mem
> ops in Ideal graph - this should work. I can try it tomorrow to see
> what happens. I assume you mean "C2 breaks" is crash during
> compilation. Do you have special test to show that?

How about if I simply give up on the idea of using acquire and release
for volatile for the time being?  The we could try to solve the
problem of barriers in hotspot at some later date.  It's not very
important for the AArch64 port, and perhaps it's just a step too far.

Andrew.

From tobias.hartmann at oracle.com  Thu Dec 11 11:54:17 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 11 Dec 2014 12:54:17 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <54895ABC.70208@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <, >
	<54857B2E.8020100@oracle.com>	<>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>	<54870A75.2000008@oracle.com>	<54873D3D.2030704@oracle.com>	<548747D4.40805@oracle.com>	<548825F2.4010900@oracle.com>	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>	<548826F8.4040100@oracle.com>
	<5489543A.7020300@oracle.com> <54895ABC.70208@oracle.com>
Message-ID: <548985E9.5020303@oracle.com>

Thanks, Igor.

I updated the copyrights.

http://cr.openjdk.java.net/~thartmann/8066433/webrev.04/
http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/

Best,
Tobias

On 11.12.2014 09:50, Igor Ignatyev wrote:
> Tobias,
> 
> /test/lib/Makefile
>  years in copyright should be updated
> 
> otherwise LGTM
> 
> Thanks,
> Igor
> 
> On 12/11/2014 11:22 AM, Tobias Hartmann wrote:
>> Hi,
>>
>> are you fine with these changes? We will do the renaming with a separate change.
>>
>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>
>> Thanks,
>> Tobias
>>
>> On 10.12.2014 11:56, Tobias Hartmann wrote:
>>>
>>> On 10.12.2014 11:54, Staffan Larsen wrote:
>>>> I think we agreed to use jdk.test.lib as the package name (one dot more).
>>>
>>> Yes, but as Igor suggested we postpone the renaming and first only move it.
>>>
>>> I've also sent the wrong link. This is the right one:
>>>
>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>
>>>> /Staffan
>>>>
>>>>> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the
>>>>> change
>>>>> is in. Here are the new webrevs for moving only:
>>>>>
>>>>> Top level repo:
>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>
>>>>> Hotspot repo:
>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>>>>
>>>>> If there are no objections I would like to push the change soon.
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>> On 09.12.2014 20:04, Stefan S?rne wrote:
>>>>>>
>>>>>> Make sense.
>>>>>>
>>>>>> I am ok with delaying the name change.
>>>>>> There is a phase two with the bulk of the job to this anyway.
>>>>>> Dmitry, this is where we can have the repo discussion as well.
>>>>>>
>>>>>> I think there is an interesting part here anyway.
>>>>>>
>>>>>> Best regards,
>>>>>> Stefan
>>>>>>
>>>>>> Igor Ignatyev skrev 2014-12-09 19:19:
>>>>>>> Guys,
>>>>>>>
>>>>>>> changing Whitebox package name will cause failures in the tens tests
>>>>>>> which and
>>>>>>> aren't co-located w/ the product.
>>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can
>>>>>>> lead
>>>>>>> to some failures. and I'd like not to have these failures mixed up. so I
>>>>>>> don't
>>>>>>> want to have whitebox renamed this and next week.
>>>>>>> however I do want to have whitebox available in jdk and hotspot repo this
>>>>>>> week.
>>>>>>>
>>>>>>> can we move whitebox to top repo now and do renaming later?
>>>>>>>
>>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>>>>>> repository we also have to adapt the native lookup code in
>>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>>>>>
>>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all
>>>>>>>> tests in
>>>>>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>>>>>
>>>>>>>> Top level repo:
>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>>>>
>>>>>>>> Hotspot repo:
>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>>>>>
>>>>>>>> Tested on JPRT.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> thanks for the feedback.
>>>>>>>>>>>
>>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>>>>>> library.
>>>>>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>>>>>
>>>>>>>>>>>>>   - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>>>>>     what's used in the jdk repo?
>>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>>>>>
>>>>>>>>>> Now sounds like a good time to align.   :)
>>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a
>>>>>>>>>> second
>>>>>>>>>> step).
>>>>>>>>>> Let's go with test/lib.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>   - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>>>>>     all test-library classes have the same package root?
>>>>>>>>>>>> +1
>>>>>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>>>>>
>>>>>>>>>> Sounds good, the same package root is better.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>   - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>>>>>     proper naming scheme for test-library packages, preferably
>>>>>>>>>>>>> starting
>>>>>>>>>>>>>     with "jdk.?.
>>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>>>>>> Whatever you prefer.
>>>>>>>>>>
>>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Stefan
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Tobias
>>>>>>>>>>>
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent
>>>>>>>>>>>>> will
>>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded
>>>>>>>>>>>> quite a
>>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these
>>>>>>>>>>>> overlap with
>>>>>>>>>>>> the files in the jdk directory, however.
>>>>>>>>>>>>
>>>>>>>>>>>> /Staffan
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
> 

From igor.ignatyev at oracle.com  Thu Dec 11 11:58:05 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 11 Dec 2014 14:58:05 +0300
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <548985E9.5020303@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <, >
	<54857B2E.8020100@oracle.com>	<>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>	<54870A75.2000008@oracle.com>	<54873D3D.2030704@oracle.com>	<548747D4.40805@oracle.com>	<548825F2.4010900@oracle.com>	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>	<548826F8.4040100@oracle.com>
	<5489543A.7020300@oracle.com> <54895ABC.70208@oracle.com>
	<548985E9.5020303@orac! le.com>
Message-ID: <548986CD.7040700@oracle.com>

Tobias,

thanks, push it.

-- 
Igor

On 12/11/2014 02:54 PM, Tobias Hartmann wrote:
> Thanks, Igor.
>
> I updated the copyrights.
>
> http://cr.openjdk.java.net/~thartmann/8066433/webrev.04/
> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>
> Best,
> Tobias
>
> On 11.12.2014 09:50, Igor Ignatyev wrote:
>> Tobias,
>>
>> /test/lib/Makefile
>>   years in copyright should be updated
>>
>> otherwise LGTM
>>
>> Thanks,
>> Igor
>>
>> On 12/11/2014 11:22 AM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> are you fine with these changes? We will do the renaming with a separate change.
>>>
>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>>
>>> Thanks,
>>> Tobias
>>>
>>> On 10.12.2014 11:56, Tobias Hartmann wrote:
>>>>
>>>> On 10.12.2014 11:54, Staffan Larsen wrote:
>>>>> I think we agreed to use jdk.test.lib as the package name (one dot more).
>>>>
>>>> Yes, but as Igor suggested we postpone the renaming and first only move it.
>>>>
>>>> I've also sent the wrong link. This is the right one:
>>>>
>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>
>>>>> /Staffan
>>>>>
>>>>>> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the
>>>>>> change
>>>>>> is in. Here are the new webrevs for moving only:
>>>>>>
>>>>>> Top level repo:
>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>>
>>>>>> Hotspot repo:
>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>>>>>
>>>>>> If there are no objections I would like to push the change soon.
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>> On 09.12.2014 20:04, Stefan S?rne wrote:
>>>>>>>
>>>>>>> Make sense.
>>>>>>>
>>>>>>> I am ok with delaying the name change.
>>>>>>> There is a phase two with the bulk of the job to this anyway.
>>>>>>> Dmitry, this is where we can have the repo discussion as well.
>>>>>>>
>>>>>>> I think there is an interesting part here anyway.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Stefan
>>>>>>>
>>>>>>> Igor Ignatyev skrev 2014-12-09 19:19:
>>>>>>>> Guys,
>>>>>>>>
>>>>>>>> changing Whitebox package name will cause failures in the tens tests
>>>>>>>> which and
>>>>>>>> aren't co-located w/ the product.
>>>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can
>>>>>>>> lead
>>>>>>>> to some failures. and I'd like not to have these failures mixed up. so I
>>>>>>>> don't
>>>>>>>> want to have whitebox renamed this and next week.
>>>>>>>> however I do want to have whitebox available in jdk and hotspot repo this
>>>>>>>> week.
>>>>>>>>
>>>>>>>> can we move whitebox to top repo now and do renaming later?
>>>>>>>>
>>>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>>>>>>> repository we also have to adapt the native lookup code in
>>>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>>>>>>
>>>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all
>>>>>>>>> tests in
>>>>>>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>>>>>>
>>>>>>>>> Top level repo:
>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>>>>>
>>>>>>>>> Hotspot repo:
>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>>>>>>
>>>>>>>>> Tested on JPRT.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Tobias
>>>>>>>>>
>>>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> thanks for the feedback.
>>>>>>>>>>>>
>>>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>>>>>>> library.
>>>>>>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>>>>>>      what's used in the jdk repo?
>>>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>>>>>>
>>>>>>>>>>> Now sounds like a good time to align.   :)
>>>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a
>>>>>>>>>>> second
>>>>>>>>>>> step).
>>>>>>>>>>> Let's go with test/lib.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>    - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>>>>>>      all test-library classes have the same package root?
>>>>>>>>>>>>> +1
>>>>>>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>>>>>>
>>>>>>>>>>> Sounds good, the same package root is better.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>    - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>>>>>>      proper naming scheme for test-library packages, preferably
>>>>>>>>>>>>>> starting
>>>>>>>>>>>>>>      with "jdk.?.
>>>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>>>>>>> Whatever you prefer.
>>>>>>>>>>>
>>>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Stefan
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Tobias
>>>>>>>>>>>>
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded
>>>>>>>>>>>>> quite a
>>>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these
>>>>>>>>>>>>> overlap with
>>>>>>>>>>>>> the files in the jdk directory, however.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Staffan
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>

From tobias.hartmann at oracle.com  Thu Dec 11 12:38:48 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 11 Dec 2014 13:38:48 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <891F1C17-337D-4E33-9BD0-9CB246C1A203@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <,
	<547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <,
	> <54857B2E.8020100@oracle.com> <>>>>>
	<20141208111859.936395@eggemoggin.niobe.net>
	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>
	<5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com>
	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>
	<54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com>
	<548747D4.40805@oracle.com> <548825F2.4010900@oracle.com>
	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>
	<548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com>
	<891F1C17-337D-4E33-9BD0-9CB246C1A203@oracle.com>
Message-ID: <54899058.2020909@oracle.com>

Hi Staffan,

On 11.12.2014 10:02, Staffan Larsen wrote:
> Looks good!
> 
> Have we filed a bug for the rename? 

Thanks. I filed JDK-8067223.

> I assume you have run the changed tests and verified that they do not fail?

Yes, I did.

Thanks,
Tobias

> 
> Thanks,
> /Staffan
> 
> 
>> On 11 dec 2014, at 09:22, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>
>> Hi,
>>
>> are you fine with these changes? We will do the renaming with a separate change.
>>
>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>
>> Thanks,
>> Tobias
>>
>> On 10.12.2014 11:56, Tobias Hartmann wrote:
>>>
>>> On 10.12.2014 11:54, Staffan Larsen wrote:
>>>> I think we agreed to use jdk.test.lib as the package name (one dot more).
>>>
>>> Yes, but as Igor suggested we postpone the renaming and first only move it.
>>>
>>> I've also sent the wrong link. This is the right one:
>>>
>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>
>>>> /Staffan
>>>>
>>>>> On 10 dec 2014, at 11:52, Tobias Hartmann <Tobias.Hartmann at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change
>>>>> is in. Here are the new webrevs for moving only:
>>>>>
>>>>> Top level repo:
>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>
>>>>> Hotspot repo:
>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/
>>>>>
>>>>> If there are no objections I would like to push the change soon.
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>> On 09.12.2014 20:04, Stefan S?rne wrote:
>>>>>>
>>>>>> Make sense.
>>>>>>
>>>>>> I am ok with delaying the name change.
>>>>>> There is a phase two with the bulk of the job to this anyway.
>>>>>> Dmitry, this is where we can have the repo discussion as well.
>>>>>>
>>>>>> I think there is an interesting part here anyway.
>>>>>>
>>>>>> Best regards,
>>>>>> Stefan
>>>>>>
>>>>>> Igor Ignatyev skrev 2014-12-09 19:19:
>>>>>>> Guys,
>>>>>>>
>>>>>>> changing Whitebox package name will cause failures in the tens tests which and
>>>>>>> aren't co-located w/ the product.
>>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead
>>>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't
>>>>>>> want to have whitebox renamed this and next week.
>>>>>>> however I do want to have whitebox available in jdk and hotspot repo this week.
>>>>>>>
>>>>>>> can we move whitebox to top repo now and do renaming later?
>>>>>>>
>>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I just noticed that if we want to access the Whitebox API in the top level
>>>>>>>> repository we also have to adapt the native lookup code in
>>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name.
>>>>>>>>
>>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in
>>>>>>>> the hotspot repository. Here are the corresponding webrevs:
>>>>>>>>
>>>>>>>> Top level repo:
>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/
>>>>>>>>
>>>>>>>> Hotspot repo:
>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/
>>>>>>>>
>>>>>>>> Tested on JPRT.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne <stefan.sarne at oracle.com
>>>>>>>>>> <mailto:stefan.sarne at oracle.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> thanks for the feedback.
>>>>>>>>>>>
>>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote:
>>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com
>>>>>>>>>>>>> <mailto:mark.reinhold at oracle.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com
>>>>>>>>>>>>> <mailto:stefan.sarne at oracle.com>:
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test
>>>>>>>>>>>>>> library.
>>>>>>>>>>>>> Yes.  The various "testlibrary" directories in different repos are, at
>>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the present root-repo proposal:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is
>>>>>>>>>>>>>   what's used in the jdk repo?
>>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-)
>>>>>>>>>>> Yes, do you prefer 'test/lib'?
>>>>>>>>>>
>>>>>>>>>> Now sounds like a good time to align.   :)
>>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second
>>>>>>>>>> step).
>>>>>>>>>> Let's go with test/lib.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> - Why does the white-box library get its own directory?  Shouldn't
>>>>>>>>>>>>>   all test-library classes have the same package root?
>>>>>>>>>>>> +1
>>>>>>>>>>> I agree. I'll remove the whitebox directory.
>>>>>>>>>>
>>>>>>>>>> Sounds good, the same package root is better.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> - The package name "sun.hotspot" is archaic.  We should figure out a
>>>>>>>>>>>>>   proper naming scheme for test-library packages, preferably starting
>>>>>>>>>>>>>   with "jdk.?.
>>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox?
>>>>>>>>>>> Whatever you prefer.
>>>>>>>>>>
>>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Stefan
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Tobias
>>>>>>>>>>>
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to
>>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing.
>>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the
>>>>>>>>>>>>>> RFE. The test folder already exists in the top repo.
>>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only
>>>>>>>>>>>>> contains 28 files.  It seems unlikely that the root-repo equivalent will
>>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill.
>>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a
>>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with
>>>>>>>>>>>> the files in the jdk directory, however.
>>>>>>>>>>>>
>>>>>>>>>>>> /Staffan
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
> 

From tobias.hartmann at oracle.com  Thu Dec 11 12:39:46 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 11 Dec 2014 13:39:46 +0100
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <548986CD.7040700@oracle.com>
References: <547DCF47.9000608@oracle.com> <, <547DF8D8.8080601@oracle.com> <,
	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com> <,
	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com> <,
	> <547E190F.1090407@oracle.com> <,
	> <54800E21.2050700@oracle.com> <,
	> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <,
	> <54855234.3050400@oracle.com> <,
	> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <,
	> <54856A31.9020702@oracle.com> <, >
	<54857B2E.8020100@oracle.com>	<>>>>>	<20141208111859.936395@eggemoggin.niobe.net>	<24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com>	<5486C62C.2040906@oracle.com>	<5486C73B.5080206@oracle.com>	<2B38452A-20B2-4954-B7A8-11B794357907@oracle.com>	<54870A75.2000008@oracle.com>	<54873D3D.2030704@oracle.com>	<548747D4.40805@oracle.com>	<548825F2.4010900@oracle.com>	<5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com>	<548826F8.4040100@oracle.com>
	<5489543A.7020300@oracle.com> <54895ABC.70208@oracle.com>
	<548985E9.5020303@oracle.com> <548986CD.7040700@oracle.! com>
Message-ID: <54899092.9020108@oracle.com>

Thanks, Igor.

Best,
Tobias

On 11.12.2014 12:58, Igor Ignatyev wrote:
> Tobias,
> 
> thanks, push it.
> 

From roland.westrelin at oracle.com  Thu Dec 11 13:59:51 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 11 Dec 2014 14:59:51 +0100
Subject: RFR(M): 8066964: ppc64: argument and return type profiling,
	fix problem with popframe
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>
Message-ID: <2BF1C0EA-DFBC-4F90-AE71-9D5889D4E4FF@oracle.com>

> The change is ppc/aix only.  I would like to get it to jdk8u60 or 40.
> http://cr.openjdk.java.net/~goetz/webrevs/8066964-typeProf/webrev.01/

That looks good to me.

Roland.

From roland.westrelin at oracle.com  Thu Dec 11 14:58:10 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 11 Dec 2014 15:58:10 +0100
Subject: [8u] backport of 6898462: The escape analysis with G1 cause crash
	assertion src/share/vm/runtime/vframeArray.cpp:94
Message-ID: <A83D57A9-18D9-44DE-A746-D5D1FA615294@oracle.com>

8u backport request. 6898462 was pushed to jdk9 on monday and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u.

https://bugs.openjdk.java.net/browse/JDK-6898462
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4d5b47a5184d

8067144 (currently a P4) is a follow up bug with TraceDeoptimization. It was pushed to jdk9 yesterday. It also applies cleanly to 8u.

https://bugs.openjdk.java.net/browse/JDK-8067144
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eaa8491c3fec

Do we want it backported as well? I would say yes but I would need to bump it to a P3, right?

Roland.

From roland.westrelin at oracle.com  Thu Dec 11 15:01:14 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 11 Dec 2014 16:01:14 +0100
Subject: [8u] backport of 8066103 C2's range check smearing allows out of
	bound array accesses 
Message-ID: <F392E9AF-F89E-47E8-BF1F-74FA10A4F488@oracle.com>

8u backport request. 8066103 was pushed to jdk9 on tuesday and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u.

https://bugs.openjdk.java.net/browse/JDK-8066103
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/287f46592168

Roland.

From roland.westrelin at oracle.com  Thu Dec 11 15:04:51 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 11 Dec 2014 16:04:51 +0100
Subject: [8u] backport of 8066775: opto/node.hpp:355,
	assert(i < _max) failed: oob: i=1, _max=1
Message-ID: <BBD877F4-FB89-4805-9998-5EF1F3EB9B89@oracle.com>

8u backport request. 8066775 was pushed to jdk9 on tuesday and it hasn?t caused any new failures during nightly testing. The change doesn?t apply cleanly to 8u (the change needs to be applied to connode.cpp instead of castnode.cpp but it is otherwise identical).

https://bugs.openjdk.java.net/browse/JDK-8066775
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/87900c19db37

Roland.

From coleen.phillimore at oracle.com  Thu Dec 11 16:22:52 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 11 Dec 2014 11:22:52 -0500
Subject: RFR: 8065634: Crash in InstanceKlass::clean_method_data when
	_method is NULL
In-Reply-To: <54896FDB.2010902@oracle.com>
References: <547F1C6E.1070701@oracle.com> <54896FDB.2010902@oracle.com>
Message-ID: <5489C4DC.7030104@oracle.com>


Good.
Coleen

On 12/11/14, 5:20 AM, Stefan Karlsson wrote:
> Hi all,
>
> FYI, this patch is being backported to 8u40. The JDK 9 Nighly testing 
> looks good and the patch applies cleanly to 8u40.
>
> StefanK
>
> On 2014-12-03 15:21, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please, review this patch to fix an issue where the GC encounters an 
>> InstanceKlass before it has come far enough in the class loading 
>> process.
>>
>> Some background to the fix:
>>
>> When the JVM loads classes it has to keep track of the allocated 
>> Metadata, and in the event of an exception deallocate the Metadata. 
>> The ClassFileParser saves the Metadata pointers so that it knows what 
>> needs to be deallocated. When the class loading has come far enough 
>> there's a point were the GC can take over the ownership of the 
>> Metadata and do deallocation of the both the InstanceKlass and the 
>> Metadata, if needed. At that point the Metadata pointers in the 
>> ClassFileParser are cleared and transfered over to the InstanceKlass.
>>
>> Most Metadata allocations happen before the InstanceKlass is 
>> allocated, but the Annotations are allocated after the InstanceKlass 
>> but before the transferal and clearing of the Metadata pointers in 
>> the ClassFileParser. If the GC stops when allocating the Annotations, 
>> it will likely find this InstanceKlass and assume that the Metadata 
>> are correctly setup. This is exactly what's happening in the bug 
>> report. The GC finds that the _methods array, unexpectedly, points to 
>> NULL.
>>
>> The proposed solution to this problem is to allocate the Annotations 
>> before the InstanceKlass is allocated.
>>
>> http://cr.openjdk.java.net/~stefank/8065634/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8065634
>>
>> Testing:
>> JPRT, parallel_class_loading testlist, Aurora adhoc run
>>
>> Thanks,
>> StefanK
>


From vladimir.kozlov at oracle.com  Thu Dec 11 17:32:04 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 09:32:04 -0800
Subject: [8u] backport of 6898462: The escape analysis with G1 cause crash
	assertion src/share/vm/runtime/vframeArray.cpp:94
In-Reply-To: <A83D57A9-18D9-44DE-A746-D5D1FA615294@oracle.com>
References: <A83D57A9-18D9-44DE-A746-D5D1FA615294@oracle.com>
Message-ID: <5489D514.7070704@oracle.com>

Looks good.

Thanks,
Vladimir

On 12/11/14 6:58 AM, Roland Westrelin wrote:
> 8u backport request. 6898462 was pushed to jdk9 on monday and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u.
>
> https://bugs.openjdk.java.net/browse/JDK-6898462
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4d5b47a5184d
>
> 8067144 (currently a P4) is a follow up bug with TraceDeoptimization. It was pushed to jdk9 yesterday. It also applies cleanly to 8u.
>
> https://bugs.openjdk.java.net/browse/JDK-8067144
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eaa8491c3fec
>
> Do we want it backported as well? I would say yes but I would need to bump it to a P3, right?
>
> Roland.
>

From vladimir.kozlov at oracle.com  Thu Dec 11 17:32:46 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 09:32:46 -0800
Subject: [8u] backport of 8066103 C2's range check smearing allows out
	of bound array accesses
In-Reply-To: <F392E9AF-F89E-47E8-BF1F-74FA10A4F488@oracle.com>
References: <F392E9AF-F89E-47E8-BF1F-74FA10A4F488@oracle.com>
Message-ID: <5489D53E.1020407@oracle.com>

Good.

thanks,
Vladimir

On 12/11/14 7:01 AM, Roland Westrelin wrote:
> 8u backport request. 8066103 was pushed to jdk9 on tuesday and it hasn?t caused any new failures during nightly testing. The change applies cleanly to 8u.
>
> https://bugs.openjdk.java.net/browse/JDK-8066103
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/287f46592168
>
> Roland.
>

From vladimir.kozlov at oracle.com  Thu Dec 11 17:33:37 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 09:33:37 -0800
Subject: [8u] backport of 8066775: opto/node.hpp:355, assert(i < _max)
	failed: oob: i=1, _max=1
In-Reply-To: <BBD877F4-FB89-4805-9998-5EF1F3EB9B89@oracle.com>
References: <BBD877F4-FB89-4805-9998-5EF1F3EB9B89@oracle.com>
Message-ID: <5489D571.9050409@oracle.com>

Good.

Thanks,
Vladimir

On 12/11/14 7:04 AM, Roland Westrelin wrote:
> 8u backport request. 8066775 was pushed to jdk9 on tuesday and it hasn?t caused any new failures during nightly testing. The change doesn?t apply cleanly to 8u (the change needs to be applied to connode.cpp instead of castnode.cpp but it is otherwise identical).
>
> https://bugs.openjdk.java.net/browse/JDK-8066775
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/87900c19db37
>
> Roland.
>

From vladimir.kozlov at oracle.com  Thu Dec 11 17:37:21 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 09:37:21 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <548972AC.100@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com> <54895BCB.5060502@redhat.com>
	<54896602.6000809@oracle.com> <548972AC.100@redhat.com>
Message-ID: <5489D651.4020707@oracle.com>

Meanwhile can we adjust changes in library_call.cpp to avoid only store's barriers as I suggested and deal with loads later?

Thanks,
Vladimir

On 12/11/14 2:32 AM, Andrew Haley wrote:
> On 12/11/2014 09:38 AM, Vladimir Kozlov wrote:
>> Most likely bug. If you eliminate barriers in all places where we generate volatile load and stores they should look
>> like normal mem ops in Ideal graph - this should work. I can try it tomorrow to see what happens. I assume you mean "C2
>> breaks" is crash during compilation. Do you have special test to show that?
>
> I'll try to reproduce it.  I think it was compiling Netbeans, so it
> might be difficult to get a reproducer.
>
> Andrew.
>

From vladimir.kozlov at oracle.com  Thu Dec 11 17:39:45 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 09:39:45 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <54898046.3070105@redhat.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26C6A@DEWDFEMB12A.global.corp.sap>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com> <54895BCB.5060502@redhat.com>
	<54896602.6000809@oracle.com> <54898046.3070105@redhat.com>
Message-ID: <5489D6E1.50305@oracle.com>

Agree!

Thanks,
Vladimir

On 12/11/14 3:30 AM, Andrew Haley wrote:
> On 12/11/2014 09:38 AM, Vladimir Kozlov wrote:
>>> I can't, because C2 breaks.  Do you think this is a bug, or just a
>>>> rather pathological dependency between the front- and middle-ends?
>>
>> Most likely bug. If you eliminate barriers in all places where we
>> generate volatile load and stores they should look like normal mem
>> ops in Ideal graph - this should work. I can try it tomorrow to see
>> what happens. I assume you mean "C2 breaks" is crash during
>> compilation. Do you have special test to show that?
>
> How about if I simply give up on the idea of using acquire and release
> for volatile for the time being?  The we could try to solve the
> problem of barriers in hotspot at some later date.  It's not very
> important for the AArch64 port, and perhaps it's just a step too far.
>
> Andrew.
>

From aph at redhat.com  Thu Dec 11 17:45:14 2014
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Dec 2014 17:45:14 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5489D651.4020707@oracle.com>
References: <54625D3D.4000007@redhat.com>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com> <54895BCB.5060502@redhat.com>
	<54896602.6000809@oracle.com> <548972AC.100@redhat.com>
	<5489D651.4020707@oracle.com>
Message-ID: <5489D82A.2020409@redhat.com>

On 12/11/2014 05:37 PM, Vladimir Kozlov wrote:
> Meanwhile can we adjust changes in library_call.cpp to avoid only store's barriers as I suggested and deal with loads later?

Okay, I think I understand what you mean.  Another patch coming
up.

Andrew.


From vladimir.kozlov at oracle.com  Thu Dec 11 17:55:14 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 09:55:14 -0800
Subject: RFR(M): 8066964: ppc64: argument and return type profiling, fix
	problem with popframe
In-Reply-To: <2BF1C0EA-DFBC-4F90-AE71-9D5889D4E4FF@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>
	<2BF1C0EA-DFBC-4F90-AE71-9D5889D4E4FF@oracle.com>
Message-ID: <5489DA82.6020600@oracle.com>

Good.

Since changes are ppc64 specific you can push it yourself (make sure changeset descriptor is correct).
Change priority to P3 and you can push it into 8u40 (do it until this Friday after which we would need approval):

http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/

Thanks,
Vladimir

On 12/11/14 5:59 AM, Roland Westrelin wrote:
>> The change is ppc/aix only.  I would like to get it to jdk8u60 or 40.
>> http://cr.openjdk.java.net/~goetz/webrevs/8066964-typeProf/webrev.01/
>
> That looks good to me.
>
> Roland.
>

From aph at redhat.com  Thu Dec 11 19:07:49 2014
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Dec 2014 19:07:49 +0000
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5489D6E1.50305@oracle.com>
References: <54625D3D.4000007@redhat.com>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com> <54895BCB.5060502@redhat.com>
	<54896602.6000809@oracle.com> <54898046.3070105@redhat.com>
	<5489D6E1.50305@oracle.com>
Message-ID: <5489EB85.5060209@redhat.com>

On 12/11/2014 05:39 PM, Vladimir Kozlov wrote:
> Agree!

http://cr.openjdk.java.net/~aph/aarch64-8064611-8/

Thanks,
Andrew.


From dean.long at oracle.com  Thu Dec 11 19:53:05 2014
From: dean.long at oracle.com (Dean Long)
Date: Thu, 11 Dec 2014 11:53:05 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5489EB85.5060209@redhat.com>
References: <54625D3D.4000007@redhat.com>	<54632ABA.5000706@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>	<54883895.1000609@redhat.com>
	<54885DA7.4010003@redhat.com>	<5488ACC3.9070404@oracle.com>
	<5488B0A3.7020003@redhat.com>	<54891C77.2080404@oracle.com>
	<54895BCB.5060502@redhat.com>	<54896602.6000809@oracle.com>
	<54898046.3070105@redhat.com>	<5489D6E1.50305@oracle.com>
	<5489EB85.5060209@redhat.com>
Message-ID: <5489F621.2010906@oracle.com>

Looks good to me.  Did someone from the runtime team already look at the 
metaspace.cpp changes?

dl

On 12/11/2014 11:07 AM, Andrew Haley wrote:
> On 12/11/2014 05:39 PM, Vladimir Kozlov wrote:
>> Agree!
> http://cr.openjdk.java.net/~aph/aarch64-8064611-8/
>
> Thanks,
> Andrew.
>


From dmitrij.pochepko at oracle.com  Thu Dec 11 12:25:44 2014
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Thu, 11 Dec 2014 15:25:44 +0300
Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and
	JDK-8066440 - Various changes in testlibrary for JDK-8059613
In-Reply-To: <B02FCEDA-E6AE-4BBB-912B-1040C934F988@oracle.com>
References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com>
	<8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com>
	<548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com>
	<AD8AFA70-1D8A-405B-9A48-886C3D9066DD@oracle.com>
	<5486C215.2090206@oracle.com>
	<F1A3188B-EA30-4B26-A272-E22148440023@oracle.com>
	<5486CABC.9090107@oracle.com>
	<CEA874EB-D227-4670-8D5E-BEB240649032@oracle.com>
	<5486D0B3.5060209@oracle.com>
	<0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com>
	<5486F03D.6060608@oracle.com>
	<B02FCEDA-E6AE-4BBB-912B-1040C934F988@oracle.com>
Message-ID: <54898D48.7090005@oracle.com>

Yes,
but in order to launch with any terations count, one shold just launch 
UsageThresholdExceededTest with -Dcom.oracle.java.testlibrary.iterations 
specified.

Thanks,
Dmitrij
> In UsageThresholdExceededSeveralTimesTest you have specified -Dcom.oracle.java.testlibrary.iterations=10 in the test - this will also mean that you cannot override it from outside. So same result.
>
> /Staffan
>
>> On 9 dec 2014, at 13:51, Igor Ignatyev<igor.ignatyev at oracle.com>  wrote:
>>
>> this solution doesn't allow us to change iteration count for all tests.
>>
>> Igor
>>
>> On 12/09/2014 03:22 PM, Staffan Larsen wrote:
>>> I would favor a solution where the iteration count is an argument to the test instead of being a global variable.
>>>
>>> /Staffan
>>>
>>>> On 9 dec 2014, at 11:36, Igor Ignatyev<igor.ignatyev at oracle.com>  wrote:
>>>>
>>>> On 12/09/2014 01:20 PM, Staffan Larsen wrote:
>>>>>> On 9 dec 2014, at 11:11, Igor Ignatyev<igor.ignatyev at oracle.com>  wrote:
>>>>>>
>>>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
>>>>>>
>>>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
>>>>>>
>>>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
>>>>>>
>>>>>> for all of these cases, I'd like to use one variable.
>>>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed.
>>>>>
>>>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests.
>>>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib?
>>>>
>>>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one.
>>>>
>>>> -- Igor
>>>>> /Staffan
>>>>>
>>>>>> Thanks,
>>>>>> Igor
>>>>>>
>>>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>>>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>>>>>>>
>>>>>>> /Staffan
>>>>>>>
>>>>>>>
>>>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev<igor.ignatyev at oracle.com>  wrote:
>>>>>>>>
>>>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>>>>>>>
>>>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>>>>>>>
>>>>>>>>> /Staffan
>>>>>>>>>
>>>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev<igor.ignatyev at oracle.com>  wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Staffan,
>>>>>>>>>>
>>>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>>>>>>> perhaps he has future plans for this.
>>>>>>>>>>> Igor?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dmitrij
>>>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>>>>>>> library?
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>   wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please review changes for
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>>>>>>> Test task: JMX- tests
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>>>>>>> testing thresholds, usage,
>>>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>>>>>>> tests.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Additional note: this patch assumes
>>>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>>>>>>> is fixed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Dmitrij
>>>>>>>> --
>>>>>>>> Igor
>>>>>> --
>>>>>> Igor


From vladimir.kozlov at oracle.com  Thu Dec 11 20:19:41 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 12:19:41 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5489F621.2010906@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>	<54883895.1000609@redhat.com>
	<54885DA7.4010003@redhat.com>	<5488ACC3.9070404@oracle.com>
	<5488B0A3.7020003@redhat.com>	<54891C77.2080404@oracle.com>
	<54895BCB.5060502@redhat.com>	<54896602.6000809@oracle.com>
	<54898046.3070105@redhat.com>	<5489D6E1.50305@oracle.com>
	<5489EB85.5060209@redhat.com> <5489F621.2010906@oracle.com>
Message-ID: <5489FC5D.70306@oracle.com>

Good.

David Holmes looked on this changes. And metaspace.cpp changes are aarch64 platform specific.

I am pushing it.

Thanks,
Vladimir

On 12/11/14 11:53 AM, Dean Long wrote:
> Looks good to me.  Did someone from the runtime team already look at the metaspace.cpp changes?
>
> dl
>
> On 12/11/2014 11:07 AM, Andrew Haley wrote:
>> On 12/11/2014 05:39 PM, Vladimir Kozlov wrote:
>>> Agree!
>> http://cr.openjdk.java.net/~aph/aarch64-8064611-8/
>>
>> Thanks,
>> Andrew.
>>
>

From coleen.phillimore at oracle.com  Thu Dec 11 20:42:56 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 11 Dec 2014 15:42:56 -0500
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5489F621.2010906@oracle.com>
References: <54625D3D.4000007@redhat.com>	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>	<54638FA0.8040204@redhat.com>	<546572B8.9080005@oracle.com>	<546A1EF5.6060607@redhat.com>	<546A60C7.1070408@oracle.com>	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>	<546BF7F3.5020507@oracle.com>	<546C0881.8050905@oracle.com>	<546C1264.6090308@oracle.com>	<546DF9D8.3090505@redhat.com>	<546E2D75.8080900@oracle.com>	<546E2F62.4030104@redhat.com>	<546F7765.1070907@redhat.com>	<546F7F42.5090100@oracle.com>	<54875958.5010707@oracle.com>	<54880D04.4050605@redhat.com>	<5488277E.9080502@redhat.com>	<54882FC5.6010906@oracle.com>	<54883895.1000609@redhat.com>	<54885DA7.4010003@redhat.com>	<5488ACC3.9070404@oracle.com>	<5488B0A3.7020003@redhat.com>	<54891C77.2080404@oracle.com>	<54895BCB.5060502@redhat.com>	<54896602.6000809@oracle.com>	<54898046.3070105@redhat.com>	<5489D6E1.50305@oracle.com>	<5489EB85.5060209@redhat.com>
	<5489F621.2010906@oracle.com>
Message-ID: <548A01D0.6040504@oracle.com>


On 12/11/14, 2:53 PM, Dean Long wrote:
> Looks good to me.  Did someone from the runtime team already look at 
> the metaspace.cpp changes?

I looked at it a while ago and wasn't very alarmed.  I don't like the 
conditional code but we might be able to use it, so it's fine there.   
The rest of the change seemed fine also at the time (although I didn't 
look at any compiler files).

Coleen

>
> dl
>
> On 12/11/2014 11:07 AM, Andrew Haley wrote:
>> On 12/11/2014 05:39 PM, Vladimir Kozlov wrote:
>>> Agree!
>> http://cr.openjdk.java.net/~aph/aarch64-8064611-8/
>>
>> Thanks,
>> Andrew.
>>
>


From christian.thalinger at oracle.com  Thu Dec 11 20:49:39 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 11 Dec 2014 12:49:39 -0800
Subject: AARCH64: 8064611: Changes to HotSpot shared code
In-Reply-To: <5489FC5D.70306@oracle.com>
References: <54625D3D.4000007@redhat.com>
	<4295855A5C1DE049A61835A1887419CC2CF26D77@DEWDFEMB12A.global.corp.sap>
	<54638FA0.8040204@redhat.com> <546572B8.9080005@oracle.com>
	<546A1EF5.6060607@redhat.com> <546A60C7.1070408@oracle.com>
	<B3D82DB2-1B66-4CFD-92CF-F1B3003DC8F3@oracle.com>
	<546BF7F3.5020507@oracle.com> <546C0881.8050905@oracle.com>
	<546C1264.6090308@oracle.com> <546DF9D8.3090505@redhat.com>
	<546E2D75.8080900@oracle.com> <546E2F62.4030104@redhat.com>
	<546F7765.1070907@redhat.com> <546F7F42.5090100@oracle.com>
	<54875958.5010707@oracle.com> <54880D04.4050605@redhat.com>
	<5488277E.9080502@redhat.com> <54882FC5.6010906@oracle.com>
	<54883895.1000609@redhat.com> <54885DA7.4010003@redhat.com>
	<5488ACC3.9070404@oracle.com> <5488B0A3.7020003@redhat.com>
	<54891C77.2080404@oracle.com> <54895BCB.5060502@redhat.com>
	<54896602.6000809@oracle.com> <54898046.3070105@redhat.com>
	<5489D6E1.50305@oracle.com> <5489EB85.5060209@redhat.com>
	<5489F621.2010906@oracle.com> <5489FC5D.70306@or! acle.com>
Message-ID: <A5220C3D-A94B-40CB-9EDE-212009EE1200@oracle.com>


> On Dec 11, 2014, at 12:19 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Good.
> 
> David Holmes looked on this changes. And metaspace.cpp changes are aarch64 platform specific.
> 
> I am pushing it.

Yay!

> 
> Thanks,
> Vladimir
> 
> On 12/11/14 11:53 AM, Dean Long wrote:
>> Looks good to me.  Did someone from the runtime team already look at the metaspace.cpp changes?
>> 
>> dl
>> 
>> On 12/11/2014 11:07 AM, Andrew Haley wrote:
>>> On 12/11/2014 05:39 PM, Vladimir Kozlov wrote:
>>>> Agree!
>>> http://cr.openjdk.java.net/~aph/aarch64-8064611-8/
>>> 
>>> Thanks,
>>> Andrew.
>>> 
>> 


From vladimir.kozlov at oracle.com  Thu Dec 11 22:04:20 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Dec 2014 14:04:20 -0800
Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really
	reload given class
In-Reply-To: <54883681.3030307@oracle.com>
References: <54872854.90806@oracle.com>	<628BCC0A-43FF-4469-BC0D-FC38BBE53A58@oracle.com>
	<54883681.3030307@oracle.com>
Message-ID: <548A14E4.7090807@oracle.com>

Pavel,

I am resending it to whole hotspot so you can get more help/explanations.

Thanks,
Vladimir

On 12/10/14 4:03 AM, Pavel Chistyakov wrote:
> Hi David,
>
> Thanks for review.
>
> The intent was:
>
>   * be able to get */new/* instance of Class w/ given name and given bytecode for every /*new*/ instance of
>     ByteCodeLoader even if this class was already loaded by parent loader. For this reason, I overrided loadClass to
>     break delegation to parent loader for given className;
>   * make single class definition for ByteCodeLoader instance. Here holder field appears and DCL for it's thread safe
>     initialization.
>
>
> -------------
> Pavel
>
> On 09.12.2014 23:49, David Chase wrote:
>> I agree with your changes to loadClass, but I am not sure that this will allow you to redefine an existing class.  My understanding of how this would work is that it will allow you re-obtain the class that was already loaded (but not to fail at this).  Actually redefining a class requires use of JVMTI (or so I think).
>>
>> Was that your intent?
>>
>> David
>>
>>
>> On 2014-12-09, at 11:50 AM, Pavel Chistyakov<pavel.chistyakov at oracle.com>  wrote:
>>
>>> Hi all,
>>>
>>> please review changes for:https://bugs.openjdk.java.net/browse/JDK-8066497
>>> webrev:http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/  <http://cr.openjdk.java.net/%7Eiignatyev/pchistyakov/8066497/webrev.00/>
>>>
>>> Problem:
>>> ByteCodeLoader allows one to load class with given name from existing bytecode. But if this class is already loaded by e.g. system classloader it cannot be redefined using another bytecode array because of delegation of loadClass call to parent classloader.
>>>
>>> Solution:
>>> override loadClass to break delegation for given className.
>>>
>>> Testing: manual
>>>
>>> -------------------
>>> Thanks,
>>> Pavel
>

From david.holmes at oracle.com  Thu Dec 11 22:50:33 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Dec 2014 08:50:33 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <5487EA35.6070709@oracle.com>
References: <542C8274.3010809@gmail.com>	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>	<5479E9DE.7070703@gmail.com>	<547C079A.9020604@oracle.com>	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>	<547C1815.6050900@oracle.com>	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>	<547C38AD.6050703@gmail.com>	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>	<547D891D.7010809@oracle.com>	<547DCCFB.3050209@gmail.com>	<54854475.20800@oracle.com>	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>	<54868B02.1070408@oracle.com>	<CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>	<5486B952.4070708@oracle.com>	<CAA-vtUyRtwD+08BjZSZY_q5uHGnb8kmW7AZD2TSe=_0h6rgT_A@mail.gmai!	l.com>
	<5486FF9A.2050604@gma! il.com> <5487EA35.6070709@oracle.com>
Message-ID: <548A1FB9.1010306@oracle.com>

Sorry, I've been advised I need a second reviewer with an openjdk user 
name and as Staffan has not come back to this thread, that means I need 
one more reviewer from the runtime team please. And please check the 
email trail on this as it is quite long and I really don't want to 
revisit covered ground. :) Thanks.

David

On 10/12/2014 4:37 PM, David Holmes wrote:
> Hi Yasumasa,
>
> On 9/12/2014 11:56 PM, Yasumasa Suenaga wrote:
>> David, Thomas,
>>
>> Thank you so much!
>> I wait 2nd reviewer.
>
> I'm a Reviewer and I think Thomas counts as a reviewer. Plus Staffan had
> a look too. So I think this is good to go - though I'll give it till my
> morning before finalizing it.
>
>> BTW, I'm not a committer.
>> So I'm also waiting a sponsor :-)
>
> I will sponsor if you can prepare the changeset.
>
> Thanks,
> David
>
>>> I'm okay with these changes. Just a minor style nit (no need for
>>> updated webrev) can you remove the blank lines in os_linux.cpp:
>>>
>>> 6011       }
>>> 6012
>>> 6013     }
>>> 6014
>>> 6015   }
>>>
>>> 6057       }
>>> 6058
>>> 6059     }
>>> 6060
>>> 6061   }
>>>
>>> If anyone has any objections please raise them asap.
>>
>> I will upload new webrev which is fix them after reviewing.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> (2014/12/09 21:06), Thomas St?fe wrote:
>>> Yes, Sure :-) @Yasumasa : thank you for this patch!
>>>
>>> Kind regards, Thomas
>>>
>>> On Dec 9, 2014 9:56 AM, "David Holmes" <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>     Hi Thomas,
>>>
>>>     So can we take this as-is for now and file a RFE to address your
>>> concerns?
>>>
>>>     Anybody else object to that?
>>>
>>>     Thanks,
>>>     David
>>>
>>>     On 9/12/2014 6:09 PM, Thomas St?fe wrote:
>>>
>>>         Hi David,
>>>
>>>         On Tue, Dec 9, 2014 at 6:39 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 Thomas,
>>>
>>>              On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>>>
>>>                  Hi,
>>>
>>>                  I do not really like the handling of the leading pipe
>>> symbol:
>>>
>>>
>>>              To be fair to Yasumasa this aspect of the fix has been
>>> the same
>>>              since Oct 15:
>>>
>>>
>>> http://cr.openjdk.java.net/~____ysuenaga/JDK-8059586/webrev.____02/
>>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/>
>>>
>>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/
>>> <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/>>
>>>
>>>              and was not flagged.
>>>
>>>
>>>         You are right, I did not read those mails close enough.
>>>
>>>
>>>
>>>                  So, we read the core_pattern, and if the pipe symbol
>>> is detected, we
>>>                  write the core pattern minus the pipe symbol but plus
>>> a leading
>>>                  quote to
>>>                  the output; the leading quote then serves as a info
>>> to the layer
>>>                  above
>>>                  in os_posix.cpp to treat this case specially. This
>>> means the logic
>>>                  spills out of the platform dependend os_linux.cpp to
>>> shared code and
>>>                  this is also difficult to read.
>>>
>>>                  This comes from the fact that "get_core_path()"
>>> assumes the core
>>>                  file is
>>>                  written to the file system. I think it just does not
>>> fit
>>>                  anymore, better
>>>                  would be to replace it with something like
>>>                  "os::print_core_file_location(____outputStream* os)",
>>> and the OS
>>>                  handles
>>>                  both core path retrieval and the printing. Because
>>> then the
>>>                  shared code
>>>                  does not need to know whether core file gets printed
>>>                  traditionally or
>>>                  piped to a executable or whatever.
>>>
>>>
>>>              This sounds like a refactoring that I suggested would be
>>> too disruptive.
>>>
>>>
>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015547.html
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html>
>>>
>>>
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html
>>>
>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015547.html>>
>>>
>>>
>>>
>>>
>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015557.html
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html>
>>>
>>>
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html
>>>
>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015557.html>>
>>>
>>>
>>>
>>>
>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015573.html
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html>
>>>
>>>
>>>
>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html
>>>
>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015573.html>>
>>>
>>>
>>>
>>>
>>>         I do not think that this would be such a big a change, but it
>>> also could
>>>         be done with another patch.
>>>
>>>         Apart from my reservations I stated above the code looks fine
>>> and is
>>>         definitly an improvement (just last week I was helplessly
>>> looking for a
>>>         core on a machine where core_pattern turned out to be a
>>> redirection to
>>>         another program).
>>>
>>>         Kind Regards, Thomas
>>>
>>>
>>>              David
>>>

From alejandro.murillo at oracle.com  Thu Dec 11 23:27:25 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 11 Dec 2014 16:27:25 -0700
Subject: RFR(M): 8066964: ppc64: argument and return type profiling, fix
	problem with popframe
In-Reply-To: <5489DA82.6020600@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>
	<2BF1C0EA-DFBC-4F90-AE71-9D5889D4E4FF@oracle.com>
	<5489DA82.6020600@oracle.com>
Message-ID: <548A285D.1080905@oracle.com>


Thanks for letting me know Vladimir.
Goetz, please push this by tomorrow (Friday 12/12/) morning PT,
as I plan to start the snapshot during  the morning.

also,  to reduce the chance of collision,
please send a "heads up" email to this alias right before you start the 
push,
in case someone is planning to submit a jprt pushing job to that repo,
at the same time.

going forward, we might have to setup a time window
during the week for these integrations to avoid potential conflicts
(since jprt jobs take a while before they do the actual push)

Thanks
Alejandro


On 12/11/2014 10:55 AM, Vladimir Kozlov wrote:
> Good.
>
> Since changes are ppc64 specific you can push it yourself (make sure 
> changeset descriptor is correct).
> Change priority to P3 and you can push it into 8u40 (do it until this 
> Friday after which we would need approval):
>
> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/
>
> Thanks,
> Vladimir
>
> On 12/11/14 5:59 AM, Roland Westrelin wrote:
>>> The change is ppc/aix only.  I would like to get it to jdk8u60 or 40.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8066964-typeProf/webrev.01/
>>
>> That looks good to me.
>>
>> Roland.
>>

-- 
Alejandro


From jonathan.gibbons at oracle.com  Fri Dec 12 02:16:36 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 Dec 2014 18:16:36 -0800
Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level
	repository
In-Reply-To: <43F17AFB-5E36-41BF-BB29-429ECEF9D977@oracle.com>
References: <547DCF47.9000608@oracle.com>
	<547DF563.8080509@oracle.com>	<547DF8D8.8080601@oracle.com>	<A72D7FAF-0EFB-49EA-A39D-2D31D9D14489@oracle.com>	<B0446B07-4BF7-47E7-9964-B8217CDD7184@oracle.com>	<547E190F.1090407@oracle.com>
	<54800E21.2050700@oracle.com>	<66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>	<54855234.3050400@oracle.com>	<260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>	<54856A31.9020702@oracle.com>
	<5486CA0B.4010501@oracle.com>
	<43F17AFB-5E36-41BF-BB29-429ECEF9D977@oracle.com>
Message-ID: <548A5004.2030101@oracle.com>


On 12/09/2014 02:15 AM, Staffan Larsen wrote:
> The suggestion is to use "@library /../../test/lib?. Using an initial slash means that the path is relative to TEST.ROOT, not to the test itself. I?m not sure if this was intended in jtreg or if it just happens to work. I?m sure we can think of cleaner approach in the future.
>
> /Staffan

This is remarkably ugly, and I'm sorry that it even works.

I welcome suggestions for a better way of expressing this, although I 
have a horrible feeling the ../.. sequence is going to have to show up 
somewhere, although it would be better if it was not in every test that 
uses the library.

-- Jon

From goetz.lindenmaier at sap.com  Fri Dec 12 08:06:46 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 12 Dec 2014 08:06:46 +0000
Subject: RFR(M): 8066964: ppc64: argument and return type profiling, fix
	problem with popframe
In-Reply-To: <548A285D.1080905@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>
	<2BF1C0EA-DFBC-4F90-AE71-9D5889D4E4FF@oracle.com>
	<5489DA82.6020600@oracle.com> <548A285D.1080905@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF401D6@DEWDFEMB12A.global.corp.sap>

Hi,

ok, here goes the 'heads up': I'm ready to push to jdk8u/hs-dev/hotspot.

Is that fine?

Best regards,
  Goetz.


-----Original Message-----
From: Alejandro E Murillo [mailto:alejandro.murillo at oracle.com] 
Sent: Friday, December 12, 2014 12:27 AM
To: Vladimir Kozlov; Roland Westrelin; Lindenmaier, Goetz
Cc: hotspot-dev Source Developers
Subject: Re: RFR(M): 8066964: ppc64: argument and return type profiling, fix problem with popframe


Thanks for letting me know Vladimir.
Goetz, please push this by tomorrow (Friday 12/12/) morning PT,
as I plan to start the snapshot during  the morning.

also,  to reduce the chance of collision,
please send a "heads up" email to this alias right before you start the 
push,
in case someone is planning to submit a jprt pushing job to that repo,
at the same time.

going forward, we might have to setup a time window
during the week for these integrations to avoid potential conflicts
(since jprt jobs take a while before they do the actual push)

Thanks
Alejandro


On 12/11/2014 10:55 AM, Vladimir Kozlov wrote:
> Good.
>
> Since changes are ppc64 specific you can push it yourself (make sure 
> changeset descriptor is correct).
> Change priority to P3 and you can push it into 8u40 (do it until this 
> Friday after which we would need approval):
>
> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/
>
> Thanks,
> Vladimir
>
> On 12/11/14 5:59 AM, Roland Westrelin wrote:
>>> The change is ppc/aix only.  I would like to get it to jdk8u60 or 40.
>>> http://cr.openjdk.java.net/~goetz/webrevs/8066964-typeProf/webrev.01/
>>
>> That looks good to me.
>>
>> Roland.
>>

-- 
Alejandro


From mikael.vidstedt at oracle.com  Fri Dec 12 08:35:33 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Fri, 12 Dec 2014 00:35:33 -0800
Subject: RFR(M): 8066964: ppc64: argument and return type profiling,
	fix problem with popframe
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF401D6@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>
	<2BF1C0EA-DFBC-4F90-AE71-9D5889D4E4FF@oracle.com>
	<5489DA82.6020600@oracle.com> <548A285D.1080905@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF401D6@DEWDFEMB12A.global.corp.sap>
Message-ID: <15A069DD-BB55-4BAA-B47A-0820B0566909@oracle.com>


Go for it!

Cheers,
Mikael

> On Dec 12, 2014, at 00:06, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi,
> 
> ok, here goes the 'heads up': I'm ready to push to jdk8u/hs-dev/hotspot.
> 
> Is that fine?
> 
> Best regards,
>  Goetz.
> 
> 
> -----Original Message-----
> From: Alejandro E Murillo [mailto:alejandro.murillo at oracle.com] 
> Sent: Friday, December 12, 2014 12:27 AM
> To: Vladimir Kozlov; Roland Westrelin; Lindenmaier, Goetz
> Cc: hotspot-dev Source Developers
> Subject: Re: RFR(M): 8066964: ppc64: argument and return type profiling, fix problem with popframe
> 
> 
> Thanks for letting me know Vladimir.
> Goetz, please push this by tomorrow (Friday 12/12/) morning PT,
> as I plan to start the snapshot during  the morning.
> 
> also,  to reduce the chance of collision,
> please send a "heads up" email to this alias right before you start the 
> push,
> in case someone is planning to submit a jprt pushing job to that repo,
> at the same time.
> 
> going forward, we might have to setup a time window
> during the week for these integrations to avoid potential conflicts
> (since jprt jobs take a while before they do the actual push)
> 
> Thanks
> Alejandro
> 
> 
>> On 12/11/2014 10:55 AM, Vladimir Kozlov wrote:
>> Good.
>> 
>> Since changes are ppc64 specific you can push it yourself (make sure 
>> changeset descriptor is correct).
>> Change priority to P3 and you can push it into 8u40 (do it until this 
>> Friday after which we would need approval):
>> 
>> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/
>> 
>> Thanks,
>> Vladimir
>> 
>> On 12/11/14 5:59 AM, Roland Westrelin wrote:
>>>> The change is ppc/aix only.  I would like to get it to jdk8u60 or 40.
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8066964-typeProf/webrev.01/
>>> 
>>> That looks good to me.
>>> 
>>> Roland.
> 
> -- 
> Alejandro
> 

From albert.noll at oracle.com  Fri Dec 12 10:28:50 2014
From: albert.noll at oracle.com (Albert Noll)
Date: Fri, 12 Dec 2014 11:28:50 +0100
Subject: RFR: 8066875: VirtualSpace does not use large pages
In-Reply-To: <548814C1.8010905@oracle.com>
References: <54874F17.7070303@oracle.com> <548814C1.8010905@oracle.com>
Message-ID: <548AC362.8010800@oracle.com>

Hi Erik,

thanks a lot for taking care of this. I have one minor comment (not a 
reviewer):

1418 size_t os::largest_page_size_less_than(size_t sz) {
1419   if (UseLargePages) {
1420     // The page sizes are sorted descendingly.
1421     for (size_t i = 0; _page_sizes[i] != 0; ++i) {
1422       if (_page_sizes[i] <= sz) {
1423         return _page_sizes[i];
1424       }
1425     }
1426   }
1427   return vm_page_size();
1428 }

The function name suggests that the function returns a page size that is 
*less* than the value in the argument (sz).
However, in line 1422 you check for '<=' . I think you should either fix 
the name of the function or the check in line 1422.

Best,
Albert


On 12/10/2014 10:39 AM, Tobias Hartmann wrote:
> Hi Erik,
>
> looks good (not a reviewer).
>
> Thanks,
> Tobias
>
> On 09.12.2014 20:35, Erik Helin wrote:
>> Hi all,
>>
>> the fix for JDK-8049864 [0] made os::page_size_for_region slightly more strict
>> since the function now demands that the given region_size is size aligned with
>> respect to the chosen page_size. The reason for doing this was that
>> os::page_size_for_region was used in two ways:
>> 1. Give me a suitable page size for this amount of memory
>> 2. Give me the largest page size for this amount of memory
>> The fix for JDK-8049864 fixed os::page_size_for_region for the "suitable page
>> size" scenario, but is too strict for the "largest page size" scenario. This
>> caused a regression in VirtualSpace::initialize, which only needs the largest
>> possible page size, since VirtualSpace::initialize_with_granularity takes care
>> of any alignment issues.
>>
>> This patch adds the function os::largest_page_size_less_than and updates
>> VirtualSpace::initialize to use this new function instead of
>> os::page_size_for_region.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8066875/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8066875
>>
>> Testing:
>> - JPRT
>> - Verified that the code cache now uses large pages even if
>>    ReservedCodeCacheSize is 241 MB (see bug for more details).
>> - Added new internal vm tests (also run on SPARC machine with large
>>    pages)
>>
>> Thanks,
>> Erik
>>
>> [0]: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b326a3e8dcab


From sgehwolf at redhat.com  Fri Dec 12 10:46:42 2014
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 12 Dec 2014 11:46:42 +0100
Subject: RFR(S): 8067231: Zero builds fails after JDK-6898462
Message-ID: <1418381202.3181.7.camel@localhost.localdomain>

Hi,

Could somebody please review and sponsor this small change? JDK-6898462
broke the Zero variant build by assuming that
Interpreter::remove_activation_entry() is defined for the C++
interpreter (which it is not). The proposed fix ifdef's it as it's done
elsewhere.

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

Thanks,
Severin


From david.holmes at oracle.com  Fri Dec 12 11:13:01 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Dec 2014 21:13:01 +1000
Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really
	reload given class
In-Reply-To: <548A14E4.7090807@oracle.com>
References: <54872854.90806@oracle.com>	<628BCC0A-43FF-4469-BC0D-FC38BBE53A58@oracle.com>	<54883681.3030307@oracle.com>
	<548A14E4.7090807@oracle.com>
Message-ID: <548ACDBD.4040502@oracle.com>

On 12/12/2014 8:04 AM, Vladimir Kozlov wrote:
> Pavel,
>
> I am resending it to whole hotspot so you can get more help/explanations.
>
> Thanks,
> Vladimir
>
> On 12/10/14 4:03 AM, Pavel Chistyakov wrote:
>> Hi David,
>>
>> Thanks for review.
>>
>> The intent was:
>>
>>   * be able to get */new/* instance of Class w/ given name and given
>> bytecode for every /*new*/ instance of
>>     ByteCodeLoader even if this class was already loaded by parent
>> loader. For this reason, I overrided loadClass to
>>     break delegation to parent loader for given className;

I question why the parent should be able to load the class that is being 
"redefined"? If it can't, then breaking delegation is not necessary. If 
it can and you break delegation then you may be able to load the other 
variants of the class in new classloader instances, but depending on 
what you then do with the class you may get loader constraint violations.

David H.

>>   * make single class definition for ByteCodeLoader instance. Here
>> holder field appears and DCL for it's thread safe
>>     initialization.
>>
>>
>> -------------
>> Pavel
>>
>> On 09.12.2014 23:49, David Chase wrote:
>>> I agree with your changes to loadClass, but I am not sure that this
>>> will allow you to redefine an existing class.  My understanding of
>>> how this would work is that it will allow you re-obtain the class
>>> that was already loaded (but not to fail at this).  Actually
>>> redefining a class requires use of JVMTI (or so I think).
>>>
>>> Was that your intent?
>>>
>>> David
>>>
>>>
>>> On 2014-12-09, at 11:50 AM, Pavel
>>> Chistyakov<pavel.chistyakov at oracle.com>  wrote:
>>>
>>>> Hi all,
>>>>
>>>> please review changes
>>>> for:https://bugs.openjdk.java.net/browse/JDK-8066497
>>>> webrev:http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Eiignatyev/pchistyakov/8066497/webrev.00/>
>>>>
>>>>
>>>> Problem:
>>>> ByteCodeLoader allows one to load class with given name from
>>>> existing bytecode. But if this class is already loaded by e.g.
>>>> system classloader it cannot be redefined using another bytecode
>>>> array because of delegation of loadClass call to parent classloader.
>>>>
>>>> Solution:
>>>> override loadClass to break delegation for given className.
>>>>
>>>> Testing: manual
>>>>
>>>> -------------------
>>>> Thanks,
>>>> Pavel
>>

From hs at tagtraum.com  Fri Dec 12 11:35:43 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 12 Dec 2014 12:35:43 +0100
Subject: Addition to web bug JI-9017423
In-Reply-To: <54897363.8030306@oracle.com>
References: <C8A49FEE-B7BA-45D9-A3B4-899C45457DDA@tagtraum.com>
	<548971D6.7080408@oracle.com>
	<41D8C3E0-150B-4963-A35D-3CB6D09FCB01@tagtraum.com>
	<54897363.8030306@oracle.com>
Message-ID: <D5418CB6-6397-430E-B076-1FA3ABF993F3@tagtraum.com>

>> Do those exist on OS X?
> 
> AFAIK one should have been created by VMError::report_and_die before it calls abort() which triggers the OS X error report.

The crashes did not occur on my machine, but on a customer's.
He was so nice to check and actually found a bunch of them.

You can download them from https://www.beatunes.com/download/JI-9017423_hs_err_logs.zip

Some of them contain a stacktrace (which is pretty much always the same):

Stack: [0x0000000192fd1000,0x00000001930d1000],  sp=0x00000001930cea38,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0xd6ace]  acs_CopyRight+0x70
J 598  sun.misc.Unsafe.copyMemory(Ljava/lang/Object;JLjava/lang/Object;JJ)V (0 bytes) @ 0x000000010a01f5e1 [0x000000010a01f500+0xe1]
J 691 C1 java.nio.Bits.copyToArray(JLjava/lang/Object;JJJ)V (68 bytes) @ 0x000000010a0512ec [0x000000010a051160+0x18c]
j  java.nio.DirectByteBuffer.get([BII)Ljava/nio/ByteBuffer;+98
j  java.nio.ByteBuffer.get([B)Ljava/nio/ByteBuffer;+5
j  org.jaudiotagger.tag.id3.framebody.AbstractID3v2FrameBody.read(Ljava/nio/ByteBuffer;)V+48

The corresponding code call in AbstractID3v2FrameBody.read(ByteBuffer byteBuffer) is:

    byte[] buffer = new byte[size]; // size is a positive integer
    byteBuffer.get(buffer);

The byteBuffer should point to the content of an mp3 file.
So this also seems to indicate some issue with file mapping.

If you have any (simple!) idea how to work around this crash from the top of your head, I'd very much appreciate it.

Thank you,

-hendrik

From tobias.hartmann at oracle.com  Fri Dec 12 12:05:02 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 12 Dec 2014 13:05:02 +0100
Subject: [9] RFR(S): 8067337: Remove Whitebox API from hotspot repository
Message-ID: <548AD9EE.3080207@oracle.com>

Hi,

I forgot to remove the Whitebox API from the hotspot repo while moving it to the
top level repo with JDK-8066433. It should be deleted.

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

Thanks,
Tobias

From igor.ignatyev at oracle.com  Fri Dec 12 12:09:09 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 12 Dec 2014 15:09:09 +0300
Subject: [9] RFR(S): 8067337: Remove Whitebox API from hotspot repository
In-Reply-To: <548AD9EE.3080207@oracle.com>
References: <548AD9EE.3080207@oracle.com>
Message-ID: <548ADAE5.6080807@oracle.com>

looks good.

Igor

On 12/12/2014 03:05 PM, Tobias Hartmann wrote:
> Hi,
>
> I forgot to remove the Whitebox API from the hotspot repo while moving it to the
> top level repo with JDK-8066433. It should be deleted.
>
> https://bugs.openjdk.java.net/browse/JDK-8067337
> http://cr.openjdk.java.net/~thartmann/8067337/webrev.00/
>
> Thanks,
> Tobias
>

From tobias.hartmann at oracle.com  Fri Dec 12 12:10:51 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 12 Dec 2014 13:10:51 +0100
Subject: [9] RFR(S): 8067337: Remove Whitebox API from hotspot repository
In-Reply-To: <548ADAE5.6080807@oracle.com>
References: <548AD9EE.3080207@oracle.com> <548ADAE5.6080807@oracle.com>
Message-ID: <548ADB4B.8000805@oracle.com>

Thanks, Igor.

Best,
Tobias

On 12.12.2014 13:09, Igor Ignatyev wrote:
> looks good.
> 
> Igor
> 
> On 12/12/2014 03:05 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> I forgot to remove the Whitebox API from the hotspot repo while moving it to the
>> top level repo with JDK-8066433. It should be deleted.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8067337
>> http://cr.openjdk.java.net/~thartmann/8067337/webrev.00/
>>
>> Thanks,
>> Tobias
>>

From staffan.larsen at oracle.com  Fri Dec 12 12:41:21 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 12 Dec 2014 13:41:21 +0100
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <548A1FB9.1010306@oracle.com>
References: <542C8274.3010809@gmail.com>
	<FE1302A7-A228-43E9-BCB6-74558268E296@oracle.com>
	<CAGFVN2CPxXC9bhWvdq-wfmbyBGTZCS2gz5dq9jWf6dMCXGMYvg@mail.gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com> <547C079A.9020604@oracle.com>
	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
	<547C1815.6050900@oracle.com>
	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>
	<547C38AD.6050703@gmail.com>
	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
	<547D891D.7010809@oracle.com> <547DCCFB.3050209@gmail.com>
	<54854475.20800@oracle.com>
	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>
	<54868B02.1070408@oracle.com>
	<CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>
	<5486B952.4070708@oracle.com>
	<CAA-vtUyRtwD+08BjZSZY_q5uHGnb8kmW7AZD2TSe=_0h6rgT_A@mail.gmai!	l.com>
	<5486FF9A.2050604@gma! il.com> <5487EA35.6070709@oracle.com>
	<548A1FB9.1010306@! oracle.com>
Message-ID: <1B708380-1C7F-41C5-BEC8-745FEBA95277@oracle.com>

Looks good! Sorry for going away for so long - just too many things right now.

Thanks,
/Staffan

> On 11 dec 2014, at 23:50, David Holmes <david.holmes at oracle.com> wrote:
> 
> Sorry, I've been advised I need a second reviewer with an openjdk user name and as Staffan has not come back to this thread, that means I need one more reviewer from the runtime team please. And please check the email trail on this as it is quite long and I really don't want to revisit covered ground. :) Thanks.
> 
> David
> 
> On 10/12/2014 4:37 PM, David Holmes wrote:
>> Hi Yasumasa,
>> 
>> On 9/12/2014 11:56 PM, Yasumasa Suenaga wrote:
>>> David, Thomas,
>>> 
>>> Thank you so much!
>>> I wait 2nd reviewer.
>> 
>> I'm a Reviewer and I think Thomas counts as a reviewer. Plus Staffan had
>> a look too. So I think this is good to go - though I'll give it till my
>> morning before finalizing it.
>> 
>>> BTW, I'm not a committer.
>>> So I'm also waiting a sponsor :-)
>> 
>> I will sponsor if you can prepare the changeset.
>> 
>> Thanks,
>> David
>> 
>>>> I'm okay with these changes. Just a minor style nit (no need for
>>>> updated webrev) can you remove the blank lines in os_linux.cpp:
>>>> 
>>>> 6011       }
>>>> 6012
>>>> 6013     }
>>>> 6014
>>>> 6015   }
>>>> 
>>>> 6057       }
>>>> 6058
>>>> 6059     }
>>>> 6060
>>>> 6061   }
>>>> 
>>>> If anyone has any objections please raise them asap.
>>> 
>>> I will upload new webrev which is fix them after reviewing.
>>> 
>>> 
>>> Thanks,
>>> 
>>> Yasumasa
>>> 
>>> 
>>> (2014/12/09 21:06), Thomas St?fe wrote:
>>>> Yes, Sure :-) @Yasumasa : thank you for this patch!
>>>> 
>>>> Kind regards, Thomas
>>>> 
>>>> On Dec 9, 2014 9:56 AM, "David Holmes" <david.holmes at oracle.com
>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>> 
>>>>    Hi Thomas,
>>>> 
>>>>    So can we take this as-is for now and file a RFE to address your
>>>> concerns?
>>>> 
>>>>    Anybody else object to that?
>>>> 
>>>>    Thanks,
>>>>    David
>>>> 
>>>>    On 9/12/2014 6:09 PM, Thomas St?fe wrote:
>>>> 
>>>>        Hi David,
>>>> 
>>>>        On Tue, Dec 9, 2014 at 6:39 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 Thomas,
>>>> 
>>>>             On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>>>> 
>>>>                 Hi,
>>>> 
>>>>                 I do not really like the handling of the leading pipe
>>>> symbol:
>>>> 
>>>> 
>>>>             To be fair to Yasumasa this aspect of the fix has been
>>>> the same
>>>>             since Oct 15:
>>>> 
>>>> 
>>>> http://cr.openjdk.java.net/~____ysuenaga/JDK-8059586/webrev.____02/
>>>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/>
>>>> 
>>>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/
>>>> <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/>>
>>>> 
>>>>             and was not flagged.
>>>> 
>>>> 
>>>>        You are right, I did not read those mails close enough.
>>>> 
>>>> 
>>>> 
>>>>                 So, we read the core_pattern, and if the pipe symbol
>>>> is detected, we
>>>>                 write the core pattern minus the pipe symbol but plus
>>>> a leading
>>>>                 quote to
>>>>                 the output; the leading quote then serves as a info
>>>> to the layer
>>>>                 above
>>>>                 in os_posix.cpp to treat this case specially. This
>>>> means the logic
>>>>                 spills out of the platform dependend os_linux.cpp to
>>>> shared code and
>>>>                 this is also difficult to read.
>>>> 
>>>>                 This comes from the fact that "get_core_path()"
>>>> assumes the core
>>>>                 file is
>>>>                 written to the file system. I think it just does not
>>>> fit
>>>>                 anymore, better
>>>>                 would be to replace it with something like
>>>>                 "os::print_core_file_location(____outputStream* os)",
>>>> and the OS
>>>>                 handles
>>>>                 both core path retrieval and the printing. Because
>>>> then the
>>>>                 shared code
>>>>                 does not need to know whether core file gets printed
>>>>                 traditionally or
>>>>                 piped to a executable or whatever.
>>>> 
>>>> 
>>>>             This sounds like a refactoring that I suggested would be
>>>> too disruptive.
>>>> 
>>>> 
>>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015547.html
>>>> 
>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html>
>>>> 
>>>> 
>>>> 
>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html
>>>> 
>>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015547.html>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015557.html
>>>> 
>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html>
>>>> 
>>>> 
>>>> 
>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html
>>>> 
>>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015557.html>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015573.html
>>>> 
>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html>
>>>> 
>>>> 
>>>> 
>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html
>>>> 
>>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015573.html>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>>        I do not think that this would be such a big a change, but it
>>>> also could
>>>>        be done with another patch.
>>>> 
>>>>        Apart from my reservations I stated above the code looks fine
>>>> and is
>>>>        definitly an improvement (just last week I was helplessly
>>>> looking for a
>>>>        core on a machine where core_pattern turned out to be a
>>>> redirection to
>>>>        another program).
>>>> 
>>>>        Kind Regards, Thomas
>>>> 
>>>> 
>>>>             David
>>>> 


From tatiana.pivovarova at oracle.com  Fri Dec 12 12:46:19 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Fri, 12 Dec 2014 15:46:19 +0300
Subject: RFR(S): 8067211: rewrite Utils::fileAsString
In-Reply-To: <548AE189.9020800@oracle.com>
References: <548AE189.9020800@oracle.com>
Message-ID: <548AE39B.2080808@oracle.com>

Added hotspot-dev at openjdk.java.net

On 12/12/2014 03:37 PM, Tatiana Pivovarova wrote:
> Hi all,
>
> please review this small patch
>
> bugid: https://bugs.openjdk.java.net/browse/JDK-8067211
> webrev: 
> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8067211/webrev.00/
>
> Problem:
> Utils::fileAsString implementation has several issues:
>  - using '\n' instead of platform independent EOL
>  - catching wide spectre of exceptions and "ignoring" them
>  - partially duplicates code of Utils::fileAsList method which 
> duplicates File::readAllLines
>
> Solution:
>  - using library method for reading lines
>  - using system property for EndOfLine.
>
> Testing: jprt
>
> Thanks,
> Tatiana


From roland.westrelin at oracle.com  Fri Dec 12 15:14:44 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 12 Dec 2014 16:14:44 +0100
Subject: RFR(S): 8067231: Zero builds fails after JDK-6898462
In-Reply-To: <1418381202.3181.7.camel@localhost.localdomain>
References: <1418381202.3181.7.camel@localhost.localdomain>
Message-ID: <5AD44E86-27A7-40A7-9B8F-30AA072267A6@oracle.com>

> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067231/webrev.01/

That looks good to me. Thanks for fixing it. I?ll sponsor this fix.

Roland.

From sgehwolf at redhat.com  Fri Dec 12 15:29:07 2014
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 12 Dec 2014 16:29:07 +0100
Subject: RFR(S): 8067231: Zero builds fails after JDK-6898462
In-Reply-To: <5AD44E86-27A7-40A7-9B8F-30AA072267A6@oracle.com>
References: <1418381202.3181.7.camel@localhost.localdomain>
	<5AD44E86-27A7-40A7-9B8F-30AA072267A6@oracle.com>
Message-ID: <1418398147.3181.64.camel@localhost.localdomain>

On Fri, 2014-12-12 at 16:14 +0100, Roland Westrelin wrote:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067231/webrev.01/
> 
> That looks good to me. Thanks for fixing it. I?ll sponsor this fix.
> 
> Roland.

Thank you, Roland!

Cheers,
Severin


From coleen.phillimore at oracle.com  Fri Dec 12 15:55:22 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 12 Dec 2014 10:55:22 -0500
Subject: RFR(S): 8067231: Zero builds fails after JDK-6898462
In-Reply-To: <1418398147.3181.64.camel@localhost.localdomain>
References: <1418381202.3181.7.camel@localhost.localdomain>	<5AD44E86-27A7-40A7-9B8F-30AA072267A6@oracle.com>
	<1418398147.3181.64.camel@localhost.localdomain>
Message-ID: <548B0FEA.5010402@oracle.com>


The fix looks good to me also.
Coleen

On 12/12/14, 10:29 AM, Severin Gehwolf wrote:
> On Fri, 2014-12-12 at 16:14 +0100, Roland Westrelin wrote:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067231/webrev.01/
>> That looks good to me. Thanks for fixing it. I?ll sponsor this fix.
>>
>> Roland.
> Thank you, Roland!
>
> Cheers,
> Severin
>


From max.ockner at oracle.com  Fri Dec 12 16:02:28 2014
From: max.ockner at oracle.com (Max Ockner)
Date: Fri, 12 Dec 2014 11:02:28 -0500
Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
In-Reply-To: <5488B705.6060203@oracle.com>
References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com>
	<545CF033.4010503@oracle.com> <54619729.30704@oracle.com>
	<546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com>
	<5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com>
	<54887B57.2050201@oracle.com> <5488B705.6060203@oracle.com>
Message-ID: <548B1194.1090905@oracle.com>

OK, I have made these changes.
Thanks to everyone who helped me through this, especially Dan, David, 
and Coleen.

On 12/10/2014 4:11 PM, Daniel D. Daugherty wrote:
> On 12/10/14 9:56 AM, Max Ockner wrote:
>> New webrev: http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/
>
> Thumbs up! No need for a re-review if you address any of the
> formatting comments below.
>
> Repeat from last time (I've seen trailing white space in this
> round; haven't checked for the other jcheck-ish things).
>
> - jcheck is going to complain about some of your lines that
>   have trailing white space:
>
>   $ grep -n '  *$' `cat files.list`
>   $ grep -n '\t' `cat files.list`
>
>   Don't know if you have any tabs, but I included that one also.
>   Not all platforms like '\t' for the grep parameter.
>
> - jcheck may also complain about the blank lines at the end
>   of the new tests
>
> src/share/vm/runtime/mutex.hpp
>     line 197:           SafepointCheckRequired 
> safepoint_check_required =  _safepoint_check_always);
>         One space too many after the '='.
>
>         Also, I see an extra space at the end of the line; jcheck
>         will not be happy.
>
> src/share/vm/runtime/mutex.cpp
>     No comments.
>
> src/share/vm/runtime/mutexLocker.cpp
>     line 174:   }
>         Should be moved left by two spaces (i.e., one indent to the
>         left of the code block above it).
>
> src/share/vm/runtime/thread.cpp
>     No comments.
>
> src/share/vm/runtime/vmThread.cpp
>     No comments.
>
> src/os/aix/vm/osThread_aix.cpp
>     No comments.
>
> src/os/bsd/vm/osThread_bsd.cpp
>     No comments.
>
> src/os/linux/vm/osThread_linux.cpp
>     No comments.
>
> src/share/vm/classfile/classLoaderData.cpp
>     No comments.
>
> src/share/vm/memory/metaspace.cpp
>     No comments.
>
> src/share/vm/runtime/vm_operations.cpp
>     No comments.
>
> src/share/vm/memory/sharedHeap.cpp
>     No comments.
>
> src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>
>     No comments.
>
> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 
>
>     line 6391:   _lock(mutex_rank >= 0 ? new Mutex(mutex_rank, 
> mutex_name, true ,
>         Extra space before the last comma.
>
> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp 
>
>     No comments.
>
> src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
>     No comments.
>
> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
>     No comments.
>
> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
>     No comments.
>
> src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
>     No comments.
>
> src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
>     No comments.
>
> src/share/vm/services/diagnosticFramework.cpp
>     No comments.
>
> src/share/vm/services/memoryManager.cpp
>     No comments.
>
> src/share/vm/utilities/decoder.cpp
>     No comments.
>
> src/share/vm/utilities/events.hpp
>     No comments.
>
> src/share/vm/utilities/workgroup.cpp
>     No comments.
>
> src/share/vm/prims/whitebox.cpp
>     line 1045: WB_END
>         Please add a blank line after this line.
>
> test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
>     No comments.
>
> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java
>     line 42: WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, 
> true);
>         Java code indent is four spaces.
>
> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java
>     line 42: 
> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, false);
>         Java code indent is four spaces.
>
> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java
>     line 42: 
> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, true);
>         Java code indent is four spaces.
>
> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java
>     line 42: WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, 
> false);
>         Java code indent is four spaces.
>
> Dan
>
>
>
>>
>> I have addressed dan's suggestions. I also removed unnecessary 
>> "this->" occurrences from the assert statements.
>>
>> Though I realize that I have unnecessarily duplicated code in my 
>> tests, I do not want to combine the tests into one right now because 
>> (1) They work as they are, (2) They can fail independently, (3) The 
>> amount of code needed to run all four tests in one file without 
>> crashing out after the first failure is not as small as you might 
>> think, and (4) I want to commit this before someone else messes with 
>> the locks to avoid more merge conflicts. To be clear, I am not 
>> opposed to fixing this separately if people think it is important, 
>> but I prefer to put it off until the bulk of the fix is committed.
>>
>> Does this look ready?
>>
>> Thanks for your help,
>> Max O
>>
>>
>>
>> On 12/8/2014 1:39 AM, David Holmes wrote:
>>> Hi Max,
>>>
>>> Just a nit with the tests - it seems to me we should be able to 
>>> write a single Java class that can process all four combinations 
>>> rather than duplicating the bulk of the code.
>>>
>>> Thanks,
>>> David
>>>
>>> On 5/12/2014 7:50 AM, Max Ockner wrote:
>>>> Hello once again...
>>>> I have a new (and suggestively titled) webrev:
>>>> http://cr.openjdk.java.net/~coleenp/8047290final/
>>>>
>>>> Ran aurora tests.
>>>>
>>>> Here is a list of "sometimes" locks:
>>>>
>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>> "CompactibleFreeListSpace._lock"
>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>
>>>> "freelist par lock"
>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>
>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>> "CMS_markBitMap_lock"
>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp 
>>>>
>>>>
>>>>
>>>> The remaining "sometimes" locks can be found in
>>>> share/vm/runtime/mutexLocker.cpp:
>>>>
>>>> ParGCRareEvent_lock
>>>> Safepoint_lock
>>>> Threads_lock
>>>> VMOperationQueue_lock
>>>> VMOperationRequest_lock
>>>> Terminator_lock
>>>> Heap_lock
>>>> Compile_lock
>>>> PeriodicTask_lock
>>>> JfrStacktrace_lock
>>>>
>>>>
>>>> Thanks,
>>>> Max Ockner
>>>>
>>>>
>>>>
>>>>
>>>> On 11/25/2014 3:03 AM, David Holmes wrote:
>>>>> Hi Max,
>>>>>
>>>>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>>>>> Hello again,
>>>>>>
>>>>>> I have made changes based on all comments. There is now a pair of 
>>>>>> assert
>>>>>> statements in the Monitor/Mutex wait() methods. When I reran 
>>>>>> tests, I
>>>>>
>>>>> Is there an updated webrev?
>>>>>
>>>>>> caught another lock that I had to change to "sometimes", but the 
>>>>>> assert
>>>>>> that caught this lock was not in wait. There are currently no 
>>>>>> locks that
>>>>>> use try to pass an incorrect safepoint check argument to wait().
>>>>>> Instead, gcbasher did not catch this lock last time, when the only
>>>>>> asserts were in lock and lock_without_safepoint. This lock is
>>>>>> "CMS_markBitMap_lock" in
>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. 
>>>>>>
>>>>>>
>>>>>> I'm guessing that it was not caught by the tests because this 
>>>>>> section of
>>>>>> code is not reached very often. My initial inspection failed to 
>>>>>> catch
>>>>>> this lock because it is passed around between various structures and
>>>>>> renamed 4 times. I have not yet found a good way to check for this
>>>>>> situation, even with a debugger.
>>>>>>
>>>>>> Are there any tests which actually manage to hit every line of code?
>>>>>
>>>>> No. There is too much code that is dependent on low-level details of
>>>>> the GC used, the compilation strategy, plus the set of runtime flags
>>>>> used (and whether product or fastdebug). That's why we have lots of
>>>>> tests run in lots of different ways, to try to get coverage.
>>>>>
>>>>>> How should I handle this situation where I can't rely on the 
>>>>>> tests that
>>>>>> I have run to tell me if I have missed something?
>>>>>> At what point can I assume that everything is OK?
>>>>>
>>>>> Difficult to answer in general - there are a number of recommended
>>>>> test suites used by the runtime team, but your changes will also
>>>>> impact GC and compiler code and so may not get exercised by the
>>>>> runtime test suites (unless run with various compiler and GC 
>>>>> options).
>>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push after 
>>>>> the
>>>>> weekly snapshot so as to maximise nightly testing, and if there are
>>>>> issues exposed then you have time to address them or revert the fix.
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>> Thanks,
>>>>>> Max Ockner
>>>>>>
>>>>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>>>>> Hi Max,
>>>>>>>
>>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>>>>> Hello all,
>>>>>>>> I have made these additonal changes:
>>>>>>>> -Moved the assert() statements into the lock and
>>>>>>>> lock_without_safepoint
>>>>>>>> methods.
>>>>>>>> -Changed Monitor::SafepointAllowed to 
>>>>>>>> Monitor::SafepointCheckRequired
>>>>>>>> -Changed the Monitor::SafepointCheckRequired values for several 
>>>>>>>> locks
>>>>>>>> which were locked outside of a MutexLockerEx (some were locked 
>>>>>>>> with
>>>>>>>> MutexLocker, some were locked were locked without any 
>>>>>>>> MutexLocker* )
>>>>>>>>
>>>>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/
>>>>>>>
>>>>>>> Generally this is all okay - a few style and other nits below.
>>>>>>>
>>>>>>> However you missed adding an assert in Monitor::wait to check if 
>>>>>>> the
>>>>>>> no_safepoint_check flag was being used correctly for the current
>>>>>>> monitor.
>>>>>>>
>>>>>>> Specific comments:
>>>>>>>
>>>>>>> src/share/vm/runtime/mutex.hpp
>>>>>>>
>>>>>>> This comment is no longer accurate with the moved check location:
>>>>>>>
>>>>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>>>>> + // to ensure consistent checking for each lock.
>>>>>>>
>>>>>>> The same goes for other references to MutexLockerEx in the enum
>>>>>>> description.
>>>>>>>
>>>>>>> Also copyright year needs updating.
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> src/share/vm/runtime/mutex.cpp
>>>>>>>
>>>>>>>  898   //Ensure
>>>>>>>  961   //Ensure
>>>>>>>
>>>>>>> Space needed after //
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>>>
>>>>>>> +  var = new type(Mutex::pri, #var,
>>>>>>> vm_block,safepoint_check_allowed); \
>>>>>>>
>>>>>>> space needed after comma in k,s
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>>>>
>>>>>>> Whitespace only changes - looks like leftovers from removed edits.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> Additional testing:
>>>>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>>>>> jtreg jfr tests
>>>>>>>>
>>>>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>>>>
>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>>>> "SLTMonitor" 
>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>>>> "CompactibleFreeListSpace._lock"
>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> "freelist par lock"
>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>>>
>>>>>>>> The remaining "sometimes" locks can be found in
>>>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>>>
>>>>>>>> ParGCRareEvent_lock
>>>>>>>> Safepoint_lock
>>>>>>>> Threads_lock
>>>>>>>> VMOperationQueue_lock
>>>>>>>> VMOperationRequest_lock
>>>>>>>> Terminator_lock
>>>>>>>> Heap_lock
>>>>>>>> Compile_lock
>>>>>>>> PeriodicTask_lock
>>>>>>>> JfrStacktrace_lock
>>>>>>>>
>>>>>>>> I have not checked the validity of the "sometimes" locks, and I
>>>>>>>> believe
>>>>>>>> that this should be a different project.
>>>>>>>>
>>>>>>>> Thanks for your help!
>>>>>>>> Max Ockner
>>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>>>>> Hi Max,
>>>>>>>>>
>>>>>>>>> This is looking good.
>>>>>>>>>
>>>>>>>>> A few high-level initial comments:
>>>>>>>>>
>>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>>>>
>>>>>>>>> Why are the checks in MutexLocker when the state is maintained 
>>>>>>>>> in the
>>>>>>>>> mutex itself and the mutex/monitor has lock_without_safepoint, 
>>>>>>>>> and
>>>>>>>>> wait(<safepoint checking flag>) ? I would have expected to see 
>>>>>>>>> the
>>>>>>>>> check in the mutex/monitor methods.
>>>>>>>>>
>>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is 
>>>>>>>>> good.
>>>>>>>>> But
>>>>>>>>> another part of this is that a monitor/mutex that never checks 
>>>>>>>>> for
>>>>>>>>> safepoints should never be held when a thread blocks at a 
>>>>>>>>> safepoint -
>>>>>>>>> is there some way to easily check that? I was surprised how many
>>>>>>>>> locks
>>>>>>>>> are actually not checking for safepoints.
>>>>>>>>>
>>>>>>>>> Did you find any cases where the mutex/monitor was being used
>>>>>>>>> inconsistently and incorrectly?
>>>>>>>>>
>>>>>>>>> Did you analyse the "sometimes" cases to see if they were safe?
>>>>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>>>>> Threads_lock with a safepoint check and a safepoint has been
>>>>>>>>> requested
>>>>>>>>> :) ).
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I am a new member of the Hotspot runtime team in Burlington, MA.
>>>>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>>>>
>>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or 
>>>>>>>>>> without a
>>>>>>>>>> safepoint check.
>>>>>>>>>> In some cases, a particular lock must either safepoint check
>>>>>>>>>> always or
>>>>>>>>>> never to avoid deadlocking.
>>>>>>>>>> Some other locks have semantics which allow them to avoid 
>>>>>>>>>> deadlocks
>>>>>>>>>> despite having a safepoint check only some of the time.
>>>>>>>>>> All locks that are OK having inconsistent safepoint checks 
>>>>>>>>>> have been
>>>>>>>>>> marked. All locks that should never safepoint check and all 
>>>>>>>>>> locks
>>>>>>>>>> that
>>>>>>>>>> should always safepoint check have also been marked.
>>>>>>>>>> When a MutexLockerEx acquires a lock with or without a safepoint
>>>>>>>>>> check,
>>>>>>>>>> the lock's safepointAllowed marker is checked to ensure 
>>>>>>>>>> consistent
>>>>>>>>>> safepoint checking.
>>>>>>>>>>
>>>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>>>>
>>>>>>>>>> Tested with:
>>>>>>>>>>      jprt "-testset hotspot"
>>>>>>>>>>      jtreg hotspot
>>>>>>>>>>      vm.quick.testlist
>>>>>>>>>>
>>>>>>>>>> Whitebox tests:
>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: 
>>>>>>>>>> Test
>>>>>>>>>> expects Assert ("This lock should always have a safepoint 
>>>>>>>>>> check")
>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: 
>>>>>>>>>> Test
>>>>>>>>>> expects Assert ("This lock should never have a safepoint check")
>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: 
>>>>>>>>>> code
>>>>>>>>>> should not assert. (Lock is properly acquired with no safepoint
>>>>>>>>>> check)
>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: 
>>>>>>>>>> code
>>>>>>>>>> should not assert. (Lock is properly acquired with safepoint 
>>>>>>>>>> check)
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Max
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>


From alejandro.murillo at oracle.com  Fri Dec 12 16:06:29 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Fri, 12 Dec 2014 09:06:29 -0700
Subject: RFR(M): 8066964: ppc64: argument and return type profiling, fix
	problem with popframe
In-Reply-To: <15A069DD-BB55-4BAA-B47A-0820B0566909@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>
	<2BF1C0EA-DFBC-4F90-AE71-9D5889D4E4FF@oracle.com>
	<5489DA82.6020600@oracle.com> <548A285D.1080905@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF401D6@DEWDFEMB12A.global.corp.sap>
	<15A069DD-BB55-4BAA-B47A-0820B0566909@oracle.com>
Message-ID: <548B1285.6070409@oracle.com>


Thanks guys,
this is just to be aware that an external push has been done,
in case someone happen to have a jprt job running at that time.
going forward we need to come up with an automated solution

Alejandro

On 12/12/2014 1:35 AM, Mikael Vidstedt wrote:
> Go for it!
>
> Cheers,
> Mikael
>
>> On Dec 12, 2014, at 00:06, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>>
>> Hi,
>>
>> ok, here goes the 'heads up': I'm ready to push to jdk8u/hs-dev/hotspot.
>>
>> Is that fine?
>>
>> Best regards,
>>   Goetz.
>>
>>
>> -----Original Message-----
>> From: Alejandro E Murillo [mailto:alejandro.murillo at oracle.com]
>> Sent: Friday, December 12, 2014 12:27 AM
>> To: Vladimir Kozlov; Roland Westrelin; Lindenmaier, Goetz
>> Cc: hotspot-dev Source Developers
>> Subject: Re: RFR(M): 8066964: ppc64: argument and return type profiling, fix problem with popframe
>>
>>
>> Thanks for letting me know Vladimir.
>> Goetz, please push this by tomorrow (Friday 12/12/) morning PT,
>> as I plan to start the snapshot during  the morning.
>>
>> also,  to reduce the chance of collision,
>> please send a "heads up" email to this alias right before you start the
>> push,
>> in case someone is planning to submit a jprt pushing job to that repo,
>> at the same time.
>>
>> going forward, we might have to setup a time window
>> during the week for these integrations to avoid potential conflicts
>> (since jprt jobs take a while before they do the actual push)
>>
>> Thanks
>> Alejandro
>>
>>
>>> On 12/11/2014 10:55 AM, Vladimir Kozlov wrote:
>>> Good.
>>>
>>> Since changes are ppc64 specific you can push it yourself (make sure
>>> changeset descriptor is correct).
>>> Change priority to P3 and you can push it into 8u40 (do it until this
>>> Friday after which we would need approval):
>>>
>>> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 12/11/14 5:59 AM, Roland Westrelin wrote:
>>>>> The change is ppc/aix only.  I would like to get it to jdk8u60 or 40.
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8066964-typeProf/webrev.01/
>>>> That looks good to me.
>>>>
>>>> Roland.
>> -- 
>> Alejandro
>>

-- 
Alejandro


From goetz.lindenmaier at sap.com  Fri Dec 12 16:16:13 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 12 Dec 2014 16:16:13 +0000
Subject: RFR(M): 8066964: ppc64: argument and return type profiling, fix
	problem with popframe
In-Reply-To: <548B1285.6070409@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF3E186@DEWDFEMB12A.global.corp.sap>
	<2BF1C0EA-DFBC-4F90-AE71-9D5889D4E4FF@oracle.com>
	<5489DA82.6020600@oracle.com> <548A285D.1080905@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF401D6@DEWDFEMB12A.global.corp.sap>
	<15A069DD-BB55-4BAA-B47A-0820B0566909@oracle.com>
	<548B1285.6070409@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF40E46@DEWDFEMB12A.global.corp.sap>

Automation would make me feel good ;)
This is a lot like dealing with a black box for me.
Also access to jprt would be magnificent!!!

I found out I need to register to a lot more mailing lists now...

Best regards,
  Goetz.

-----Original Message-----
From: Alejandro E Murillo [mailto:alejandro.murillo at oracle.com] 
Sent: Friday, December 12, 2014 5:06 PM
To: Mikael Vidstedt; Lindenmaier, Goetz
Cc: Vladimir Kozlov; Roland Westrelin; hotspot-dev Source Developers
Subject: Re: RFR(M): 8066964: ppc64: argument and return type profiling, fix problem with popframe


Thanks guys,
this is just to be aware that an external push has been done,
in case someone happen to have a jprt job running at that time.
going forward we need to come up with an automated solution

Alejandro

On 12/12/2014 1:35 AM, Mikael Vidstedt wrote:
> Go for it!
>
> Cheers,
> Mikael
>
>> On Dec 12, 2014, at 00:06, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
>>
>> Hi,
>>
>> ok, here goes the 'heads up': I'm ready to push to jdk8u/hs-dev/hotspot.
>>
>> Is that fine?
>>
>> Best regards,
>>   Goetz.
>>
>>
>> -----Original Message-----
>> From: Alejandro E Murillo [mailto:alejandro.murillo at oracle.com]
>> Sent: Friday, December 12, 2014 12:27 AM
>> To: Vladimir Kozlov; Roland Westrelin; Lindenmaier, Goetz
>> Cc: hotspot-dev Source Developers
>> Subject: Re: RFR(M): 8066964: ppc64: argument and return type profiling, fix problem with popframe
>>
>>
>> Thanks for letting me know Vladimir.
>> Goetz, please push this by tomorrow (Friday 12/12/) morning PT,
>> as I plan to start the snapshot during  the morning.
>>
>> also,  to reduce the chance of collision,
>> please send a "heads up" email to this alias right before you start the
>> push,
>> in case someone is planning to submit a jprt pushing job to that repo,
>> at the same time.
>>
>> going forward, we might have to setup a time window
>> during the week for these integrations to avoid potential conflicts
>> (since jprt jobs take a while before they do the actual push)
>>
>> Thanks
>> Alejandro
>>
>>
>>> On 12/11/2014 10:55 AM, Vladimir Kozlov wrote:
>>> Good.
>>>
>>> Since changes are ppc64 specific you can push it yourself (make sure
>>> changeset descriptor is correct).
>>> Change priority to P3 and you can push it into 8u40 (do it until this
>>> Friday after which we would need approval):
>>>
>>> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 12/11/14 5:59 AM, Roland Westrelin wrote:
>>>>> The change is ppc/aix only.  I would like to get it to jdk8u60 or 40.
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8066964-typeProf/webrev.01/
>>>> That looks good to me.
>>>>
>>>> Roland.
>> -- 
>> Alejandro
>>

-- 
Alejandro


From max.ockner at oracle.com  Fri Dec 12 20:21:22 2014
From: max.ockner at oracle.com (Max Ockner)
Date: Fri, 12 Dec 2014 15:21:22 -0500
Subject: RFR:8064319:Enable -XX:+TraceExceptions in product builds.
Message-ID: <548B4E42.6070207@oracle.com>

Hello all,
Please review my small fix for the TraceExceptions command line argument.

Bug:   https://bugs.openjdk.java.net/browse/JDK-8064319
Webrev:   http://cr.openjdk.java.net/~coleenp/8064319/
Summary:    -XX:+TraceExceptions was previously enabled only in 
development/debug versions, and not in product builds. Now it is enabled 
in product builds as well.
Tested with JPRT and updated TraceExceptions.java test.

Thanks,
Max Ockner

From alejandro.murillo at oracle.com  Fri Dec 12 21:31:46 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Fri, 12 Dec 2014 14:31:46 -0700
Subject: [8u40] IMPORTANT INFO: Please do not push any changeset to
	jdk8u/hs-dev until further notice
Message-ID: <548B5EC2.4060203@oracle.com>


Hotspot developers:

I just took the last snapshot of jdk8u/hs-dev [1] before 8u40 enters the 
RDP2 phase.
that repository will become associated to 8u60 next week, after 8u40-b19 
is promoted.
Until then  please refrain from pushing any changes to it. I will reply 
this email
when that happens

Going forward,
Hotspot changes destined for 8u40 will need to be approved by the 
releasing team (see [2] for details).
Once approved, they should be pushed to jdk8u/hs-dev as usual, and then 
I will
take all 8u40 approved changes from there to the jdk8u40 stabilization 
repo (see [3])
after going through PIT (if needed).

thanks

[1]  http://hg.openjdk.java.net/jdk8u/hs-dev/
[2] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html
[3] 
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-December/002677.html

-- 
Alejandro


From dean.long at oracle.com  Fri Dec 12 22:11:36 2014
From: dean.long at oracle.com (Dean Long)
Date: Fri, 12 Dec 2014 14:11:36 -0800
Subject: RFR:8064319:Enable -XX:+TraceExceptions in product builds.
In-Reply-To: <548B4E42.6070207@oracle.com>
References: <548B4E42.6070207@oracle.com>
Message-ID: <548B6818.4010401@oracle.com>

Do you need a CCC request for this?

dl

On 12/12/2014 12:21 PM, Max Ockner wrote:
> Hello all,
> Please review my small fix for the TraceExceptions command line argument.
>
> Bug:   https://bugs.openjdk.java.net/browse/JDK-8064319
> Webrev:   http://cr.openjdk.java.net/~coleenp/8064319/
> Summary:    -XX:+TraceExceptions was previously enabled only in 
> development/debug versions, and not in product builds. Now it is 
> enabled in product builds as well.
> Tested with JPRT and updated TraceExceptions.java test.
>
> Thanks,
> Max Ockner


From calvin.cheung at oracle.com  Fri Dec 12 22:23:59 2014
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 12 Dec 2014 14:23:59 -0800
Subject: RFR:8064319:Enable -XX:+TraceExceptions in product builds.
In-Reply-To: <548B4E42.6070207@oracle.com>
References: <548B4E42.6070207@oracle.com>
Message-ID: <548B6AFF.7000302@oracle.com>

Max,

The fix looks good.

I think it requires a CCC request for changing a flag to a product flag.
e.g. there was a CCC request for 
https://bugs.openjdk.java.net/browse/JDK-8047934

thanks,
Calvin

On 12/12/2014 12:21 PM, Max Ockner wrote:
> Hello all,
> Please review my small fix for the TraceExceptions command line argument.
>
> Bug:   https://bugs.openjdk.java.net/browse/JDK-8064319
> Webrev:   http://cr.openjdk.java.net/~coleenp/8064319/
> Summary:    -XX:+TraceExceptions was previously enabled only in 
> development/debug versions, and not in product builds. Now it is 
> enabled in product builds as well.
> Tested with JPRT and updated TraceExceptions.java test.
>
> Thanks,
> Max Ockner


From dean.long at oracle.com  Fri Dec 12 23:08:00 2014
From: dean.long at oracle.com (Dean Long)
Date: Fri, 12 Dec 2014 15:08:00 -0800
Subject: Addition to web bug JI-9017423
In-Reply-To: <D5418CB6-6397-430E-B076-1FA3ABF993F3@tagtraum.com>
References: <C8A49FEE-B7BA-45D9-A3B4-899C45457DDA@tagtraum.com>	<548971D6.7080408@oracle.com>	<41D8C3E0-150B-4963-A35D-3CB6D09FCB01@tagtraum.com>	<54897363.8030306@oracle.com>
	<D5418CB6-6397-430E-B076-1FA3ABF993F3@tagtraum.com>
Message-ID: <548B7550.5000907@oracle.com>

This sounds a lot like https://bugs.openjdk.java.net/browse/JDK-8041721.

If this crash is reproducible, could you run the app with syscall 
tracing enabled?
(I know Linux has "strace", but I don't know about OSX.)  I'm wondering 
if there
is a stray mprotect or munmap happening on the mapped memory.

dl

On 12/12/2014 3:35 AM, Hendrik Schreiber wrote:
>>> Do those exist on OS X?
>> AFAIK one should have been created by VMError::report_and_die before it calls abort() which triggers the OS X error report.
> The crashes did not occur on my machine, but on a customer's.
> He was so nice to check and actually found a bunch of them.
>
> You can download them from https://www.beatunes.com/download/JI-9017423_hs_err_logs.zip
>
> Some of them contain a stacktrace (which is pretty much always the same):
>
> Stack: [0x0000000192fd1000,0x00000001930d1000],  sp=0x00000001930cea38,  free space=1014k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.dylib+0xd6ace]  acs_CopyRight+0x70
> J 598  sun.misc.Unsafe.copyMemory(Ljava/lang/Object;JLjava/lang/Object;JJ)V (0 bytes) @ 0x000000010a01f5e1 [0x000000010a01f500+0xe1]
> J 691 C1 java.nio.Bits.copyToArray(JLjava/lang/Object;JJJ)V (68 bytes) @ 0x000000010a0512ec [0x000000010a051160+0x18c]
> j  java.nio.DirectByteBuffer.get([BII)Ljava/nio/ByteBuffer;+98
> j  java.nio.ByteBuffer.get([B)Ljava/nio/ByteBuffer;+5
> j  org.jaudiotagger.tag.id3.framebody.AbstractID3v2FrameBody.read(Ljava/nio/ByteBuffer;)V+48
>
> The corresponding code call in AbstractID3v2FrameBody.read(ByteBuffer byteBuffer) is:
>
>      byte[] buffer = new byte[size]; // size is a positive integer
>      byteBuffer.get(buffer);
>
> The byteBuffer should point to the content of an mp3 file.
> So this also seems to indicate some issue with file mapping.
>
> If you have any (simple!) idea how to work around this crash from the top of your head, I'd very much appreciate it.
>
> Thank you,
>
> -hendrik


From hs at tagtraum.com  Sun Dec 14 01:36:45 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Sun, 14 Dec 2014 02:36:45 +0100
Subject: Addition to web bug JI-9017423
In-Reply-To: <548B7550.5000907@oracle.com>
References: <C8A49FEE-B7BA-45D9-A3B4-899C45457DDA@tagtraum.com>
	<548971D6.7080408@oracle.com>
	<41D8C3E0-150B-4963-A35D-3CB6D09FCB01@tagtraum.com>
	<54897363.8030306@oracle.com>
	<D5418CB6-6397-430E-B076-1FA3ABF993F3@tagtraum.com>
	<548B7550.5000907@oracle.com>
Message-ID: <ABA55846-E499-4FAE-97E2-F5D2667FDE5B@tagtraum.com>

On Dec 13, 2014, at 00:08, Dean Long <dean.long at oracle.com> wrote:
> 
> This sounds a lot like https://bugs.openjdk.java.net/browse/JDK-8041721.
> 
> If this crash is reproducible, could you run the app with syscall tracing enabled?
> (I know Linux has "strace", but I don't know about OSX.)  I'm wondering if there
> is a stray mprotect or munmap happening on the mapped memory.

I don't really have an opinion on whether this may be a duplicate of JDK-8041721. As far as I can tell it does not say anything about memory mapped direct byte buffers there.

Anyhow. Unfortunately, the customer the crash logs are from has since deleted the one file he had the problem with, so it looks like this problem is not reproducible anymore :-(

Bummer.

-hendrik

From staffan.larsen at oracle.com  Sun Dec 14 19:43:45 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Sun, 14 Dec 2014 20:43:45 +0100
Subject: RFR:8064319:Enable -XX:+TraceExceptions in product builds.
In-Reply-To: <548B4E42.6070207@oracle.com>
References: <548B4E42.6070207@oracle.com>
Message-ID: <D6190766-8ABD-4A25-B0F0-A13E32BCBB2C@oracle.com>

Thank you! Looks good!

/Staffan


> On 12 dec 2014, at 21:21, Max Ockner <max.ockner at oracle.com> wrote:
> 
> Hello all,
> Please review my small fix for the TraceExceptions command line argument.
> 
> Bug:   https://bugs.openjdk.java.net/browse/JDK-8064319
> Webrev:   http://cr.openjdk.java.net/~coleenp/8064319/
> Summary:    -XX:+TraceExceptions was previously enabled only in development/debug versions, and not in product builds. Now it is enabled in product builds as well.
> Tested with JPRT and updated TraceExceptions.java test.
> 
> Thanks,
> Max Ockner


From alexyursha at gmail.com  Sun Dec 14 20:47:06 2014
From: alexyursha at gmail.com (Alex Yursha)
Date: Sun, 14 Dec 2014 23:47:06 +0300
Subject: What is the primary development platform for OpenJDK HotSpot JVM?
Message-ID: <14179A91-A2C3-493A-AD28-7947AB4AC3BB@gmail.com>

Many projects are firstly developed for one target platform and only afterwords ported to other platforms. I wonder if there exists such first target platform for HotSpot JVM or is it developed in parallel for different platforms?

From david.holmes at oracle.com  Sun Dec 14 22:53:59 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Dec 2014 08:53:59 +1000
Subject: What is the primary development platform for OpenJDK HotSpot JVM?
In-Reply-To: <14179A91-A2C3-493A-AD28-7947AB4AC3BB@gmail.com>
References: <14179A91-A2C3-493A-AD28-7947AB4AC3BB@gmail.com>
Message-ID: <548E1507.6070407@oracle.com>

On 15/12/2014 6:47 AM, Alex Yursha wrote:
> Many projects are firstly developed for one target platform and only afterwords ported to other platforms. I wonder if there exists such first target platform for HotSpot JVM or is it developed in parallel for different platforms?

Are you talking historically ie what was the first platform that hotspot 
ran on? (I think it was Windows but not 100% sure). Or do you mean 
currently are new features developed on one platform and then ported to 
the others? For this latter question typically new features are 
prototyped on the platform most accessible to the developer doing the 
work, but quickly ported to the other platforms - often only becoming 
visible to others once all platforms are supported.

David


From david.holmes at oracle.com  Mon Dec 15 01:22:56 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Dec 2014 11:22:56 +1000
Subject: RFR: JDK-8059586: hs_err report should treat redirected core
	pattern.
In-Reply-To: <1B708380-1C7F-41C5-BEC8-745FEBA95277@oracle.com>
References: <542C8274.3010809@gmail.com>
	<CAA-vtUx5iVr6=CoywjdnyH4mkP1_zdpOceW0TMeYSTsND_PUDg@mail.gmail.com>
	<5479E9DE.7070703@gmail.com> <547C079A.9020604@oracle.com>
	<CAA-vtUwB6mM=1Y-8h_PVOD1LJWuKRFmb6W2h1LSyFXNTuvQm9A@mail.gmail.com>
	<547C1815.6050900@oracle.com>
	<CAA-vtUyBXaaVbouPXh36zm6RCjH3ub=wwSbRRfVuYT15UxYysw@mail.gmail.com>
	<547C38AD.6050703@gmail.com>
	<CAA-vtUy-RjQ3Am8+R1KjyWq=JRzd1TBU=BnPi68KGL0x2FCofw@mail.gmail.com>
	<547D891D.7010809@oracle.com> <547DCCFB.3050209@gmail.com>
	<54854475.20800@oracle.com>
	<CAA-vtUxOcJm88nVo+1jHS7FxkE7Q7nsvkmvhC3dxiKuquGmSPQ@mail.gmail.com>
	<54868B02.1070408@oracle.com>
	<CAA-vtUxHLs5kTT1bxqHd92xmenWZ-WmnhiZGMmGT9qDMuzvd0w@mail.gmail.com>
	<5486B952.4070708@oracle.com>
	<CAA-vtUyRtwD+08BjZSZY_q5uHGnb8kmW7AZD2TSe=_0h6rgT_A@mail.gmai!	l.com>
	<5486FF9A.2050604@gma! il.com> <5487EA35.6070709@oracle.com>
	<548A1FB9.1010306@oracle.com>
	<1B708380-1C7F-41C5-BEC8-745FEBA95277@oracle.com>
Message-ID: <548E37F0.5090709@oracle.com>

On 12/12/2014 10:41 PM, Staffan Larsen wrote:
> Looks good! Sorry for going away for so long - just too many things right now.

Thanks Staffan! I've now submitted this to JPRT. Thomas is also listed 
as a reviewer as he does in fact have an openjdk username (sorry about 
that misunderstanding).

David

> Thanks,
> /Staffan
>
>> On 11 dec 2014, at 23:50, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Sorry, I've been advised I need a second reviewer with an openjdk user name and as Staffan has not come back to this thread, that means I need one more reviewer from the runtime team please. And please check the email trail on this as it is quite long and I really don't want to revisit covered ground. :) Thanks.
>>
>> David
>>
>> On 10/12/2014 4:37 PM, David Holmes wrote:
>>> Hi Yasumasa,
>>>
>>> On 9/12/2014 11:56 PM, Yasumasa Suenaga wrote:
>>>> David, Thomas,
>>>>
>>>> Thank you so much!
>>>> I wait 2nd reviewer.
>>>
>>> I'm a Reviewer and I think Thomas counts as a reviewer. Plus Staffan had
>>> a look too. So I think this is good to go - though I'll give it till my
>>> morning before finalizing it.
>>>
>>>> BTW, I'm not a committer.
>>>> So I'm also waiting a sponsor :-)
>>>
>>> I will sponsor if you can prepare the changeset.
>>>
>>> Thanks,
>>> David
>>>
>>>>> I'm okay with these changes. Just a minor style nit (no need for
>>>>> updated webrev) can you remove the blank lines in os_linux.cpp:
>>>>>
>>>>> 6011       }
>>>>> 6012
>>>>> 6013     }
>>>>> 6014
>>>>> 6015   }
>>>>>
>>>>> 6057       }
>>>>> 6058
>>>>> 6059     }
>>>>> 6060
>>>>> 6061   }
>>>>>
>>>>> If anyone has any objections please raise them asap.
>>>>
>>>> I will upload new webrev which is fix them after reviewing.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> (2014/12/09 21:06), Thomas St?fe wrote:
>>>>> Yes, Sure :-) @Yasumasa : thank you for this patch!
>>>>>
>>>>> Kind regards, Thomas
>>>>>
>>>>> On Dec 9, 2014 9:56 AM, "David Holmes" <david.holmes at oracle.com
>>>>> <mailto:david.holmes at oracle.com>> wrote:
>>>>>
>>>>>     Hi Thomas,
>>>>>
>>>>>     So can we take this as-is for now and file a RFE to address your
>>>>> concerns?
>>>>>
>>>>>     Anybody else object to that?
>>>>>
>>>>>     Thanks,
>>>>>     David
>>>>>
>>>>>     On 9/12/2014 6:09 PM, Thomas St?fe wrote:
>>>>>
>>>>>         Hi David,
>>>>>
>>>>>         On Tue, Dec 9, 2014 at 6:39 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 Thomas,
>>>>>
>>>>>              On 8/12/2014 8:27 PM, Thomas St?fe wrote:
>>>>>
>>>>>                  Hi,
>>>>>
>>>>>                  I do not really like the handling of the leading pipe
>>>>> symbol:
>>>>>
>>>>>
>>>>>              To be fair to Yasumasa this aspect of the fix has been
>>>>> the same
>>>>>              since Oct 15:
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~____ysuenaga/JDK-8059586/webrev.____02/
>>>>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/>
>>>>>
>>>>> <http://cr.openjdk.java.net/~__ysuenaga/JDK-8059586/webrev.__02/
>>>>> <http://cr.openjdk.java.net/~ysuenaga/JDK-8059586/webrev.02/>>
>>>>>
>>>>>              and was not flagged.
>>>>>
>>>>>
>>>>>         You are right, I did not read those mails close enough.
>>>>>
>>>>>
>>>>>
>>>>>                  So, we read the core_pattern, and if the pipe symbol
>>>>> is detected, we
>>>>>                  write the core pattern minus the pipe symbol but plus
>>>>> a leading
>>>>>                  quote to
>>>>>                  the output; the leading quote then serves as a info
>>>>> to the layer
>>>>>                  above
>>>>>                  in os_posix.cpp to treat this case specially. This
>>>>> means the logic
>>>>>                  spills out of the platform dependend os_linux.cpp to
>>>>> shared code and
>>>>>                  this is also difficult to read.
>>>>>
>>>>>                  This comes from the fact that "get_core_path()"
>>>>> assumes the core
>>>>>                  file is
>>>>>                  written to the file system. I think it just does not
>>>>> fit
>>>>>                  anymore, better
>>>>>                  would be to replace it with something like
>>>>>                  "os::print_core_file_location(____outputStream* os)",
>>>>> and the OS
>>>>>                  handles
>>>>>                  both core path retrieval and the printing. Because
>>>>> then the
>>>>>                  shared code
>>>>>                  does not need to know whether core file gets printed
>>>>>                  traditionally or
>>>>>                  piped to a executable or whatever.
>>>>>
>>>>>
>>>>>              This sounds like a refactoring that I suggested would be
>>>>> too disruptive.
>>>>>
>>>>>
>>>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015547.html
>>>>>
>>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html>
>>>>>
>>>>>
>>>>>
>>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015547.html
>>>>>
>>>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015547.html>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015557.html
>>>>>
>>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html>
>>>>>
>>>>>
>>>>>
>>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015557.html
>>>>>
>>>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015557.html>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://mail.openjdk.java.net/____pipermail/hotspot-dev/2014-____October/015573.html
>>>>>
>>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html>
>>>>>
>>>>>
>>>>>
>>>>> <http://mail.openjdk.java.net/__pipermail/hotspot-dev/2014-__October/015573.html
>>>>>
>>>>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015573.html>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>         I do not think that this would be such a big a change, but it
>>>>> also could
>>>>>         be done with another patch.
>>>>>
>>>>>         Apart from my reservations I stated above the code looks fine
>>>>> and is
>>>>>         definitly an improvement (just last week I was helplessly
>>>>> looking for a
>>>>>         core on a machine where core_pattern turned out to be a
>>>>> redirection to
>>>>>         another program).
>>>>>
>>>>>         Kind Regards, Thomas
>>>>>
>>>>>
>>>>>              David
>>>>>
>

From alexyursha at gmail.com  Mon Dec 15 06:42:23 2014
From: alexyursha at gmail.com (Alex Yursha)
Date: Mon, 15 Dec 2014 09:42:23 +0300
Subject: What is the primary development platform for OpenJDK HotSpot JVM?
In-Reply-To: <548E1507.6070407@oracle.com>
References: <14179A91-A2C3-493A-AD28-7947AB4AC3BB@gmail.com>
	<548E1507.6070407@oracle.com>
Message-ID: <56C25948-5B8D-413F-B767-91CC0FE921F1@gmail.com>

Sorry for ambiguity. My question was about the current state of affairs.

So does every HotSpot developer assumed to be an expert in all supported platforms or are there experts in specific platforms who assist in porting?

I also wonder if there is a platform which is used much more often for feature prototyping or is the work distributed almost equally between Solaris, Linux and Windows?

Thanks

> On Dec 15, 2014, at 1:53, David Holmes <david.holmes at oracle.com> wrote:
> 
>> On 15/12/2014 6:47 AM, Alex Yursha wrote:
>> Many projects are firstly developed for one target platform and only afterwords ported to other platforms. I wonder if there exists such first target platform for HotSpot JVM or is it developed in parallel for different platforms?
> 
> Are you talking historically ie what was the first platform that hotspot ran on? (I think it was Windows but not 100% sure). Or do you mean currently are new features developed on one platform and then ported to the others? For this latter question typically new features are prototyped on the platform most accessible to the developer doing the work, but quickly ported to the other platforms - often only becoming visible to others once all platforms are supported.
> 
> David
> 

From dmitry.samersoff at oracle.com  Mon Dec 15 09:12:09 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 15 Dec 2014 12:12:09 +0300
Subject: What is the primary development platform for OpenJDK HotSpot JVM?
In-Reply-To: <56C25948-5B8D-413F-B767-91CC0FE921F1@gmail.com>
References: <14179A91-A2C3-493A-AD28-7947AB4AC3BB@gmail.com>	<548E1507.6070407@oracle.com>
	<56C25948-5B8D-413F-B767-91CC0FE921F1@gmail.com>
Message-ID: <548EA5E9.5000508@oracle.com>

Alex,

Hotspot code is (and have to be) portable so regardless of platform you
start from you end up coding and testing on all supported platforms.

Every developers has it's own preferences about theirs primary
development platform. Personally I prefer Linux because I'm comfortable
with linux toolchain, but many developers use other platforms (Windows,
OS X, Solaris).

-Dmitry



On 2014-12-15 09:42, Alex Yursha wrote:
> Sorry for ambiguity. My question was about the current state of affairs.
> 
> So does every HotSpot developer assumed to be an expert in all supported platforms or are there experts in specific platforms who assist in porting?
> 
> I also wonder if there is a platform which is used much more often for feature prototyping or is the work distributed almost equally between Solaris, Linux and Windows?
> 
> Thanks
> 
>> On Dec 15, 2014, at 1:53, David Holmes <david.holmes at oracle.com> wrote:
>>
>>> On 15/12/2014 6:47 AM, Alex Yursha wrote:
>>> Many projects are firstly developed for one target platform and only afterwords ported to other platforms. I wonder if there exists such first target platform for HotSpot JVM or is it developed in parallel for different platforms?
>>
>> Are you talking historically ie what was the first platform that hotspot ran on? (I think it was Windows but not 100% sure). Or do you mean currently are new features developed on one platform and then ported to the others? For this latter question typically new features are prototyped on the platform most accessible to the developer doing the work, but quickly ported to the other platforms - often only becoming visible to others once all platforms are supported.
>>
>> David
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From erik.helin at oracle.com  Mon Dec 15 14:36:49 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 15 Dec 2014 15:36:49 +0100
Subject: RFR: 8066875: VirtualSpace does not use large pages
In-Reply-To: <548AC362.8010800@oracle.com>
References: <54874F17.7070303@oracle.com> <548814C1.8010905@oracle.com>
	<548AC362.8010800@oracle.com>
Message-ID: <20141215143649.GB24542@ehelin.jrpg.bea.com>

On 2014-12-12, Albert Noll wrote:
> Hi Erik,
> 
> thanks a lot for taking care of this. I have one minor comment (not a
> reviewer):
> 
> 1418 size_t os::largest_page_size_less_than(size_t sz) {
> 1419   if (UseLargePages) {
> 1420     // The page sizes are sorted descendingly.
> 1421     for (size_t i = 0; _page_sizes[i] != 0; ++i) {
> 1422       if (_page_sizes[i] <= sz) {
> 1423         return _page_sizes[i];
> 1424       }
> 1425     }
> 1426   }
> 1427   return vm_page_size();
> 1428 }
> 
> The function name suggests that the function returns a page size that is
> *less* than the value in the argument (sz).
> However, in line 1422 you check for '<=' . I think you should either fix the
> name of the function or the check in line 1422.

Yeah, I wasn't too fond of that name either. I discussed some potential
names with the guys in the office and ended up with:
- os::page_size_for_region_aligned
- os::page_size_for_region_unaligned

os::page_size_for_region_aligned and os::page_size_for_region_unaligned
takes the same number of parameters, a region size and minimum number of
pages. The difference is that page_size_for_region_aligned guarantees
that returned page size divides the given region size, whereas
page_size_for_region_unaligned does not guarantee this.

These names were chosen because a call to page_size_for_region_unaligned
indicates that the surrounding code must handle any alignment on its
own.

Webrevs:
- incremental: http://cr.openjdk.java.net/~ehelin/8066875/webrev.00-01/
- full: http://cr.openjdk.java.net/~ehelin/8066875/webrev.01/

Testing:
- JPRT
- Verified that the code cache now uses large pages even if
  ReservedCodeCacheSize is 241 MB (see bug for more details).
- Added new internal vm tests (also run on SPARC machine with large
  pages)
- Run hotspot jtreg tests on SPARC machine with large pages

Thanks,
Erik

> Best,
> Albert
> 
> 
> On 12/10/2014 10:39 AM, Tobias Hartmann wrote:
> >Hi Erik,
> >
> >looks good (not a reviewer).
> >
> >Thanks,
> >Tobias
> >
> >On 09.12.2014 20:35, Erik Helin wrote:
> >>Hi all,
> >>
> >>the fix for JDK-8049864 [0] made os::page_size_for_region slightly more strict
> >>since the function now demands that the given region_size is size aligned with
> >>respect to the chosen page_size. The reason for doing this was that
> >>os::page_size_for_region was used in two ways:
> >>1. Give me a suitable page size for this amount of memory
> >>2. Give me the largest page size for this amount of memory
> >>The fix for JDK-8049864 fixed os::page_size_for_region for the "suitable page
> >>size" scenario, but is too strict for the "largest page size" scenario. This
> >>caused a regression in VirtualSpace::initialize, which only needs the largest
> >>possible page size, since VirtualSpace::initialize_with_granularity takes care
> >>of any alignment issues.
> >>
> >>This patch adds the function os::largest_page_size_less_than and updates
> >>VirtualSpace::initialize to use this new function instead of
> >>os::page_size_for_region.
> >>
> >>Webrev:
> >>http://cr.openjdk.java.net/~ehelin/8066875/webrev.00/
> >>
> >>Bug:
> >>https://bugs.openjdk.java.net/browse/JDK-8066875
> >>
> >>Testing:
> >>- JPRT
> >>- Verified that the code cache now uses large pages even if
> >>   ReservedCodeCacheSize is 241 MB (see bug for more details).
> >>- Added new internal vm tests (also run on SPARC machine with large
> >>   pages)
> >>
> >>Thanks,
> >>Erik
> >>
> >>[0]: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b326a3e8dcab
> 

From sgehwolf at redhat.com  Mon Dec 15 15:09:12 2014
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 15 Dec 2014 16:09:12 +0100
Subject: RFR(S) 8067331: Zero: Atomic::xchg and Atomic::xchg_ptr need full
	memory barrier
Message-ID: <1418656152.3297.44.camel@localhost.localdomain>

Hi,

Could someone please review and sponsor the following change?

bug: https://bugs.openjdk.java.net/browse/JDK-8067331
webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067331/webrev.02/

The issue is that all atomic operations are expected to be full memory
barriers, but two implementations of the Zero variant JVM - Atomic::xchg
and Atomic::xchg_ptr - use GCC's built-in __sync_lock_test_and_set which
is an acquire barrier only. The fix adds full memory barriers manually
for those.

Thoughts?

Cheers,
Severin


From erik.helin at oracle.com  Mon Dec 15 17:18:44 2014
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 15 Dec 2014 18:18:44 +0100
Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
Message-ID: <20141215171844.GE24542@ehelin.jrpg.bea.com>

Hi all,

this small patch renames the test group hotspot_all in
hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
I also synced the new test group hotspot_jprt with the top-level
make/jprt.properties file, so that hotspot_jprt includes as many of the
JTReg tests we run in JPRT as possible.

I also added a new test group hotspot_all that actually is *all* the tests
under hotspot/test.

Please note that this will not affects which tests are being run in
JPRT, that is still decided by the top-level file make/jprt.properties.

Webrev:
http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/

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

Testing:
- Run `make test TEST=hotspot_all` on Linux x86-64
- Run `make test TEST=hotspot_jprt` on Linux x86-64

Thanks,
Erik

From christian.tornqvist at oracle.com  Mon Dec 15 18:32:03 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Mon, 15 Dec 2014 13:32:03 -0500
Subject: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
In-Reply-To: <20141215171844.GE24542@ehelin.jrpg.bea.com>
References: <20141215171844.GE24542@ehelin.jrpg.bea.com>
Message-ID: <04b101d01895$6c917490$45b45db0$@oracle.com>

Hi Erik,

This looks good.

Thanks,
Christian

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
Erik Helin
Sent: Monday, December 15, 2014 12:19 PM
To: hotspot-dev at openjdk.java.net
Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups

Hi all,

this small patch renames the test group hotspot_all in
hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
I also synced the new test group hotspot_jprt with the top-level
make/jprt.properties file, so that hotspot_jprt includes as many of the
JTReg tests we run in JPRT as possible.

I also added a new test group hotspot_all that actually is *all* the tests
under hotspot/test.

Please note that this will not affects which tests are being run in JPRT,
that is still decided by the top-level file make/jprt.properties.

Webrev:
http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/

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

Testing:
- Run `make test TEST=hotspot_all` on Linux x86-64
- Run `make test TEST=hotspot_jprt` on Linux x86-64

Thanks,
Erik


From dmitrij.pochepko at oracle.com  Mon Dec 15 18:19:42 2014
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Mon, 15 Dec 2014 21:19:42 +0300
Subject: RFR: 8065279 - Remove testlibrary_tests from compact profile in jtreg
Message-ID: <548F263E.7030206@oracle.com>

Hi all,

please review fix for 8065279 - Remove testlibrary_tests from compact 
profile in jtreg

a small fix just removing one line.

webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8065279/webrev.00/

Thanks,
Dmitrij

From vladimir.kozlov at oracle.com  Mon Dec 15 22:18:14 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 15 Dec 2014 14:18:14 -0800
Subject: RFR: 8065279 - Remove testlibrary_tests from compact profile
	in jtreg
In-Reply-To: <548F263E.7030206@oracle.com>
References: <548F263E.7030206@oracle.com>
Message-ID: <548F5E26.808@oracle.com>

Okay.

Thanks,
Vladimir

On 12/15/14 10:19 AM, Dmitrij Pochepko wrote:
> Hi all,
>
> please review fix for 8065279 - Remove testlibrary_tests from compact
> profile in jtreg
>
> a small fix just removing one line.
>
> webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8065279/webrev.00/
>
> Thanks,
> Dmitrij

From igor.ignatyev at oracle.com  Mon Dec 15 22:22:34 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 16 Dec 2014 01:22:34 +0300
Subject: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
In-Reply-To: <04b101d01895$6c917490$45b45db0$@oracle.com>
References: <20141215171844.GE24542@ehelin.jrpg.bea.com>
	<04b101d01895$6c917490$45b45db0$@oracle.com>
Message-ID: <548F5F2A.1030200@oracle.com>

Erik,

looks good to me.
--
Thanks
Igor

On 12/15/2014 09:32 PM, Christian Tornqvist wrote:
> Hi Erik,
>
> This looks good.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
> Erik Helin
> Sent: Monday, December 15, 2014 12:19 PM
> To: hotspot-dev at openjdk.java.net
> Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
>
> Hi all,
>
> this small patch renames the test group hotspot_all in
> hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
> I also synced the new test group hotspot_jprt with the top-level
> make/jprt.properties file, so that hotspot_jprt includes as many of the
> JTReg tests we run in JPRT as possible.
>
> I also added a new test group hotspot_all that actually is *all* the tests
> under hotspot/test.
>
> Please note that this will not affects which tests are being run in JPRT,
> that is still decided by the top-level file make/jprt.properties.
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8067452
>
> Testing:
> - Run `make test TEST=hotspot_all` on Linux x86-64
> - Run `make test TEST=hotspot_jprt` on Linux x86-64
>
> Thanks,
> Erik
>

From david.holmes at oracle.com  Tue Dec 16 05:39:36 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Dec 2014 15:39:36 +1000
Subject: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
In-Reply-To: <04b101d01895$6c917490$45b45db0$@oracle.com>
References: <20141215171844.GE24542@ehelin.jrpg.bea.com>
	<04b101d01895$6c917490$45b45db0$@oracle.com>
Message-ID: <548FC598.9070603@oracle.com>

Is this a stepping stone to having JPRT execute hotspot_jprt?

You don't really need a group to represent "all" as that is what you get 
if you don't specify any group or a specific test. But it is harmless I 
suppose.

Thanks,
David

On 16/12/2014 4:32 AM, Christian Tornqvist wrote:
> Hi Erik,
>
> This looks good.
>
> Thanks,
> Christian
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
> Erik Helin
> Sent: Monday, December 15, 2014 12:19 PM
> To: hotspot-dev at openjdk.java.net
> Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
>
> Hi all,
>
> this small patch renames the test group hotspot_all in
> hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
> I also synced the new test group hotspot_jprt with the top-level
> make/jprt.properties file, so that hotspot_jprt includes as many of the
> JTReg tests we run in JPRT as possible.
>
> I also added a new test group hotspot_all that actually is *all* the tests
> under hotspot/test.
>
> Please note that this will not affects which tests are being run in JPRT,
> that is still decided by the top-level file make/jprt.properties.
>
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8067452
>
> Testing:
> - Run `make test TEST=hotspot_all` on Linux x86-64
> - Run `make test TEST=hotspot_jprt` on Linux x86-64
>
> Thanks,
> Erik
>

From david.holmes at oracle.com  Tue Dec 16 05:49:52 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Dec 2014 15:49:52 +1000
Subject: RFR: 8065279 - Remove testlibrary_tests from compact profile
	in jtreg
In-Reply-To: <548F263E.7030206@oracle.com>
References: <548F263E.7030206@oracle.com>
Message-ID: <548FC800.1020306@oracle.com>

On 16/12/2014 4:19 AM, Dmitrij Pochepko wrote:
> Hi all,
>
> please review fix for 8065279 - Remove testlibrary_tests from compact
> profile in jtreg
>
> a small fix just removing one line.
>
> webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8065279/webrev.00/

So these tests are never expected to be run with the main set of tests?

David

> Thanks,
> Dmitrij

From erik.helin at oracle.com  Tue Dec 16 07:20:07 2014
From: erik.helin at oracle.com ('Erik Helin')
Date: Tue, 16 Dec 2014 08:20:07 +0100
Subject: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
In-Reply-To: <548FC598.9070603@oracle.com>
References: <20141215171844.GE24542@ehelin.jrpg.bea.com>
	<04b101d01895$6c917490$45b45db0$@oracle.com>
	<548FC598.9070603@oracle.com>
Message-ID: <20141216072007.GF24542@ehelin.jrpg.bea.com>

On 2014-12-16, David Holmes wrote:
> Is this a stepping stone to having JPRT execute hotspot_jprt?

Unfortunately no, we need the parallelism we gain from specifying the
targets individually in the top-level make/jprt.properties file.

> You don't really need a group to represent "all" as that is what you get if
> you don't specify any group or a specific test. But it is harmless I
> suppose.

The group hotspot_all is convenient when running the JTReg tests from
the top-level Makefile. If you run configure with
"--with-jtreg=/path/to/jtreg", you can now run

  $ make test TEST=hotspot_all

at the top-level to run all JTReg tests in the hotspot/test folder (and
subfolders).

Thanks,
ERik

> Thanks,
> David
> 
> On 16/12/2014 4:32 AM, Christian Tornqvist wrote:
> >Hi Erik,
> >
> >This looks good.
> >
> >Thanks,
> >Christian
> >
> >-----Original Message-----
> >From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
> >Erik Helin
> >Sent: Monday, December 15, 2014 12:19 PM
> >To: hotspot-dev at openjdk.java.net
> >Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
> >
> >Hi all,
> >
> >this small patch renames the test group hotspot_all in
> >hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
> >I also synced the new test group hotspot_jprt with the top-level
> >make/jprt.properties file, so that hotspot_jprt includes as many of the
> >JTReg tests we run in JPRT as possible.
> >
> >I also added a new test group hotspot_all that actually is *all* the tests
> >under hotspot/test.
> >
> >Please note that this will not affects which tests are being run in JPRT,
> >that is still decided by the top-level file make/jprt.properties.
> >
> >Webrev:
> >http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/
> >
> >Bug:
> >https://bugs.openjdk.java.net/browse/JDK-8067452
> >
> >Testing:
> >- Run `make test TEST=hotspot_all` on Linux x86-64
> >- Run `make test TEST=hotspot_jprt` on Linux x86-64
> >
> >Thanks,
> >Erik
> >

From erik.helin at oracle.com  Tue Dec 16 07:20:23 2014
From: erik.helin at oracle.com ('Erik Helin')
Date: Tue, 16 Dec 2014 08:20:23 +0100
Subject: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
In-Reply-To: <04b101d01895$6c917490$45b45db0$@oracle.com>
References: <20141215171844.GE24542@ehelin.jrpg.bea.com>
	<04b101d01895$6c917490$45b45db0$@oracle.com>
Message-ID: <20141216072023.GG24542@ehelin.jrpg.bea.com>

On 2014-12-15, Christian Tornqvist wrote:
> Hi Erik,
> 
> This looks good.

Thanks!
Erik

> Thanks,
> Christian
> 
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
> Erik Helin
> Sent: Monday, December 15, 2014 12:19 PM
> To: hotspot-dev at openjdk.java.net
> Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
> 
> Hi all,
> 
> this small patch renames the test group hotspot_all in
> hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
> I also synced the new test group hotspot_jprt with the top-level
> make/jprt.properties file, so that hotspot_jprt includes as many of the
> JTReg tests we run in JPRT as possible.
> 
> I also added a new test group hotspot_all that actually is *all* the tests
> under hotspot/test.
> 
> Please note that this will not affects which tests are being run in JPRT,
> that is still decided by the top-level file make/jprt.properties.
> 
> Webrev:
> http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8067452
> 
> Testing:
> - Run `make test TEST=hotspot_all` on Linux x86-64
> - Run `make test TEST=hotspot_jprt` on Linux x86-64
> 
> Thanks,
> Erik
> 

From erik.helin at oracle.com  Tue Dec 16 07:20:35 2014
From: erik.helin at oracle.com ('Erik Helin')
Date: Tue, 16 Dec 2014 08:20:35 +0100
Subject: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
In-Reply-To: <548F5F2A.1030200@oracle.com>
References: <20141215171844.GE24542@ehelin.jrpg.bea.com>
	<04b101d01895$6c917490$45b45db0$@oracle.com>
	<548F5F2A.1030200@oracle.com>
Message-ID: <20141216072035.GH24542@ehelin.jrpg.bea.com>

On 2014-12-16, Igor Ignatyev wrote:
> Erik,
> 
> looks good to me.

Thanks!
Erik

> --
> Thanks
> Igor
> 
> On 12/15/2014 09:32 PM, Christian Tornqvist wrote:
> >Hi Erik,
> >
> >This looks good.
> >
> >Thanks,
> >Christian
> >
> >-----Original Message-----
> >From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
> >Erik Helin
> >Sent: Monday, December 15, 2014 12:19 PM
> >To: hotspot-dev at openjdk.java.net
> >Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
> >
> >Hi all,
> >
> >this small patch renames the test group hotspot_all in
> >hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
> >I also synced the new test group hotspot_jprt with the top-level
> >make/jprt.properties file, so that hotspot_jprt includes as many of the
> >JTReg tests we run in JPRT as possible.
> >
> >I also added a new test group hotspot_all that actually is *all* the tests
> >under hotspot/test.
> >
> >Please note that this will not affects which tests are being run in JPRT,
> >that is still decided by the top-level file make/jprt.properties.
> >
> >Webrev:
> >http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/
> >
> >Bug:
> >https://bugs.openjdk.java.net/browse/JDK-8067452
> >
> >Testing:
> >- Run `make test TEST=hotspot_all` on Linux x86-64
> >- Run `make test TEST=hotspot_jprt` on Linux x86-64
> >
> >Thanks,
> >Erik
> >

From david.holmes at oracle.com  Tue Dec 16 08:04:06 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Dec 2014 18:04:06 +1000
Subject: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
In-Reply-To: <20141216072007.GF24542@ehelin.jrpg.bea.com>
References: <20141215171844.GE24542@ehelin.jrpg.bea.com>
	<04b101d01895$6c917490$45b45db0$@oracle.com>
	<548FC598.9070603@oracle.com>
	<20141216072007.GF24542@ehelin.jrpg.bea.com>
Message-ID: <548FE776.9060107@oracle.com>

On 16/12/2014 5:20 PM, 'Erik Helin' wrote:
> On 2014-12-16, David Holmes wrote:
>> Is this a stepping stone to having JPRT execute hotspot_jprt?
>
> Unfortunately no, we need the parallelism we gain from specifying the
> targets individually in the top-level make/jprt.properties file.

Ah right - so this is only to be able to run stand-alone what JPRT would 
run?

>> You don't really need a group to represent "all" as that is what you get if
>> you don't specify any group or a specific test. But it is harmless I
>> suppose.
>
> The group hotspot_all is convenient when running the JTReg tests from
> the top-level Makefile. If you run configure with
> "--with-jtreg=/path/to/jtreg", you can now run
>
>    $ make test TEST=hotspot_all
>
> at the top-level to run all JTReg tests in the hotspot/test folder (and
> subfolders).

Got it - it's a make target more than anything.

Thanks,
David

> Thanks,
> ERik
>
>> Thanks,
>> David
>>
>> On 16/12/2014 4:32 AM, Christian Tornqvist wrote:
>>> Hi Erik,
>>>
>>> This looks good.
>>>
>>> Thanks,
>>> Christian
>>>
>>> -----Original Message-----
>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
>>> Erik Helin
>>> Sent: Monday, December 15, 2014 12:19 PM
>>> To: hotspot-dev at openjdk.java.net
>>> Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
>>>
>>> Hi all,
>>>
>>> this small patch renames the test group hotspot_all in
>>> hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
>>> I also synced the new test group hotspot_jprt with the top-level
>>> make/jprt.properties file, so that hotspot_jprt includes as many of the
>>> JTReg tests we run in JPRT as possible.
>>>
>>> I also added a new test group hotspot_all that actually is *all* the tests
>>> under hotspot/test.
>>>
>>> Please note that this will not affects which tests are being run in JPRT,
>>> that is still decided by the top-level file make/jprt.properties.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8067452
>>>
>>> Testing:
>>> - Run `make test TEST=hotspot_all` on Linux x86-64
>>> - Run `make test TEST=hotspot_jprt` on Linux x86-64
>>>
>>> Thanks,
>>> Erik
>>>

From erik.helin at oracle.com  Tue Dec 16 09:26:52 2014
From: erik.helin at oracle.com ('Erik Helin')
Date: Tue, 16 Dec 2014 10:26:52 +0100
Subject: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
In-Reply-To: <548FE776.9060107@oracle.com>
References: <20141215171844.GE24542@ehelin.jrpg.bea.com>
	<04b101d01895$6c917490$45b45db0$@oracle.com>
	<548FC598.9070603@oracle.com>
	<20141216072007.GF24542@ehelin.jrpg.bea.com>
	<548FE776.9060107@oracle.com>
Message-ID: <20141216092652.GB3493@ehelin.jrpg.bea.com>

On 2014-12-16, David Holmes wrote:
> On 16/12/2014 5:20 PM, 'Erik Helin' wrote:
> >On 2014-12-16, David Holmes wrote:
> >>Is this a stepping stone to having JPRT execute hotspot_jprt?
> >
> >Unfortunately no, we need the parallelism we gain from specifying the
> >targets individually in the top-level make/jprt.properties file.
> 
> Ah right - so this is only to be able to run stand-alone what JPRT would
> run?

Yes, that is correct. The goal is to make it easy for developers to run
as much as possible of what JPRT runs (on their own machines).

Thanks,
Erik

> >>You don't really need a group to represent "all" as that is what you get if
> >>you don't specify any group or a specific test. But it is harmless I
> >>suppose.
> >
> >The group hotspot_all is convenient when running the JTReg tests from
> >the top-level Makefile. If you run configure with
> >"--with-jtreg=/path/to/jtreg", you can now run
> >
> >   $ make test TEST=hotspot_all
> >
> >at the top-level to run all JTReg tests in the hotspot/test folder (and
> >subfolders).
> 
> Got it - it's a make target more than anything.
> 
> Thanks,
> David
> 
> >Thanks,
> >ERik
> >
> >>Thanks,
> >>David
> >>
> >>On 16/12/2014 4:32 AM, Christian Tornqvist wrote:
> >>>Hi Erik,
> >>>
> >>>This looks good.
> >>>
> >>>Thanks,
> >>>Christian
> >>>
> >>>-----Original Message-----
> >>>From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
> >>>Erik Helin
> >>>Sent: Monday, December 15, 2014 12:19 PM
> >>>To: hotspot-dev at openjdk.java.net
> >>>Subject: RFR: 8067452: Rename hotspot_all in hotspot/test/TEST.groups
> >>>
> >>>Hi all,
> >>>
> >>>this small patch renames the test group hotspot_all in
> >>>hotspot/test/TEST.groups to hotspot_jprt to better reflect its purpose.
> >>>I also synced the new test group hotspot_jprt with the top-level
> >>>make/jprt.properties file, so that hotspot_jprt includes as many of the
> >>>JTReg tests we run in JPRT as possible.
> >>>
> >>>I also added a new test group hotspot_all that actually is *all* the tests
> >>>under hotspot/test.
> >>>
> >>>Please note that this will not affects which tests are being run in JPRT,
> >>>that is still decided by the top-level file make/jprt.properties.
> >>>
> >>>Webrev:
> >>>http://cr.openjdk.java.net/~ehelin/8067452/webrev.00/
> >>>
> >>>Bug:
> >>>https://bugs.openjdk.java.net/browse/JDK-8067452
> >>>
> >>>Testing:
> >>>- Run `make test TEST=hotspot_all` on Linux x86-64
> >>>- Run `make test TEST=hotspot_jprt` on Linux x86-64
> >>>
> >>>Thanks,
> >>>Erik
> >>>

From tatiana.pivovarova at oracle.com  Tue Dec 16 14:41:51 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Tue, 16 Dec 2014 17:41:51 +0300
Subject: RFR(S): 8067173: remove Utils::fileAsList
Message-ID: <549044AF.5000503@oracle.com>

Hi all,

please review this small patch

bugid: https://bugs.openjdk.java.net/browse/JDK-8067173
webrevs:
- 
http://cr.openjdk.java.net/~iignatyev/tpivovarova/8067173/hotspot/webrev.00/
- http://cr.openjdk.java.net/~iignatyev/tpivovarova/8067173/jdk/webrev.00/

Problem:
Utils::fileAsList is almost a copy of Files::readAllLines

Solution:
Replace Utils::fileAsList by Files::readAllLines

Testing: jprt

Thanks,
Tatiana

From goetz.lindenmaier at sap.com  Tue Dec 16 16:24:56 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 16 Dec 2014 16:24:56 +0000
Subject: [8u]: backport of 8065915: Fix includes after 8058148: MaxNodeLimit
	and LiveNodeCountInliningCutoff
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF427F3@DEWDFEMB12A.global.corp.sap>

Hi,

I would like to downport this fix to 8u.  It applies without any problems.

http://cr.openjdk.java.net/~goetz/webrevs/8065915-inclFix/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8065915
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2edb06d66129

I please need a sponsor for this.

Thanks and best regards,
Goetz.


From vladimir.kozlov at oracle.com  Tue Dec 16 16:45:24 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Dec 2014 08:45:24 -0800
Subject: RFR(S): 8067173: remove Utils::fileAsList
In-Reply-To: <549044AF.5000503@oracle.com>
References: <549044AF.5000503@oracle.com>
Message-ID: <549061A4.7020800@oracle.com>

Good.

Thanks,
Vladimir

On 12/16/14 6:41 AM, Tatiana Pivovarova wrote:
> Hi all,
>
> please review this small patch
>
> bugid: https://bugs.openjdk.java.net/browse/JDK-8067173
> webrevs:
> - http://cr.openjdk.java.net/~iignatyev/tpivovarova/8067173/hotspot/webrev.00/
> - http://cr.openjdk.java.net/~iignatyev/tpivovarova/8067173/jdk/webrev.00/
>
> Problem:
> Utils::fileAsList is almost a copy of Files::readAllLines
>
> Solution:
> Replace Utils::fileAsList by Files::readAllLines
>
> Testing: jprt
>
> Thanks,
> Tatiana

From tatiana.pivovarova at oracle.com  Tue Dec 16 17:28:47 2014
From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova)
Date: Tue, 16 Dec 2014 20:28:47 +0300
Subject: RFR(S): 8067173: remove Utils::fileAsList
In-Reply-To: <549061A4.7020800@oracle.com>
References: <549044AF.5000503@oracle.com> <549061A4.7020800@oracle.com>
Message-ID: <54906BCF.4030900@oracle.com>

Hi Vladimir,

Thanks for the review!

Tatiana

On 12/16/2014 07:45 PM, Vladimir Kozlov wrote:
> Good.
>
> Thanks,
> Vladimir
>
> On 12/16/14 6:41 AM, Tatiana Pivovarova wrote:
>> Hi all,
>>
>> please review this small patch
>>
>> bugid: https://bugs.openjdk.java.net/browse/JDK-8067173
>> webrevs:
>> - 
>> http://cr.openjdk.java.net/~iignatyev/tpivovarova/8067173/hotspot/webrev.00/
>> - 
>> http://cr.openjdk.java.net/~iignatyev/tpivovarova/8067173/jdk/webrev.00/
>>
>> Problem:
>> Utils::fileAsList is almost a copy of Files::readAllLines
>>
>> Solution:
>> Replace Utils::fileAsList by Files::readAllLines
>>
>> Testing: jprt
>>
>> Thanks,
>> Tatiana


From coleen.phillimore at oracle.com  Tue Dec 16 23:59:44 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 16 Dec 2014 18:59:44 -0500
Subject: RFR:8064319:Enable -XX:+TraceExceptions in product builds.
In-Reply-To: <548B4E42.6070207@oracle.com>
References: <548B4E42.6070207@oracle.com>
Message-ID: <5490C770.4000104@oracle.com>


Max, This change looks good to me.  Thank you for filing the 
compatibility request, adding a release note and fixing the test.

Coleen

On 12/12/14, 3:21 PM, Max Ockner wrote:
> Hello all,
> Please review my small fix for the TraceExceptions command line argument.
>
> Bug:   https://bugs.openjdk.java.net/browse/JDK-8064319
> Webrev:   http://cr.openjdk.java.net/~coleenp/8064319/
> Summary:    -XX:+TraceExceptions was previously enabled only in 
> development/debug versions, and not in product builds. Now it is 
> enabled in product builds as well.
> Tested with JPRT and updated TraceExceptions.java test.
>
> Thanks,
> Max Ockner


From dmitrij.pochepko at oracle.com  Tue Dec 16 13:37:10 2014
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Tue, 16 Dec 2014 16:37:10 +0300
Subject: RFR: 8065279 - Remove testlibrary_tests from compact profile
	in jtreg
In-Reply-To: <548FC800.1020306@oracle.com>
References: <548F263E.7030206@oracle.com> <548FC800.1020306@oracle.com>
Message-ID: <54903586.3020905@oracle.com>

Yes.
quoting reporter: "They are intended for testing the functionality in 
testlibrary and should not be used to testing the product - there is no 
value here"

Thanks,
Dmitrij
> On 16/12/2014 4:19 AM, Dmitrij Pochepko wrote:
>> Hi all,
>>
>> please review fix for 8065279 - Remove testlibrary_tests from compact
>> profile in jtreg
>>
>> a small fix just removing one line.
>>
>> webrev: 
>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8065279/webrev.00/
>
> So these tests are never expected to be run with the main set of tests?
>
> David
>
>> Thanks,
>> Dmitrij


From david.holmes at oracle.com  Wed Dec 17 02:36:13 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Dec 2014 12:36:13 +1000
Subject: RFR: 8065279 - Remove testlibrary_tests from compact profile
	in jtreg
In-Reply-To: <54903586.3020905@oracle.com>
References: <548F263E.7030206@oracle.com> <548FC800.1020306@oracle.com>
	<54903586.3020905@oracle.com>
Message-ID: <5490EC1D.4080503@oracle.com>

On 16/12/2014 11:37 PM, Dmitrij Pochepko wrote:
> Yes.
> quoting reporter: "They are intended for testing the functionality in
> testlibrary and should not be used to testing the product - there is no
> value here"

Okay. But who is responsible for running them and ensuring the 
testlibrary still works ?

David

> Thanks,
> Dmitrij
>> On 16/12/2014 4:19 AM, Dmitrij Pochepko wrote:
>>> Hi all,
>>>
>>> please review fix for 8065279 - Remove testlibrary_tests from compact
>>> profile in jtreg
>>>
>>> a small fix just removing one line.
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8065279/webrev.00/
>>
>> So these tests are never expected to be run with the main set of tests?
>>
>> David
>>
>>> Thanks,
>>> Dmitrij
>

From erik.osterlund at lnu.se  Wed Dec 17 16:38:15 2014
From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=)
Date: Wed, 17 Dec 2014 16:38:15 +0000
Subject: RFR: 8067790: Better support for native implementations of
	Atomic::cmpxchg
Message-ID: <0F0D9F35-148D-4C62-8065-7E58F5EC76D1@lnu.se>

Hi all,

Previously, jbyte Atomic::cmpxchg had one general implementation for all platforms. A macro based solution was introduced, adding specialized implementation for the x86 platforms without changing code for the ports for other architectures, making the specialization optional (from ).

However, macros are not very nice and this new fix gets rid of the macros and replaces it with a cleaner solution using inheritance and templates. The core idea is simple: split the Atomic class into three layers of inheritance.

1. AtomicBase is the base class where general operations for all platforms should go, now it contains the general implementation for jbyte cmpxchg, but in the future other similar methods are welcome too.
2. AtomicPlatform is an optional class that a platform can define, but does not have to (and hence does not break existing ports), allowing specialized variants to override the behaviour of AtomicBase. Now it contains the specialized platform dependent x86 variants of jbyte cmpxchg.
3. Atomic is the fascade of all atomics as expected. Its jbyte cmpxchg implementation simply forwards to its super class AtomicSuper which is either AtomicBase or AtomicPlatform if provided for the specific platform.

All in all, it?s based on simple inheritance with the twist that the AtomicPlatform part is optional. This is allowed using some C++ metaprogramming idioms. Concretely, a trait was implemented called SelectBaseClass that allows you to specify the desired base class, and another one to fall back to in case the desired base class was not defined (forward declaration). The super class of Atomic is hence defined as:

typedef SelectBaseClass<AtomicPlatform, AtomicBase>::type AtomicSuper;

To implement this trait, an equivalent variant of the C++11/boost is_base_of trait was implemented, called IsBaseOf to follow our naming conventions. It is very similar to the standard version but works on all of our compilers. The only difference so far between IsBaseOf and is_base_of is that IsBaseOf will return true when comparing two unions that are the same, while is_base_of will not. The reason for this is that I found no portable way of detecting unions. A bunch of dependent traits were implemented too, and it can all be found in utilities/traits/ since I like reasonably fine grained headers. All these traits are built to be reusable and perhaps we will have more uses for metaprogramming in the future where this comes in handy. The intended behaviour and contract of the traits are documented in comments.

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

In summary this allows us to get rid of the ugly macro used before and provide a better general mechanism for having generalized and specialized atomics without breaking existing ports for those platforms that do not need it. And hopefully the metaprogramming tools will come in useful in the future for perhaps similar situations.

Testing:
* All new traits have test cases using STATIC_ASSERT nailing down the intended behaviour and contract also reflected in the comments.
* The changes passed the jprt testing ok. (Thanks to Jesper for running it!)

Thanks,
/Erik

From serguei.spitsyn at oracle.com  Wed Dec 17 17:26:17 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 17 Dec 2014 09:26:17 -0800
Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution
	must support pseudo strings
In-Reply-To: <54762FC9.2010800@oracle.com>
References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com>
	<54762FC9.2010800@oracle.com>
Message-ID: <5491BCB9.10505@oracle.com>

Please, review the second round fix for:
   https://bugs.openjdk.java.net/browse/JDK-8008678

Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/


Summary:

   This fix implements a footprint saving approach suggested by Coleen.
   To be able to reconstitute a class constant pool, an intermediate 
pseudo-string map is used.
   Now, this field is accounted optionally, only if the 'cp_patches' is 
provided in the
   ClassFileParser::parseClassFile() before ConstantPool is allocated.
   This fix is not elegant, even a little bit ugly, but it is the only 
way I see so far.

   Unfortunately, this approach did not help much to make some other 
fields (eg., 'operands') optional.
   The problem is that we have to account optional fields before 
parsing, at the CP allocation time.
   It is possible to re-allocate the ConstantPool when any InvokeDynamic 
bytecode is discovered,
   but it looks too complicated.

Testing:
   - the unit test from bug report
   - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument
   - vm.mlvm.testlist, vm.quick.testlist, 
vm.parallel_class_loading.testlist (in progress)


Thanks,
Serguei


On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote:
> Coleen,
>
> Thank you for looking at this!
> I'll check how this can be improved.
> It is my concern too.
>
> Thanks,
> Serguei
>
> On 11/26/14 9:17 AM, Coleen Phillimore wrote:
>>
>> Serguei,
>> I had a quick look at this.  I was wondering if we could make the 
>> pseudo_string_map conditional in ConstantPool and not make all 
>> classes pay in footprint for this field?  The same thing probably 
>> could be done for operands too.  There are flags that you can set to 
>> conditionally add a pointer to base() in this function.
>>
>> Typical C++ would subclass ConstantPool to add 
>> InvokeDynamicConstantPool fields, but this is not typical C++ so the 
>> trick we use is like the one in ConstMethod.   I think it's worth 
>> doing in this case.
>>
>> Thanks,
>> Coleen
>>
>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>>   https://bugs.openjdk.java.net/browse/JDK-8008678
>>>
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ 
>>>
>>>
>>>
>>> Summary:
>>>    The pseudo-strings are currently not supported in reconstitution 
>>> of constant pool.
>>>
>>>    This is an explanation from John Rose about what the 
>>> pseudo-strings are:
>>>
>>>    "We still need "live" oop constants pre-linked into the constant 
>>> pool of bytecodes which
>>>     implement some method handles. We use the anonymous class 
>>> pseudo-string feature for that.
>>>     The relevant code is here:
>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
>>>
>>>     These oops are what "pseudo-strings" are.
>>>     The odd name refers to the fact that, even though they are 
>>> random oops, they appear in the constant pool
>>>     where one would expect (because of class file syntax) to find a 
>>> string."
>>>      ...
>>>     If you really wanted to reconstitute a class file for an 
>>> anonymous class, and
>>>     if that class has oop patching (pseudo-strings), you would need 
>>> either to (a) reconstitute the patches array
>>>     handed to Unsafe.defineAnonymousClass, or (b) accept whatever 
>>> odd strings were there first, as an approximation.
>>>     The "odd strings" are totally insignificant, and are typically 
>>> something like "CONSTANT_PLACEHOLDER_42"
>>>     (see java/lang/invoke/InvokerBytecodeGenerator.java)."
>>>
>>>
>>>    Reconstitution of the ConstantPool is needed for both the JVMTI 
>>> GetConstantPool() and RetransformClasses().
>>>    Finally, it goes to the ConstantPool::copy_cpool_bytes().
>>>
>>>    The problem is that a pseudo-string is a patched string that does 
>>> not have
>>>    a reference to the string symbol anymore:
>>>        unresolved_string_at(idx) == NULL
>>>
>>>    The fix is to create and fill in a map from JVM_CONSTANT_String 
>>> cp index to the JVM_CONSTANT_Utf8 cp index
>>>    to be able to restore this assotiation in the 
>>> JvmtiConstantPoolReconstituter.
>>>
>>> Testing:
>>>   Run:
>>>    - java/lang/instrument tests
>>>    - new jtreg test (see webrev) that was written by Filipp Zhinkin
>>>
>>>
>>> Thanks,
>>> Serguei
>>
>


From coleen.phillimore at oracle.com  Wed Dec 17 18:05:15 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 17 Dec 2014 13:05:15 -0500
Subject: RFR: 8067713: Move clean_weak_method_links for redefinition out of
	class unloading
Message-ID: <5491C5DB.6000004@oracle.com>

Summary: Do this work during class redefinition, only verify clean 
during class unloading in debug mode.

open webrev at http://cr.openjdk.java.net/~coleenp/8067713/
bug link https://bugs.openjdk.java.net/browse/JDK-8067713

Roland added tests for the original bugs

https://bugs.openjdk.java.net/browse/JDK-8038636
and
https://bugs.openjdk.java.net/browse/JDK-8040237

test/compiler/profiling/spectrapredefineclass/Launcher.javatest/compiler/profiling/TestSpecTrapClassUnloading.java

Ran jdk/test/java/lang/instrument tests, vm.quick.testlist, testbase vm.redefine.testlist (thanks to Serguei for creating this list) with -Xmixed,
-Xcomp and
-XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -XX:+UseTypeSpeculation -XX:TypeProfileLevel=222

Thanks,
Coleen



From alejandro.murillo at oracle.com  Wed Dec 17 19:49:14 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 17 Dec 2014 12:49:14 -0700
Subject: [8u40] IMPORTANT INFO: Please do not push any changeset to
	jdk8u/hs-dev until further notice
In-Reply-To: <548B5EC2.4060203@oracle.com>
References: <548B5EC2.4060203@oracle.com>
Message-ID: <5491DE3A.6040609@oracle.com>


On 12/12/2014 2:31 PM, Alejandro E Murillo wrote:
>
> Hotspot developers:
>
> I just took the last snapshot of jdk8u/hs-dev [1] before 8u40 enters 
> the RDP2 phase.
> that repository will become associated to 8u60 next week, after 
> 8u40-b19 is promoted.
> Until then  please refrain from pushing any changes to it. I will 
> reply this email
> when that happens
The switch has been done.  Repo [1] is now open for changes
as explained below,  approved changes for 8u40 should also be
pushed to this repo

Thanks
Alejandro
>
> Going forward,
> Hotspot changes destined for 8u40 will need to be approved by the 
> releasing team (see [2] for details).
> Once approved, they should be pushed to jdk8u/hs-dev as usual, and 
> then I will
> take all 8u40 approved changes from there to the jdk8u40 stabilization 
> repo (see [3])
> after going through PIT (if needed).
>
> thanks
>

> [1] http://hg.openjdk.java.net/jdk8u/hs-dev/
> [2] http://openjdk.java.net/projects/jdk8u/phase2/phase2-process.html
> [3] 
> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2014-December/002677.html
>

-- 
Alejandro


From vladimir.kozlov at oracle.com  Wed Dec 17 20:06:32 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Dec 2014 12:06:32 -0800
Subject: [8u]: backport of 8065915: Fix includes after 8058148:
	MaxNodeLimit and LiveNodeCountInliningCutoff
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF427F3@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF427F3@DEWDFEMB12A.global.corp.sap>
Message-ID: <5491E248.5000000@oracle.com>

Hi Goetz,

Do you want to push it into 8u40? Or you are okay with 8u60?
We need an approval for pushing into 8u40 from now on.

Thanks,
Vladimir

On 12/16/14 8:24 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I would like to downport this fix to 8u.  It applies without any problems.
>
> http://cr.openjdk.java.net/~goetz/webrevs/8065915-inclFix/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8065915
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2edb06d66129
>
> I please need a sponsor for this.
>
> Thanks and best regards,
> Goetz.
>

From dmitrij.pochepko at oracle.com  Wed Dec 17 18:45:45 2014
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Wed, 17 Dec 2014 21:45:45 +0300
Subject: RFR: 8065279 - Remove testlibrary_tests from compact profile
	in jtreg
In-Reply-To: <5490EC1D.4080503@oracle.com>
References: <548F263E.7030206@oracle.com> <548FC800.1020306@oracle.com>
	<54903586.3020905@oracle.com> <5490EC1D.4080503@oracle.com>
Message-ID: <5491CF59.4060500@oracle.com>

As far as i know, of all sqe teams, groups mechanism is used by embedded 
sqe only(most of embedded machines are very slow, so, execution time 
reduction is important  there).
SE teams runs all tests as a whole( jteg -jdk:$JAVA_HOME 
${WS}/hotspot/test/.) including testlibrary_tests

Thanks,
Dmitrij
> On 16/12/2014 11:37 PM, Dmitrij Pochepko wrote:
>> Yes.
>> quoting reporter: "They are intended for testing the functionality in
>> testlibrary and should not be used to testing the product - there is no
>> value here"
>
> Okay. But who is responsible for running them and ensuring the 
> testlibrary still works ?
>
> David
>
>> Thanks,
>> Dmitrij
>>> On 16/12/2014 4:19 AM, Dmitrij Pochepko wrote:
>>>> Hi all,
>>>>
>>>> please review fix for 8065279 - Remove testlibrary_tests from compact
>>>> profile in jtreg
>>>>
>>>> a small fix just removing one line.
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8065279/webrev.00/
>>>
>>> So these tests are never expected to be run with the main set of tests?
>>>
>>> David
>>>
>>>> Thanks,
>>>> Dmitrij
>>


From david.holmes at oracle.com  Thu Dec 18 00:53:03 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Dec 2014 10:53:03 +1000
Subject: [8u60] RFR: 8035663 Suspicious failure of test
	java/util/concurrent/Phaser/FickleRegister.java
Message-ID: <5492256F.3060101@oracle.com>

Please approve the backport of this fix to 8u60 (jdk8u/hs-dev forest). 
The patch from 9 applied cleanly.

Original closed bug: https://bugs.openjdk.java.net/browse/JDK-8035663
Open backport for 9: https://bugs.openjdk.java.net/browse/JDK-8061564
JDK 9 changeset: 
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/478aaf1a3848

webrev for 8u60: http://cr.openjdk.java.net/~dholmes/8035663/webrev.8u60/

Thanks,
David

From serguei.spitsyn at oracle.com  Thu Dec 18 01:42:00 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 17 Dec 2014 17:42:00 -0800
Subject: RFR: 8067713: Move clean_weak_method_links for redefinition out
	of class unloading
In-Reply-To: <5491C5DB.6000004@oracle.com>
References: <5491C5DB.6000004@oracle.com>
Message-ID: <549230E8.1050805@oracle.com>

Hi Coleen,

The fix looks good.

One minor comment:

src/share/vm/prims/jvmtiRedefineClasses.cpp

3452 // Clean method data for this class
3453 void VM_RedefineClasses::MethodDataCleaner::do_klass(Klass* k) {
3454   if (k->oop_is_instance()) {
3455     InstanceKlass *ik = InstanceKlass::cast(k);
3456     // Clean MethodData of this class's methods so they don't refer to
3457     // old methods that are no longer running.
3458     Array<Method*>* methods = ik->methods();
3459     int num_methods = methods->length();
3460     for (int index2 = 0; index2 < num_methods; ++index2) {
3461       if (methods->at(index2)->method_data() != NULL) {
3462         methods->at(index2)->method_data()->clean_weak_method_links();
3463       }
3464     }
3465   }
3466 }

   Why index2, not just index? :)


Thanks,
Serguei



On 12/17/14 10:05 AM, Coleen Phillimore wrote:
> Summary: Do this work during class redefinition, only verify clean 
> during class unloading in debug mode.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8067713/
> bug link https://bugs.openjdk.java.net/browse/JDK-8067713
>
> Roland added tests for the original bugs
>
> https://bugs.openjdk.java.net/browse/JDK-8038636
> and
> https://bugs.openjdk.java.net/browse/JDK-8040237
>
> test/compiler/profiling/spectrapredefineclass/Launcher.javatest/compiler/profiling/TestSpecTrapClassUnloading.java 
>
>
> Ran jdk/test/java/lang/instrument tests, vm.quick.testlist, testbase 
> vm.redefine.testlist (thanks to Serguei for creating this list) with 
> -Xmixed,
> -Xcomp and
> -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation 
> -XX:-UseOnStackReplacement -XX:-BackgroundCompilation 
> -XX:+UseTypeSpeculation -XX:TypeProfileLevel=222
>
> Thanks,
> Coleen
>
>


From roland.westrelin at oracle.com  Thu Dec 18 09:29:34 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 18 Dec 2014 10:29:34 +0100
Subject: RFR: 8067713: Move clean_weak_method_links for redefinition out
	of class unloading
In-Reply-To: <5491C5DB.6000004@oracle.com>
References: <5491C5DB.6000004@oracle.com>
Message-ID: <872CCABD-3DEA-4AF2-B666-6C752650A197@oracle.com>

> open webrev at http://cr.openjdk.java.net/~coleenp/8067713/

This looks good to me.

Roland.


From alexyursha at gmail.com  Thu Dec 18 12:14:45 2014
From: alexyursha at gmail.com (Alex Yursha)
Date: Thu, 18 Dec 2014 15:14:45 +0300
Subject: Patch for a type in globalDefinitions_gcc.cpp
Message-ID: <547F6742-0C4D-4DE4-B29D-6BA9C9A2ECF0@icloud.com>

Hi all!

I don?t know if its reasonable to spend time on this but just in case decided to submit a patch. There is a typo in *constant* vs *canstant* in a comment.

Thanks



From goetz.lindenmaier at sap.com  Thu Dec 18 13:19:32 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 18 Dec 2014 13:19:32 +0000
Subject: [8u]: backport of 8065915: Fix includes after 8058148:
	MaxNodeLimit and LiveNodeCountInliningCutoff
In-Reply-To: <5491E248.5000000@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF427F3@DEWDFEMB12A.global.corp.sap>
	<5491E248.5000000@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF42EB5@DEWDFEMB12A.global.corp.sap>

I guess 8u60 is fine.

Best regards,
  Goetz.

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Mittwoch, 17. Dezember 2014 21:07
To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'
Subject: Re: [8u]: backport of 8065915: Fix includes after 8058148: MaxNodeLimit and LiveNodeCountInliningCutoff

Hi Goetz,

Do you want to push it into 8u40? Or you are okay with 8u60?
We need an approval for pushing into 8u40 from now on.

Thanks,
Vladimir

On 12/16/14 8:24 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I would like to downport this fix to 8u.  It applies without any problems.
>
> http://cr.openjdk.java.net/~goetz/webrevs/8065915-inclFix/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8065915
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2edb06d66129
>
> I please need a sponsor for this.
>
> Thanks and best regards,
> Goetz.
>

From volker.simonis at gmail.com  Thu Dec 18 16:31:26 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 18 Dec 2014 17:31:26 +0100
Subject: RFR (XXS): 8067865 : Changes 8066780/8066782 broke the non-PCH build
Message-ID: <CA+3eh10JZYcSc2UBfzR7MRfs98jx4=90AhZL7Su3C5j6sLvkNg@mail.gmail.com>

Hi,

could sombody please review and sponsor this little change which fixes
the build on AIX after 8066780/8066782:

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

Here's the full story: 8066780/8066782 did some code refactoring and
introduced the new files cardGeneration.{hpp,cpp,inline.hpp}.
Unfortunately, the changes forgot to include cardGeneration.inline.hpp
into tenuredGeneration.cpp and concurrentMarkSweepGeneration.cpp which
use the methods defined therein.

This problem doesn't show up on Linux (even if build with
'--disable-precompiled-headers') because for some reason GCC places
weak references of the corresponding symbols in cardGeneration.o. So
later when linking libjvm.so the references can still be resolved. Sun
Studio also places global instantiations of the corresponding inline
functions into cardGeneration.o so we don't see any problems there as
well.

xlC on AIX only puts a locally visible reference of the neede inline
functions into cardGeneration.o if he can't inline them (which is
perfectly legal because they are declared 'inline'). However, later
one during linking no globally visible versions of the corresponding
inline functions can be found and the link fails.

The final fix is trivial - just include the corresponding
cardGeneration.inline.hpp file into the .cpp files which require its
method definitions.

Thank you and best regards,
Volker

From coleen.phillimore at oracle.com  Thu Dec 18 19:23:11 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 18 Dec 2014 14:23:11 -0500
Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution
	must support pseudo strings
In-Reply-To: <5491BCB9.10505@oracle.com>
References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com>
	<54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com>
Message-ID: <5493299F.60005@oracle.com>


Hi Serguei,

Thank you for making the patches an optional field.

http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html

  198     if (!patched()) {
  199       assert(false, "a pseudo-string map may exists for patched CP only");
  200       return 0;
  201     }

Why not
                 assert(patched(), "a pseud-string map must exist for 
patched CP only");


Why is this?   Is this really a ShouldNotReachHere?  should it be false?

  215     assert(true, "not found a matching entry in pseudo-string map");


http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html

Don't you have to move the value of the patched field from the old 
constant pool to the new one?  I hate to ask but is there merging that 
needs to be done?   I don't know how to write this test case though.  Is 
it possible to redefine a class with a constant pool patches with 
another that has constant pool patches?

Somehow I thought you'd have to save the value of the cp_patches oops 
passed in.

So I was wondering why you can't change this instead:

   bool is_pseudo_string_at(int which) {
     // A pseudo string is a string that doesn't have a symbol in the cpSlot
-    return unresolved_string_at(which) == NULL;
+   return (strncmp(unresolved_string_at(which)->as_utf8(), 
"CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0);
   }

And the asserts in the other functions below it.

Coleen


On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the second round fix for:
> https://bugs.openjdk.java.net/browse/JDK-8008678
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/
>
>
> Summary:
>
>   This fix implements a footprint saving approach suggested by Coleen.
>   To be able to reconstitute a class constant pool, an intermediate 
> pseudo-string map is used.
>   Now, this field is accounted optionally, only if the 'cp_patches' is 
> provided in the
>   ClassFileParser::parseClassFile() before ConstantPool is allocated.
>   This fix is not elegant, even a little bit ugly, but it is the only 
> way I see so far.
>
>   Unfortunately, this approach did not help much to make some other 
> fields (eg., 'operands') optional.
>   The problem is that we have to account optional fields before 
> parsing, at the CP allocation time.
>   It is possible to re-allocate the ConstantPool when any 
> InvokeDynamic bytecode is discovered,
>   but it looks too complicated.
>
> Testing:
>   - the unit test from bug report
>   - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument
>   - vm.mlvm.testlist, vm.quick.testlist, 
> vm.parallel_class_loading.testlist (in progress)
>
>
> Thanks,
> Serguei
>
>
> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote:
>> Coleen,
>>
>> Thank you for looking at this!
>> I'll check how this can be improved.
>> It is my concern too.
>>
>> Thanks,
>> Serguei
>>
>> On 11/26/14 9:17 AM, Coleen Phillimore wrote:
>>>
>>> Serguei,
>>> I had a quick look at this.  I was wondering if we could make the 
>>> pseudo_string_map conditional in ConstantPool and not make all 
>>> classes pay in footprint for this field?  The same thing probably 
>>> could be done for operands too.  There are flags that you can set to 
>>> conditionally add a pointer to base() in this function.
>>>
>>> Typical C++ would subclass ConstantPool to add 
>>> InvokeDynamicConstantPool fields, but this is not typical C++ so the 
>>> trick we use is like the one in ConstMethod.   I think it's worth 
>>> doing in this case.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote:
>>>> Please, review the fix for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>>>
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ 
>>>>
>>>>
>>>>
>>>> Summary:
>>>>    The pseudo-strings are currently not supported in reconstitution 
>>>> of constant pool.
>>>>
>>>>    This is an explanation from John Rose about what the 
>>>> pseudo-strings are:
>>>>
>>>>    "We still need "live" oop constants pre-linked into the constant 
>>>> pool of bytecodes which
>>>>     implement some method handles. We use the anonymous class 
>>>> pseudo-string feature for that.
>>>>     The relevant code is here:
>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
>>>>
>>>>     These oops are what "pseudo-strings" are.
>>>>     The odd name refers to the fact that, even though they are 
>>>> random oops, they appear in the constant pool
>>>>     where one would expect (because of class file syntax) to find a 
>>>> string."
>>>>      ...
>>>>     If you really wanted to reconstitute a class file for an 
>>>> anonymous class, and
>>>>     if that class has oop patching (pseudo-strings), you would need 
>>>> either to (a) reconstitute the patches array
>>>>     handed to Unsafe.defineAnonymousClass, or (b) accept whatever 
>>>> odd strings were there first, as an approximation.
>>>>     The "odd strings" are totally insignificant, and are typically 
>>>> something like "CONSTANT_PLACEHOLDER_42"
>>>>     (see java/lang/invoke/InvokerBytecodeGenerator.java)."
>>>>
>>>>
>>>>    Reconstitution of the ConstantPool is needed for both the JVMTI 
>>>> GetConstantPool() and RetransformClasses().
>>>>    Finally, it goes to the ConstantPool::copy_cpool_bytes().
>>>>
>>>>    The problem is that a pseudo-string is a patched string that 
>>>> does not have
>>>>    a reference to the string symbol anymore:
>>>>        unresolved_string_at(idx) == NULL
>>>>
>>>>    The fix is to create and fill in a map from JVM_CONSTANT_String 
>>>> cp index to the JVM_CONSTANT_Utf8 cp index
>>>>    to be able to restore this assotiation in the 
>>>> JvmtiConstantPoolReconstituter.
>>>>
>>>> Testing:
>>>>   Run:
>>>>    - java/lang/instrument tests
>>>>    - new jtreg test (see webrev) that was written by Filipp Zhinkin
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>
>>
>


From coleen.phillimore at oracle.com  Thu Dec 18 19:27:13 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 18 Dec 2014 14:27:13 -0500
Subject: RFR: 8067713: Move clean_weak_method_links for redefinition out
	of class unloading
In-Reply-To: <549230E8.1050805@oracle.com>
References: <5491C5DB.6000004@oracle.com> <549230E8.1050805@oracle.com>
Message-ID: <54932A91.3060207@oracle.com>


Thank you Serguei.

On 12/17/14, 8:42 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
> The fix looks good.
>
> One minor comment:
>
> src/share/vm/prims/jvmtiRedefineClasses.cpp
>
> 3452 // Clean method data for this class
> 3453 void VM_RedefineClasses::MethodDataCleaner::do_klass(Klass* k) {
> 3454   if (k->oop_is_instance()) {
> 3455     InstanceKlass *ik = InstanceKlass::cast(k);
> 3456     // Clean MethodData of this class's methods so they don't refer to
> 3457     // old methods that are no longer running.
> 3458     Array<Method*>* methods = ik->methods();
> 3459     int num_methods = methods->length();
> 3460     for (int index2 = 0; index2 < num_methods; ++index2) {
> 3461       if (methods->at(index2)->method_data() != NULL) {
> 3462         methods->at(index2)->method_data()->clean_weak_method_links();
> 3463       }
> 3464     }
> 3465   }
> 3466 }
>
>    Why index2, not just index? :)

I copied it from code in instanceKlass where it used to be.  I'll change 
it to 'index'.

Thanks,
Coleen
>
> Thanks,
> Serguei
>
>
> On 12/17/14 10:05 AM, Coleen Phillimore wrote:
>> Summary: Do this work during class redefinition, only verify clean 
>> during class unloading in debug mode.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8067713/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8067713
>>
>> Roland added tests for the original bugs
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038636
>> and
>> https://bugs.openjdk.java.net/browse/JDK-8040237
>>
>> test/compiler/profiling/spectrapredefineclass/Launcher.javatest/compiler/profiling/TestSpecTrapClassUnloading.java 
>>
>>
>> Ran jdk/test/java/lang/instrument tests, vm.quick.testlist, testbase 
>> vm.redefine.testlist (thanks to Serguei for creating this list) with 
>> -Xmixed,
>> -Xcomp and
>> -XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation 
>> -XX:-UseOnStackReplacement -XX:-BackgroundCompilation 
>> -XX:+UseTypeSpeculation -XX:TypeProfileLevel=222
>>
>> Thanks,
>> Coleen
>>
>>
>


From coleen.phillimore at oracle.com  Thu Dec 18 20:37:17 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 18 Dec 2014 15:37:17 -0500
Subject: RFR: 8067713: Move clean_weak_method_links for redefinition out
	of class unloading
In-Reply-To: <872CCABD-3DEA-4AF2-B666-6C752650A197@oracle.com>
References: <5491C5DB.6000004@oracle.com>
	<872CCABD-3DEA-4AF2-B666-6C752650A197@oracle.com>
Message-ID: <54933AFD.2080100@oracle.com>


Thank you, Roland and thanks for your help on this.
Coleen

On 12/18/14, 4:29 AM, Roland Westrelin wrote:
>> open webrev at http://cr.openjdk.java.net/~coleenp/8067713/
> This looks good to me.
>
> Roland.
>


From kim.barrett at oracle.com  Thu Dec 18 21:01:17 2014
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 18 Dec 2014 16:01:17 -0500
Subject: RFR: 8067713: Move clean_weak_method_links for redefinition out
	of class unloading
In-Reply-To: <5491C5DB.6000004@oracle.com>
References: <5491C5DB.6000004@oracle.com>
Message-ID: <E3741468-9573-4D60-81B1-0F6E88C9C2DC@oracle.com>

On Dec 17, 2014, at 1:05 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> Summary: Do this work during class redefinition, only verify clean during class unloading in debug mode.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8067713/
> bug link https://bugs.openjdk.java.net/browse/JDK-8067713

Looks good, except for some comment issues:

------------------------------------------------------------------------------
src/share/vm/oops/instanceKlass.cpp 

3546 #ifdef ASSERT
3547             if (method->method_data() != NULL) {
3548               // Clean out any weak method links for running methods
3549               // (also should include not EMCP methods)
3550               method->method_data()->verify_clean_weak_method_links();
3551             }
3552 #endif // ASSERT

Comment needs to be updated.  This no longer cleans, it verifies
cleaning has been done.

------------------------------------------------------------------------------
src/share/vm/oops/instanceKlass.cpp  

3566 #ifdef ASSERT
3567   // Verify clean MethodData of this class's methods so they don't refer to
3568   // old methods that are no longer running.

This comment is now poorly worded; suggest something like

   // Verify clean MethodData for this class's methods, e.g. they don't refer to
   // old methods that are no longer running.

[Someone else already complained about index2 near here.]

------------------------------------------------------------------------------


From coleen.phillimore at oracle.com  Thu Dec 18 21:16:14 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 18 Dec 2014 16:16:14 -0500
Subject: RFR: 8067713: Move clean_weak_method_links for redefinition out
	of class unloading
In-Reply-To: <E3741468-9573-4D60-81B1-0F6E88C9C2DC@oracle.com>
References: <5491C5DB.6000004@oracle.com>
	<E3741468-9573-4D60-81B1-0F6E88C9C2DC@oracle.com>
Message-ID: <5493441E.7000908@oracle.com>


Kim,

Thank you for the code review.

On 12/18/14, 4:01 PM, Kim Barrett wrote:
> On Dec 17, 2014, at 1:05 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> Summary: Do this work during class redefinition, only verify clean during class unloading in debug mode.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8067713/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8067713
> Looks good, except for some comment issues:
>
> ------------------------------------------------------------------------------
> src/share/vm/oops/instanceKlass.cpp
>
> 3546 #ifdef ASSERT
> 3547             if (method->method_data() != NULL) {
> 3548               // Clean out any weak method links for running methods
> 3549               // (also should include not EMCP methods)
> 3550               method->method_data()->verify_clean_weak_method_links();
> 3551             }
> 3552 #endif // ASSERT
>
> Comment needs to be updated.  This no longer cleans, it verifies
> cleaning has been done.

               // Verify MethodData for running methods don't refer to 
old methods.

I left out EMCP methods part, that was referring to a former bug that 
was in this code.
>
> ------------------------------------------------------------------------------
> src/share/vm/oops/instanceKlass.cpp
>
> 3566 #ifdef ASSERT
> 3567   // Verify clean MethodData of this class's methods so they don't refer to
> 3568   // old methods that are no longer running.
>
> This comment is now poorly worded; suggest something like
>
>     // Verify clean MethodData for this class's methods, e.g. they don't refer to
>     // old methods that are no longer running.

Sure.  I changed it.

I changed the both occurences of "index2".

Coleen


>
> [Someone else already complained about index2 near here.]
>
> ------------------------------------------------------------------------------
>


From david.holmes at oracle.com  Thu Dec 18 21:43:14 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Dec 2014 07:43:14 +1000
Subject: [8u60] RFR: 8035663 Suspicious failure of test
	java/util/concurrent/Phaser/FickleRegister.java
In-Reply-To: <5492256F.3060101@oracle.com>
References: <5492256F.3060101@oracle.com>
Message-ID: <54934A72.9030005@oracle.com>

Someone please! I want to get this finalized before I start Xmas break 
tomorrow :)

Thanks,
David

On 18/12/2014 10:53 AM, David Holmes wrote:
> Please approve the backport of this fix to 8u60 (jdk8u/hs-dev forest).
> The patch from 9 applied cleanly.
>
> Original closed bug: https://bugs.openjdk.java.net/browse/JDK-8035663
> Open backport for 9: https://bugs.openjdk.java.net/browse/JDK-8061564
> JDK 9 changeset:
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/478aaf1a3848
>
> webrev for 8u60: http://cr.openjdk.java.net/~dholmes/8035663/webrev.8u60/
>
> Thanks,
> David

From serguei.spitsyn at oracle.com  Thu Dec 18 22:00:19 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 18 Dec 2014 14:00:19 -0800
Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution
	must support pseudo strings
In-Reply-To: <5493299F.60005@oracle.com>
References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com>
	<54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com>
	<5493299F.60005@oracle.com>
Message-ID: <54934E73.4080808@oracle.com>

Hi Coleen,

Thank you for reviewing!


On 12/18/14 11:23 AM, Coleen Phillimore wrote:
>
> Hi Serguei,
>
> Thank you for making the patches an optional field.
>
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html
>   198     if (!patched()) {
>   199       assert(false, "a pseudo-string map may exists for patched CP only");
>   200       return 0;
>   201     }
> Why not
>                 assert(patched(), "a pseud-string map must exist for 
> patched CP only");

Wanted it to be more reliable but it looks pointless.
Will make this change.

>
>
> Why is this?   Is this really a ShouldNotReachHere?  should it be false?
>
>   215     assert(true, "not found a matching entry in pseudo-string map");


A typo, must be false.
It is the last minute change.
Thanks for the catch!


>
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html
>
> Don't you have to move the value of the patched field from the old 
> constant pool to the new one?  I hate to ask but is there merging that 
> needs to be done?   I don't know how to write this test case though.  
> Is it possible to redefine a class with a constant pool patches with 
> another that has constant pool patches?

Thank you for asking this question.
If I understand correctly, the patching comes from the compiler side for 
anonymous classes only.
I saw it for LambdaForm's only.
I think, the patching can not be changed with a retransformation.
But I'm not sure if it can not be changed with a redefinition.

But if it can - then it would be safe to merge the 'patched' condition, 
i.e. make it patched
if either the_class or scratch class is patched.

>
> Somehow I thought you'd have to save the value of the cp_patches oops 
> passed in.
>
> So I was wondering why you can't change this instead:
>
>   bool is_pseudo_string_at(int which) {
>     // A pseudo string is a string that doesn't have a symbol in the 
> cpSlot
> -    return unresolved_string_at(which) == NULL;
> +   return (strncmp(unresolved_string_at(which)->as_utf8(), 
> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0);
>   }

I was thinking about the same but was not sure if it would work for the 
compiler team.
We have to ask John about this (added John and Christian to the cc-list).
This question to John was in my plan! :)

The beauty of the above approach is that there is no need to create an 
intermediate
pseudo-string map and most of the code in from this webrev is not needed.


Thanks,
Serguei

>
> And the asserts in the other functions below it.
>
> Coleen
>
>
> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the second round fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/
>>
>>
>> Summary:
>>
>>   This fix implements a footprint saving approach suggested by Coleen.
>>   To be able to reconstitute a class constant pool, an intermediate 
>> pseudo-string map is used.
>>   Now, this field is accounted optionally, only if the 'cp_patches' 
>> is provided in the
>>   ClassFileParser::parseClassFile() before ConstantPool is allocated.
>>   This fix is not elegant, even a little bit ugly, but it is the only 
>> way I see so far.
>>
>>   Unfortunately, this approach did not help much to make some other 
>> fields (eg., 'operands') optional.
>>   The problem is that we have to account optional fields before 
>> parsing, at the CP allocation time.
>>   It is possible to re-allocate the ConstantPool when any 
>> InvokeDynamic bytecode is discovered,
>>   but it looks too complicated.
>>
>> Testing:
>>   - the unit test from bug report
>>   - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument
>>   - vm.mlvm.testlist, vm.quick.testlist, 
>> vm.parallel_class_loading.testlist (in progress)
>>
>>
>> Thanks,
>> Serguei
>>
>>
>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote:
>>> Coleen,
>>>
>>> Thank you for looking at this!
>>> I'll check how this can be improved.
>>> It is my concern too.
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote:
>>>>
>>>> Serguei,
>>>> I had a quick look at this.  I was wondering if we could make the 
>>>> pseudo_string_map conditional in ConstantPool and not make all 
>>>> classes pay in footprint for this field?  The same thing probably 
>>>> could be done for operands too.  There are flags that you can set 
>>>> to conditionally add a pointer to base() in this function.
>>>>
>>>> Typical C++ would subclass ConstantPool to add 
>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so 
>>>> the trick we use is like the one in ConstMethod.   I think it's 
>>>> worth doing in this case.
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the fix for:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>>>>
>>>>>
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ 
>>>>>
>>>>>
>>>>>
>>>>> Summary:
>>>>>    The pseudo-strings are currently not supported in 
>>>>> reconstitution of constant pool.
>>>>>
>>>>>    This is an explanation from John Rose about what the 
>>>>> pseudo-strings are:
>>>>>
>>>>>    "We still need "live" oop constants pre-linked into the 
>>>>> constant pool of bytecodes which
>>>>>     implement some method handles. We use the anonymous class 
>>>>> pseudo-string feature for that.
>>>>>     The relevant code is here:
>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
>>>>>
>>>>>     These oops are what "pseudo-strings" are.
>>>>>     The odd name refers to the fact that, even though they are 
>>>>> random oops, they appear in the constant pool
>>>>>     where one would expect (because of class file syntax) to find 
>>>>> a string."
>>>>>      ...
>>>>>     If you really wanted to reconstitute a class file for an 
>>>>> anonymous class, and
>>>>>     if that class has oop patching (pseudo-strings), you would 
>>>>> need either to (a) reconstitute the patches array
>>>>>     handed to Unsafe.defineAnonymousClass, or (b) accept whatever 
>>>>> odd strings were there first, as an approximation.
>>>>>     The "odd strings" are totally insignificant, and are typically 
>>>>> something like "CONSTANT_PLACEHOLDER_42"
>>>>>     (see java/lang/invoke/InvokerBytecodeGenerator.java)."
>>>>>
>>>>>
>>>>>    Reconstitution of the ConstantPool is needed for both the JVMTI 
>>>>> GetConstantPool() and RetransformClasses().
>>>>>    Finally, it goes to the ConstantPool::copy_cpool_bytes().
>>>>>
>>>>>    The problem is that a pseudo-string is a patched string that 
>>>>> does not have
>>>>>    a reference to the string symbol anymore:
>>>>>        unresolved_string_at(idx) == NULL
>>>>>
>>>>>    The fix is to create and fill in a map from JVM_CONSTANT_String 
>>>>> cp index to the JVM_CONSTANT_Utf8 cp index
>>>>>    to be able to restore this assotiation in the 
>>>>> JvmtiConstantPoolReconstituter.
>>>>>
>>>>> Testing:
>>>>>   Run:
>>>>>    - java/lang/instrument tests
>>>>>    - new jtreg test (see webrev) that was written by Filipp Zhinkin
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>
>>>
>>
>


From serguei.spitsyn at oracle.com  Thu Dec 18 22:23:04 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 18 Dec 2014 14:23:04 -0800
Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution
	must support pseudo strings
In-Reply-To: <54934E73.4080808@oracle.com>
References: <5475968C.40800@oracle.com>
	<54760B40.9040206@oracle.com>	<54762FC9.2010800@oracle.com>
	<5491BCB9.10505@oracle.com>	<5493299F.60005@oracle.com>
	<54934E73.4080808@oracle.com>
Message-ID: <549353C8.9000706@oracle.com>

On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
> Thank you for reviewing!
>
>
> On 12/18/14 11:23 AM, Coleen Phillimore wrote:
>>
>> Hi Serguei,
>>
>> Thank you for making the patches an optional field.
>>
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html
>>   198     if (!patched()) {
>>   199       assert(false, "a pseudo-string map may exists for patched CP only");
>>   200       return 0;
>>   201     }
>> Why not
>>                 assert(patched(), "a pseud-string map must exist for 
>> patched CP only");
>
> Wanted it to be more reliable but it looks pointless.
> Will make this change.
>
>>
>>
>> Why is this?   Is this really a ShouldNotReachHere?  should it be false?
>>
>>   215     assert(true, "not found a matching entry in pseudo-string map");
>
>
> A typo, must be false.
> It is the last minute change.
> Thanks for the catch!
>
>
>>
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html
>>
>> Don't you have to move the value of the patched field from the old 
>> constant pool to the new one?  I hate to ask but is there merging 
>> that needs to be done?   I don't know how to write this test case 
>> though.  Is it possible to redefine a class with a constant pool 
>> patches with another that has constant pool patches?
>
> Thank you for asking this question.
> If I understand correctly, the patching comes from the compiler side 
> for anonymous classes only.
> I saw it for LambdaForm's only.
> I think, the patching can not be changed with a retransformation.
> But I'm not sure if it can not be changed with a redefinition.
>
> But if it can - then it would be safe to merge the 'patched' 
> condition, i.e. make it patched
> if either the_class or scratch class is patched.
>
>>
>> Somehow I thought you'd have to save the value of the cp_patches oops 
>> passed in.

Forgot to answer this good question.

If the cp_patches can be changed with a class redefinition (it, 
probably, can)
then it needs to be saved and merged too.
Can we separate this cp_patches merge issue into another bug or RFE?
The need still has to be clarified though, I'll check this with John.


Thanks,
Serguei


>>
>> So I was wondering why you can't change this instead:
>>
>>   bool is_pseudo_string_at(int which) {
>>     // A pseudo string is a string that doesn't have a symbol in the 
>> cpSlot
>> -    return unresolved_string_at(which) == NULL;
>> +   return (strncmp(unresolved_string_at(which)->as_utf8(), 
>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0);
>>   }
>
> I was thinking about the same but was not sure if it would work for 
> the compiler team.
> We have to ask John about this (added John and Christian to the cc-list).
> This question to John was in my plan! :)
>
> The beauty of the above approach is that there is no need to create an 
> intermediate
> pseudo-string map and most of the code in from this webrev is not needed.
>
>
> Thanks,
> Serguei
>
>>
>> And the asserts in the other functions below it.
>>
>> Coleen
>>
>>
>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the second round fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>>
>>> Open webrev:
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/
>>>
>>>
>>> Summary:
>>>
>>>   This fix implements a footprint saving approach suggested by Coleen.
>>>   To be able to reconstitute a class constant pool, an intermediate 
>>> pseudo-string map is used.
>>>   Now, this field is accounted optionally, only if the 'cp_patches' 
>>> is provided in the
>>>   ClassFileParser::parseClassFile() before ConstantPool is allocated.
>>>   This fix is not elegant, even a little bit ugly, but it is the 
>>> only way I see so far.
>>>
>>>   Unfortunately, this approach did not help much to make some other 
>>> fields (eg., 'operands') optional.
>>>   The problem is that we have to account optional fields before 
>>> parsing, at the CP allocation time.
>>>   It is possible to re-allocate the ConstantPool when any 
>>> InvokeDynamic bytecode is discovered,
>>>   but it looks too complicated.
>>>
>>> Testing:
>>>   - the unit test from bug report
>>>   - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument
>>>   - vm.mlvm.testlist, vm.quick.testlist, 
>>> vm.parallel_class_loading.testlist (in progress)
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote:
>>>> Coleen,
>>>>
>>>> Thank you for looking at this!
>>>> I'll check how this can be improved.
>>>> It is my concern too.
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote:
>>>>>
>>>>> Serguei,
>>>>> I had a quick look at this.  I was wondering if we could make the 
>>>>> pseudo_string_map conditional in ConstantPool and not make all 
>>>>> classes pay in footprint for this field?  The same thing probably 
>>>>> could be done for operands too.  There are flags that you can set 
>>>>> to conditionally add a pointer to base() in this function.
>>>>>
>>>>> Typical C++ would subclass ConstantPool to add 
>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so 
>>>>> the trick we use is like the one in ConstMethod. I think it's 
>>>>> worth doing in this case.
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote:
>>>>>> Please, review the fix for:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>>>>>
>>>>>>
>>>>>> Open webrev:
>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Summary:
>>>>>>    The pseudo-strings are currently not supported in 
>>>>>> reconstitution of constant pool.
>>>>>>
>>>>>>    This is an explanation from John Rose about what the 
>>>>>> pseudo-strings are:
>>>>>>
>>>>>>    "We still need "live" oop constants pre-linked into the 
>>>>>> constant pool of bytecodes which
>>>>>>     implement some method handles. We use the anonymous class 
>>>>>> pseudo-string feature for that.
>>>>>>     The relevant code is here:
>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
>>>>>>
>>>>>>     These oops are what "pseudo-strings" are.
>>>>>>     The odd name refers to the fact that, even though they are 
>>>>>> random oops, they appear in the constant pool
>>>>>>     where one would expect (because of class file syntax) to find 
>>>>>> a string."
>>>>>>      ...
>>>>>>     If you really wanted to reconstitute a class file for an 
>>>>>> anonymous class, and
>>>>>>     if that class has oop patching (pseudo-strings), you would 
>>>>>> need either to (a) reconstitute the patches array
>>>>>>     handed to Unsafe.defineAnonymousClass, or (b) accept whatever 
>>>>>> odd strings were there first, as an approximation.
>>>>>>     The "odd strings" are totally insignificant, and are 
>>>>>> typically something like "CONSTANT_PLACEHOLDER_42"
>>>>>>     (see java/lang/invoke/InvokerBytecodeGenerator.java)."
>>>>>>
>>>>>>
>>>>>>    Reconstitution of the ConstantPool is needed for both the 
>>>>>> JVMTI GetConstantPool() and RetransformClasses().
>>>>>>    Finally, it goes to the ConstantPool::copy_cpool_bytes().
>>>>>>
>>>>>>    The problem is that a pseudo-string is a patched string that 
>>>>>> does not have
>>>>>>    a reference to the string symbol anymore:
>>>>>>        unresolved_string_at(idx) == NULL
>>>>>>
>>>>>>    The fix is to create and fill in a map from 
>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index
>>>>>>    to be able to restore this assotiation in the 
>>>>>> JvmtiConstantPoolReconstituter.
>>>>>>
>>>>>> Testing:
>>>>>>   Run:
>>>>>>    - java/lang/instrument tests
>>>>>>    - new jtreg test (see webrev) that was written by Filipp Zhinkin
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>
>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Thu Dec 18 22:59:45 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 18 Dec 2014 17:59:45 -0500
Subject: [8u60] RFR: 8035663 Suspicious failure of test
	java/util/concurrent/Phaser/FickleRegister.java
In-Reply-To: <54934A72.9030005@oracle.com>
References: <5492256F.3060101@oracle.com> <54934A72.9030005@oracle.com>
Message-ID: <54935C61.6060405@oracle.com>


This looks fine.   Happy Holidays!
Coleen

On 12/18/14, 4:43 PM, David Holmes wrote:
> Someone please! I want to get this finalized before I start Xmas break 
> tomorrow :)
>
> Thanks,
> David
>
> On 18/12/2014 10:53 AM, David Holmes wrote:
>> Please approve the backport of this fix to 8u60 (jdk8u/hs-dev forest).
>> The patch from 9 applied cleanly.
>>
>> Original closed bug: https://bugs.openjdk.java.net/browse/JDK-8035663
>> Open backport for 9: https://bugs.openjdk.java.net/browse/JDK-8061564
>> JDK 9 changeset:
>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/478aaf1a3848
>>
>> webrev for 8u60: 
>> http://cr.openjdk.java.net/~dholmes/8035663/webrev.8u60/
>>
>> Thanks,
>> David


From coleen.phillimore at oracle.com  Thu Dec 18 23:01:59 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 18 Dec 2014 18:01:59 -0500
Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution
	must support pseudo strings
In-Reply-To: <549353C8.9000706@oracle.com>
References: <5475968C.40800@oracle.com>
	<54760B40.9040206@oracle.com>	<54762FC9.2010800@oracle.com>
	<5491BCB9.10505@oracle.com>	<5493299F.60005@oracle.com>
	<54934E73.4080808@oracle.com> <549353C8.9000706@oracle.com>
Message-ID: <54935CE7.2020400@oracle.com>


On 12/18/14, 5:23 PM, serguei.spitsyn at oracle.com wrote:
> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote:
>> Hi Coleen,
>>
>> Thank you for reviewing!
>>
>>
>> On 12/18/14 11:23 AM, Coleen Phillimore wrote:
>>>
>>> Hi Serguei,
>>>
>>> Thank you for making the patches an optional field.
>>>
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html
>>>   198     if (!patched()) {
>>>   199       assert(false, "a pseudo-string map may exists for patched CP only");
>>>   200       return 0;
>>>   201     }
>>> Why not
>>>                 assert(patched(), "a pseud-string map must exist for 
>>> patched CP only");
>>
>> Wanted it to be more reliable but it looks pointless.
>> Will make this change.
>>
>>>
>>>
>>> Why is this?   Is this really a ShouldNotReachHere?  should it be false?
>>>
>>>   215     assert(true, "not found a matching entry in pseudo-string map");
>>
>>
>> A typo, must be false.
>> It is the last minute change.
>> Thanks for the catch!
>>
>>
>>>
>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html
>>>
>>> Don't you have to move the value of the patched field from the old 
>>> constant pool to the new one?  I hate to ask but is there merging 
>>> that needs to be done?   I don't know how to write this test case 
>>> though.  Is it possible to redefine a class with a constant pool 
>>> patches with another that has constant pool patches?
>>
>> Thank you for asking this question.
>> If I understand correctly, the patching comes from the compiler side 
>> for anonymous classes only.
>> I saw it for LambdaForm's only.
>> I think, the patching can not be changed with a retransformation.
>> But I'm not sure if it can not be changed with a redefinition.
>>
>> But if it can - then it would be safe to merge the 'patched' 
>> condition, i.e. make it patched
>> if either the_class or scratch class is patched.
>>
>>>
>>> Somehow I thought you'd have to save the value of the cp_patches 
>>> oops passed in.
>
> Forgot to answer this good question.
>
> If the cp_patches can be changed with a class redefinition (it, 
> probably, can)
> then it needs to be saved and merged too.
> Can we separate this cp_patches merge issue into another bug or RFE?
> The need still has to be clarified though, I'll check this with John.

Yes, it seems good to have a follow up bug for this once the requirement 
is understood.  It may be a fair bit of work.

Thanks,
Coleen

>
>
> Thanks,
> Serguei
>
>
>>>
>>> So I was wondering why you can't change this instead:
>>>
>>>   bool is_pseudo_string_at(int which) {
>>>     // A pseudo string is a string that doesn't have a symbol in the 
>>> cpSlot
>>> -    return unresolved_string_at(which) == NULL;
>>> +   return (strncmp(unresolved_string_at(which)->as_utf8(), 
>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0);
>>>   }
>>
>> I was thinking about the same but was not sure if it would work for 
>> the compiler team.
>> We have to ask John about this (added John and Christian to the cc-list).
>> This question to John was in my plan! :)
>>
>> The beauty of the above approach is that there is no need to create 
>> an intermediate
>> pseudo-string map and most of the code in from this webrev is not needed.
>>
>>
>> Thanks,
>> Serguei
>>
>>>
>>> And the asserts in the other functions below it.
>>>
>>> Coleen
>>>
>>>
>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote:
>>>> Please, review the second round fix for:
>>>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>>>
>>>> Open webrev:
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/
>>>>
>>>>
>>>> Summary:
>>>>
>>>>   This fix implements a footprint saving approach suggested by Coleen.
>>>>   To be able to reconstitute a class constant pool, an intermediate 
>>>> pseudo-string map is used.
>>>>   Now, this field is accounted optionally, only if the 'cp_patches' 
>>>> is provided in the
>>>>   ClassFileParser::parseClassFile() before ConstantPool is allocated.
>>>>   This fix is not elegant, even a little bit ugly, but it is the 
>>>> only way I see so far.
>>>>
>>>>   Unfortunately, this approach did not help much to make some other 
>>>> fields (eg., 'operands') optional.
>>>>   The problem is that we have to account optional fields before 
>>>> parsing, at the CP allocation time.
>>>>   It is possible to re-allocate the ConstantPool when any 
>>>> InvokeDynamic bytecode is discovered,
>>>>   but it looks too complicated.
>>>>
>>>> Testing:
>>>>   - the unit test from bug report
>>>>   - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument
>>>>   - vm.mlvm.testlist, vm.quick.testlist, 
>>>> vm.parallel_class_loading.testlist (in progress)
>>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>
>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote:
>>>>> Coleen,
>>>>>
>>>>> Thank you for looking at this!
>>>>> I'll check how this can be improved.
>>>>> It is my concern too.
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote:
>>>>>>
>>>>>> Serguei,
>>>>>> I had a quick look at this.  I was wondering if we could make the 
>>>>>> pseudo_string_map conditional in ConstantPool and not make all 
>>>>>> classes pay in footprint for this field?  The same thing probably 
>>>>>> could be done for operands too.  There are flags that you can set 
>>>>>> to conditionally add a pointer to base() in this function.
>>>>>>
>>>>>> Typical C++ would subclass ConstantPool to add 
>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so 
>>>>>> the trick we use is like the one in ConstMethod.   I think it's 
>>>>>> worth doing in this case.
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>>>
>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote:
>>>>>>> Please, review the fix for:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>>>>>>
>>>>>>>
>>>>>>> Open webrev:
>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Summary:
>>>>>>>    The pseudo-strings are currently not supported in 
>>>>>>> reconstitution of constant pool.
>>>>>>>
>>>>>>>    This is an explanation from John Rose about what the 
>>>>>>> pseudo-strings are:
>>>>>>>
>>>>>>>    "We still need "live" oop constants pre-linked into the 
>>>>>>> constant pool of bytecodes which
>>>>>>>     implement some method handles. We use the anonymous class 
>>>>>>> pseudo-string feature for that.
>>>>>>>     The relevant code is here:
>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
>>>>>>>
>>>>>>>     These oops are what "pseudo-strings" are.
>>>>>>>     The odd name refers to the fact that, even though they are 
>>>>>>> random oops, they appear in the constant pool
>>>>>>>     where one would expect (because of class file syntax) to 
>>>>>>> find a string."
>>>>>>>      ...
>>>>>>>     If you really wanted to reconstitute a class file for an 
>>>>>>> anonymous class, and
>>>>>>>     if that class has oop patching (pseudo-strings), you would 
>>>>>>> need either to (a) reconstitute the patches array
>>>>>>>     handed to Unsafe.defineAnonymousClass, or (b) accept 
>>>>>>> whatever odd strings were there first, as an approximation.
>>>>>>>     The "odd strings" are totally insignificant, and are 
>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42"
>>>>>>>     (see java/lang/invoke/InvokerBytecodeGenerator.java)."
>>>>>>>
>>>>>>>
>>>>>>>    Reconstitution of the ConstantPool is needed for both the 
>>>>>>> JVMTI GetConstantPool() and RetransformClasses().
>>>>>>>    Finally, it goes to the ConstantPool::copy_cpool_bytes().
>>>>>>>
>>>>>>>    The problem is that a pseudo-string is a patched string that 
>>>>>>> does not have
>>>>>>>    a reference to the string symbol anymore:
>>>>>>>        unresolved_string_at(idx) == NULL
>>>>>>>
>>>>>>>    The fix is to create and fill in a map from 
>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index
>>>>>>>    to be able to restore this assotiation in the 
>>>>>>> JvmtiConstantPoolReconstituter.
>>>>>>>
>>>>>>> Testing:
>>>>>>>   Run:
>>>>>>>    - java/lang/instrument tests
>>>>>>>    - new jtreg test (see webrev) that was written by Filipp Zhinkin
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Serguei
>>>>>>
>>>>>
>>>>
>>>
>>
>


From serguei.spitsyn at oracle.com  Thu Dec 18 23:14:33 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 18 Dec 2014 15:14:33 -0800
Subject: [8u60] RFR: 8035663 Suspicious failure of test
	java/util/concurrent/Phaser/FickleRegister.java
In-Reply-To: <54935C61.6060405@oracle.com>
References: <5492256F.3060101@oracle.com> <54934A72.9030005@oracle.com>
	<54935C61.6060405@oracle.com>
Message-ID: <54935FD9.8090508@oracle.com>

+1 Including "Happy Holidays!"

Thanks,
Serguei

On 12/18/14 2:59 PM, Coleen Phillimore wrote:
>
> This looks fine.   Happy Holidays!
> Coleen
>
> On 12/18/14, 4:43 PM, David Holmes wrote:
>> Someone please! I want to get this finalized before I start Xmas 
>> break tomorrow :)
>>
>> Thanks,
>> David
>>
>> On 18/12/2014 10:53 AM, David Holmes wrote:
>>> Please approve the backport of this fix to 8u60 (jdk8u/hs-dev forest).
>>> The patch from 9 applied cleanly.
>>>
>>> Original closed bug: https://bugs.openjdk.java.net/browse/JDK-8035663
>>> Open backport for 9: https://bugs.openjdk.java.net/browse/JDK-8061564
>>> JDK 9 changeset:
>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/478aaf1a3848
>>>
>>> webrev for 8u60: 
>>> http://cr.openjdk.java.net/~dholmes/8035663/webrev.8u60/
>>>
>>> Thanks,
>>> David
>


From serguei.spitsyn at oracle.com  Thu Dec 18 23:20:28 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 18 Dec 2014 15:20:28 -0800
Subject: 2-nd round RFR (S) 8008678: JSR 292: constant pool reconstitution
	must support pseudo strings
In-Reply-To: <54935CE7.2020400@oracle.com>
References: <5475968C.40800@oracle.com>
	<54760B40.9040206@oracle.com>	<54762FC9.2010800@oracle.com>
	<5491BCB9.10505@oracle.com>	<5493299F.60005@oracle.com>
	<54934E73.4080808@oracle.com> <549353C8.9000706@oracle.com>
	<54935CE7.2020400@oracle.com>
Message-ID: <5493613C.6040804@oracle.com>

On 12/18/14 3:01 PM, Coleen Phillimore wrote:
>
> On 12/18/14, 5:23 PM, serguei.spitsyn at oracle.com wrote:
>> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote:
>>> Hi Coleen,
>>>
>>> Thank you for reviewing!
>>>
>>>
>>> On 12/18/14 11:23 AM, Coleen Phillimore wrote:
>>>>
>>>> Hi Serguei,
>>>>
>>>> Thank you for making the patches an optional field.
>>>>
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html
>>>>   198     if (!patched()) {
>>>>   199       assert(false, "a pseudo-string map may exists for patched CP only");
>>>>   200       return 0;
>>>>   201     }
>>>> Why not
>>>>                 assert(patched(), "a pseud-string map must exist 
>>>> for patched CP only");
>>>
>>> Wanted it to be more reliable but it looks pointless.
>>> Will make this change.
>>>
>>>>
>>>>
>>>> Why is this?   Is this really a ShouldNotReachHere?  should it be 
>>>> false?
>>>>
>>>>   215     assert(true, "not found a matching entry in pseudo-string map");
>>>
>>>
>>> A typo, must be false.
>>> It is the last minute change.
>>> Thanks for the catch!
>>>
>>>
>>>>
>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html
>>>>
>>>> Don't you have to move the value of the patched field from the old 
>>>> constant pool to the new one?  I hate to ask but is there merging 
>>>> that needs to be done?   I don't know how to write this test case 
>>>> though.  Is it possible to redefine a class with a constant pool 
>>>> patches with another that has constant pool patches?
>>>
>>> Thank you for asking this question.
>>> If I understand correctly, the patching comes from the compiler side 
>>> for anonymous classes only.
>>> I saw it for LambdaForm's only.
>>> I think, the patching can not be changed with a retransformation.
>>> But I'm not sure if it can not be changed with a redefinition.
>>>
>>> But if it can - then it would be safe to merge the 'patched' 
>>> condition, i.e. make it patched
>>> if either the_class or scratch class is patched.
>>>
>>>>
>>>> Somehow I thought you'd have to save the value of the cp_patches 
>>>> oops passed in.
>>
>> Forgot to answer this good question.
>>
>> If the cp_patches can be changed with a class redefinition (it, 
>> probably, can)
>> then it needs to be saved and merged too.
>> Can we separate this cp_patches merge issue into another bug or RFE?
>> The need still has to be clarified though, I'll check this with John.
>
> Yes, it seems good to have a follow up bug for this once the 
> requirement is understood.  It may be a fair bit of work.

Ok, thanks!
Serguei

>
> Thanks,
> Coleen
>
>>
>>
>> Thanks,
>> Serguei
>>
>>
>>>>
>>>> So I was wondering why you can't change this instead:
>>>>
>>>>   bool is_pseudo_string_at(int which) {
>>>>     // A pseudo string is a string that doesn't have a symbol in 
>>>> the cpSlot
>>>> -    return unresolved_string_at(which) == NULL;
>>>> +   return (strncmp(unresolved_string_at(which)->as_utf8(), 
>>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0);
>>>>   }
>>>
>>> I was thinking about the same but was not sure if it would work for 
>>> the compiler team.
>>> We have to ask John about this (added John and Christian to the 
>>> cc-list).
>>> This question to John was in my plan! :)
>>>
>>> The beauty of the above approach is that there is no need to create 
>>> an intermediate
>>> pseudo-string map and most of the code in from this webrev is not 
>>> needed.
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>>
>>>> And the asserts in the other functions below it.
>>>>
>>>> Coleen
>>>>
>>>>
>>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote:
>>>>> Please, review the second round fix for:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>>>>
>>>>> Open webrev:
>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/
>>>>>
>>>>>
>>>>> Summary:
>>>>>
>>>>>   This fix implements a footprint saving approach suggested by Coleen.
>>>>>   To be able to reconstitute a class constant pool, an 
>>>>> intermediate pseudo-string map is used.
>>>>>   Now, this field is accounted optionally, only if the 
>>>>> 'cp_patches' is provided in the
>>>>>   ClassFileParser::parseClassFile() before ConstantPool is allocated.
>>>>>   This fix is not elegant, even a little bit ugly, but it is the 
>>>>> only way I see so far.
>>>>>
>>>>>   Unfortunately, this approach did not help much to make some 
>>>>> other fields (eg., 'operands') optional.
>>>>>   The problem is that we have to account optional fields before 
>>>>> parsing, at the CP allocation time.
>>>>>   It is possible to re-allocate the ConstantPool when any 
>>>>> InvokeDynamic bytecode is discovered,
>>>>>   but it looks too complicated.
>>>>>
>>>>> Testing:
>>>>>   - the unit test from bug report
>>>>>   - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument
>>>>>   - vm.mlvm.testlist, vm.quick.testlist, 
>>>>> vm.parallel_class_loading.testlist (in progress)
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>
>>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote:
>>>>>> Coleen,
>>>>>>
>>>>>> Thank you for looking at this!
>>>>>> I'll check how this can be improved.
>>>>>> It is my concern too.
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote:
>>>>>>>
>>>>>>> Serguei,
>>>>>>> I had a quick look at this.  I was wondering if we could make 
>>>>>>> the pseudo_string_map conditional in ConstantPool and not make 
>>>>>>> all classes pay in footprint for this field?  The same thing 
>>>>>>> probably could be done for operands too.  There are flags that 
>>>>>>> you can set to conditionally add a pointer to base() in this 
>>>>>>> function.
>>>>>>>
>>>>>>> Typical C++ would subclass ConstantPool to add 
>>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so 
>>>>>>> the trick we use is like the one in ConstMethod.   I think it's 
>>>>>>> worth doing in this case.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>>
>>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Please, review the fix for:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678
>>>>>>>>
>>>>>>>>
>>>>>>>> Open webrev:
>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Summary:
>>>>>>>>    The pseudo-strings are currently not supported in 
>>>>>>>> reconstitution of constant pool.
>>>>>>>>
>>>>>>>>    This is an explanation from John Rose about what the 
>>>>>>>> pseudo-strings are:
>>>>>>>>
>>>>>>>>    "We still need "live" oop constants pre-linked into the 
>>>>>>>> constant pool of bytecodes which
>>>>>>>>     implement some method handles. We use the anonymous class 
>>>>>>>> pseudo-string feature for that.
>>>>>>>>     The relevant code is here:
>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
>>>>>>>>
>>>>>>>>     These oops are what "pseudo-strings" are.
>>>>>>>>     The odd name refers to the fact that, even though they are 
>>>>>>>> random oops, they appear in the constant pool
>>>>>>>>     where one would expect (because of class file syntax) to 
>>>>>>>> find a string."
>>>>>>>>      ...
>>>>>>>>     If you really wanted to reconstitute a class file for an 
>>>>>>>> anonymous class, and
>>>>>>>>     if that class has oop patching (pseudo-strings), you would 
>>>>>>>> need either to (a) reconstitute the patches array
>>>>>>>>     handed to Unsafe.defineAnonymousClass, or (b) accept 
>>>>>>>> whatever odd strings were there first, as an approximation.
>>>>>>>>     The "odd strings" are totally insignificant, and are 
>>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42"
>>>>>>>>     (see java/lang/invoke/InvokerBytecodeGenerator.java)."
>>>>>>>>
>>>>>>>>
>>>>>>>>    Reconstitution of the ConstantPool is needed for both the 
>>>>>>>> JVMTI GetConstantPool() and RetransformClasses().
>>>>>>>>    Finally, it goes to the ConstantPool::copy_cpool_bytes().
>>>>>>>>
>>>>>>>>    The problem is that a pseudo-string is a patched string that 
>>>>>>>> does not have
>>>>>>>>    a reference to the string symbol anymore:
>>>>>>>>        unresolved_string_at(idx) == NULL
>>>>>>>>
>>>>>>>>    The fix is to create and fill in a map from 
>>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index
>>>>>>>>    to be able to restore this assotiation in the 
>>>>>>>> JvmtiConstantPoolReconstituter.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>>   Run:
>>>>>>>>    - java/lang/instrument tests
>>>>>>>>    - new jtreg test (see webrev) that was written by Filipp 
>>>>>>>> Zhinkin
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From alejandro.murillo at oracle.com  Fri Dec 19 00:16:14 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 18 Dec 2014 17:16:14 -0700
Subject: [8u60] RFR:  8067802: Update the Hotspot version numbers in Hotspot
	for JDK 8u60
Message-ID: <54936E4E.8090901@oracle.com>

Can I get a review for this:

8067802 <https://bugs.openjdk.java.net/browse/JDK-8067802>: Update the 
Hotspot version numbers in Hotspot for JDK 8u60

http://cr.openjdk.java.net/~amurillo/8u60/8067802/

Thanks

-- 
Alejandro


From vladimir.kozlov at oracle.com  Fri Dec 19 00:20:56 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Dec 2014 16:20:56 -0800
Subject: [8u60] RFR: 8067802: Update the Hotspot version numbers in Hotspot
	for JDK 8u60
In-Reply-To: <54936E4E.8090901@oracle.com>
References: <54936E4E.8090901@oracle.com>
Message-ID: <54936F68.2070405@oracle.com>

Looks good.

Thanks,
Vladimir

On 12/18/14 4:16 PM, Alejandro E Murillo wrote:
> Can I get a review for this:
>
> 8067802 <https://bugs.openjdk.java.net/browse/JDK-8067802>: Update the
> Hotspot version numbers in Hotspot for JDK 8u60
>
> http://cr.openjdk.java.net/~amurillo/8u60/8067802/
>
> Thanks
>

From alejandro.murillo at oracle.com  Fri Dec 19 00:36:48 2014
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 18 Dec 2014 17:36:48 -0700
Subject: [8u60] RFR: 8067802: Update the Hotspot version numbers in Hotspot
	for JDK 8u60
In-Reply-To: <54936F68.2070405@oracle.com>
References: <54936E4E.8090901@oracle.com> <54936F68.2070405@oracle.com>
Message-ID: <54937320.8070706@oracle.com>


Thanks Vladimir
Alejandro

On 12/18/2014 5:20 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 12/18/14 4:16 PM, Alejandro E Murillo wrote:
>> Can I get a review for this:
>>
>> 8067802 <https://bugs.openjdk.java.net/browse/JDK-8067802>: Update the
>> Hotspot version numbers in Hotspot for JDK 8u60
>>
>> http://cr.openjdk.java.net/~amurillo/8u60/8067802/
>>
>> Thanks
>>

-- 
Alejandro


From david.holmes at oracle.com  Fri Dec 19 00:52:46 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Dec 2014 10:52:46 +1000
Subject: [8u60] RFR: 8035663 Suspicious failure of test
	java/util/concurrent/Phaser/FickleRegister.java
In-Reply-To: <54935FD9.8090508@oracle.com>
References: <5492256F.3060101@oracle.com>
	<54934A72.9030005@oracle.com>	<54935C61.6060405@oracle.com>
	<54935FD9.8090508@oracle.com>
Message-ID: <549376DE.7040201@oracle.com>

Thank you both! Happy Holiday's to you all too.

David

On 19/12/2014 9:14 AM, serguei.spitsyn at oracle.com wrote:
> +1 Including "Happy Holidays!"
>
> Thanks,
> Serguei
>
> On 12/18/14 2:59 PM, Coleen Phillimore wrote:
>>
>> This looks fine.   Happy Holidays!
>> Coleen
>>
>> On 12/18/14, 4:43 PM, David Holmes wrote:
>>> Someone please! I want to get this finalized before I start Xmas
>>> break tomorrow :)
>>>
>>> Thanks,
>>> David
>>>
>>> On 18/12/2014 10:53 AM, David Holmes wrote:
>>>> Please approve the backport of this fix to 8u60 (jdk8u/hs-dev forest).
>>>> The patch from 9 applied cleanly.
>>>>
>>>> Original closed bug: https://bugs.openjdk.java.net/browse/JDK-8035663
>>>> Open backport for 9: https://bugs.openjdk.java.net/browse/JDK-8061564
>>>> JDK 9 changeset:
>>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/478aaf1a3848
>>>>
>>>> webrev for 8u60:
>>>> http://cr.openjdk.java.net/~dholmes/8035663/webrev.8u60/
>>>>
>>>> Thanks,
>>>> David
>>
>

From denis.fokin at gmail.com  Thu Dec 18 13:31:03 2014
From: denis.fokin at gmail.com (Denis Fokin)
Date: Thu, 18 Dec 2014 16:31:03 +0300
Subject: Crash with release_C_heap_structures
Message-ID: <D1E10E36-A896-4EC2-9B4C-7A73092D178A@gmail.com>

Hi,

I see a couple conversations on the list about release_C_heap_structures issues.

I still get a lot of reports about crashes even with early access jdk8u40 on Mac OS X 10.10

Process:               java [53007]
Path: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
Identifier:            net.java.openjdk.cmd
Version:               1.0 (1.0)
Code Type:             X86-64 (Native)
Parent Process:        idea [44131]
Responsible:           idea [44131]
User ID:               503

Thread 8 Crashed:
0   libsystem_kernel.dylib        0x00007fff8e3fe282 __pthread_kill + 10
1   libsystem_c.dylib             0x00007fff9cadfb73 abort + 129
2   libsystem_malloc.dylib        0x00007fff965c9937 free + 428
3   libjvm.dylib                  0x00000001043340d1 InstanceKlass::release_C_heap_structures() + 499
4   libjvm.dylib                  0x000000010433b548 InstanceKlass::deallocate_contents(ClassLoaderData*) + 48
5   libjvm.dylib                  0x0000000104211f28 void MetadataFactory::free_metadata<InstanceKlass*>(ClassLoaderData*, InstanceKlass*) + 69
6   libjvm.dylib                  0x0000000104210f01 ClassLoaderData::free_deallocate_list() + 177
7   libjvm.dylib                  0x0000000104210f97 ClassLoaderDataGraph::do_unloading(BoolObjectClosure*) + 105
8   libjvm.dylib                  0x0000000104599da8 SystemDictionary::do_unloading(BoolObjectClosure*) + 18
9   libjvm.dylib                  0x00000001045265b6 PSParallelCompact::marking_phase(ParCompactionManager*, bool, ParallelOldTracer*) + 1322
10  libjvm.dylib                  0x0000000104527adc PSParallelCompact::invoke_no_policy(bool) + 1108
11  libjvm.dylib                  0x000000010452bdd8 PSScavenge::invoke() + 214
12  libjvm.dylib                  0x0000000104501217 ParallelScavengeHeap::failed_mem_allocate(unsigned long) + 39
13  libjvm.dylib                  0x000000010460f4fe VM_ParallelGCFailedAllocation::doit() + 74
14  libjvm.dylib                  0x0000000104615b05 VM_Operation::evaluate() + 79
15  libjvm.dylib                  0x0000000104614171 VMThread::evaluate_operation(VM_Operation*) + 223
16  libjvm.dylib                  0x00000001046145be VMThread::loop() + 808
17  libjvm.dylib                  0x0000000104613edd VMThread::run() + 121
18  libjvm.dylib                  0x00000001044efa42 java_start(Thread*) + 246
19  libsystem_pthread.dylib       0x00007fff9b0d52fc _pthread_body + 131
20  libsystem_pthread.dylib       0x00007fff9b0d5279 _pthread_start + 176
21  libsystem_pthread.dylib       0x00007fff9b0d34b1 thread_start + 13

Has the issue been resolved at least in jdk9? If not is it something new or a well known issue?

Thank you,
   Denis.

From david.holmes at oracle.com  Fri Dec 19 05:59:44 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Dec 2014 15:59:44 +1000
Subject: Crash with release_C_heap_structures
In-Reply-To: <D1E10E36-A896-4EC2-9B4C-7A73092D178A@gmail.com>
References: <D1E10E36-A896-4EC2-9B4C-7A73092D178A@gmail.com>
Message-ID: <5493BED0.6000401@oracle.com>

Hi Denis,

On 18/12/2014 11:31 PM, Denis Fokin wrote:
> Hi,
>
> I see a couple conversations on the list about release_C_heap_structures issues.
>
> I still get a lot of reports about crashes even with early access jdk8u40 on Mac OS X 10.10
>
> Process:               java [53007]
> Path: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> Identifier:            net.java.openjdk.cmd
> Version:               1.0 (1.0)
> Code Type:             X86-64 (Native)
> Parent Process:        idea [44131]
> Responsible:           idea [44131]
> User ID:               503
>
> Thread 8 Crashed:
> 0   libsystem_kernel.dylib        0x00007fff8e3fe282 __pthread_kill + 10
> 1   libsystem_c.dylib             0x00007fff9cadfb73 abort + 129
> 2   libsystem_malloc.dylib        0x00007fff965c9937 free + 428
> 3   libjvm.dylib                  0x00000001043340d1 InstanceKlass::release_C_heap_structures() + 499
> 4   libjvm.dylib                  0x000000010433b548 InstanceKlass::deallocate_contents(ClassLoaderData*) + 48
> 5   libjvm.dylib                  0x0000000104211f28 void MetadataFactory::free_metadata<InstanceKlass*>(ClassLoaderData*, InstanceKlass*) + 69
> 6   libjvm.dylib                  0x0000000104210f01 ClassLoaderData::free_deallocate_list() + 177
> 7   libjvm.dylib                  0x0000000104210f97 ClassLoaderDataGraph::do_unloading(BoolObjectClosure*) + 105
> 8   libjvm.dylib                  0x0000000104599da8 SystemDictionary::do_unloading(BoolObjectClosure*) + 18
> 9   libjvm.dylib                  0x00000001045265b6 PSParallelCompact::marking_phase(ParCompactionManager*, bool, ParallelOldTracer*) + 1322
> 10  libjvm.dylib                  0x0000000104527adc PSParallelCompact::invoke_no_policy(bool) + 1108
> 11  libjvm.dylib                  0x000000010452bdd8 PSScavenge::invoke() + 214
> 12  libjvm.dylib                  0x0000000104501217 ParallelScavengeHeap::failed_mem_allocate(unsigned long) + 39
> 13  libjvm.dylib                  0x000000010460f4fe VM_ParallelGCFailedAllocation::doit() + 74
> 14  libjvm.dylib                  0x0000000104615b05 VM_Operation::evaluate() + 79
> 15  libjvm.dylib                  0x0000000104614171 VMThread::evaluate_operation(VM_Operation*) + 223
> 16  libjvm.dylib                  0x00000001046145be VMThread::loop() + 808
> 17  libjvm.dylib                  0x0000000104613edd VMThread::run() + 121
> 18  libjvm.dylib                  0x00000001044efa42 java_start(Thread*) + 246
> 19  libsystem_pthread.dylib       0x00007fff9b0d52fc _pthread_body + 131
> 20  libsystem_pthread.dylib       0x00007fff9b0d5279 _pthread_start + 176
> 21  libsystem_pthread.dylib       0x00007fff9b0d34b1 thread_start + 13
>
> Has the issue been resolved at least in jdk9? If not is it something new or a well known issue?

I can't find any bugs reports relating to this, so it seems not to be a 
known issue. google search didn't turn up anything either.

Where has this been seen?

David

> Thank you,
>     Denis.
>

From george.triantafillou at oracle.com  Fri Dec 19 11:54:04 2014
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Fri, 19 Dec 2014 06:54:04 -0500
Subject: [8u60] RFR: 8067802: Update the Hotspot version numbers in Hotspot
	for JDK 8u60
In-Reply-To: <54936E4E.8090901@oracle.com>
References: <54936E4E.8090901@oracle.com>
Message-ID: <549411DC.5010702@oracle.com>

Alejandro,

Looks good.

-George

On 12/18/2014 7:16 PM, Alejandro E Murillo wrote:
> Can I get a review for this:
>
> 8067802 <https://bugs.openjdk.java.net/browse/JDK-8067802>: Update the 
> Hotspot version numbers in Hotspot for JDK 8u60
>
> http://cr.openjdk.java.net/~amurillo/8u60/8067802/
>
> Thanks
>


From coleen.phillimore at oracle.com  Fri Dec 19 12:30:13 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 19 Dec 2014 07:30:13 -0500
Subject: Crash with release_C_heap_structures
In-Reply-To: <5493BED0.6000401@oracle.com>
References: <D1E10E36-A896-4EC2-9B4C-7A73092D178A@gmail.com>
	<5493BED0.6000401@oracle.com>
Message-ID: <54941A55.6040301@oracle.com>


We don't have any reports of crashes in this code currently. Please file 
a bug with (hopefully) directions to reproduce.
Thanks!
Coleen

On 12/19/14, 12:59 AM, David Holmes wrote:
> Hi Denis,
>
> On 18/12/2014 11:31 PM, Denis Fokin wrote:
>> Hi,
>>
>> I see a couple conversations on the list about 
>> release_C_heap_structures issues.
>>
>> I still get a lot of reports about crashes even with early access 
>> jdk8u40 on Mac OS X 10.10
>>
>> Process:               java [53007]
>> Path: 
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
>> Identifier:            net.java.openjdk.cmd
>> Version:               1.0 (1.0)
>> Code Type:             X86-64 (Native)
>> Parent Process:        idea [44131]
>> Responsible:           idea [44131]
>> User ID:               503
>>
>> Thread 8 Crashed:
>> 0   libsystem_kernel.dylib        0x00007fff8e3fe282 __pthread_kill + 10
>> 1   libsystem_c.dylib             0x00007fff9cadfb73 abort + 129
>> 2   libsystem_malloc.dylib        0x00007fff965c9937 free + 428
>> 3   libjvm.dylib                  0x00000001043340d1 
>> InstanceKlass::release_C_heap_structures() + 499
>> 4   libjvm.dylib                  0x000000010433b548 
>> InstanceKlass::deallocate_contents(ClassLoaderData*) + 48
>> 5   libjvm.dylib                  0x0000000104211f28 void 
>> MetadataFactory::free_metadata<InstanceKlass*>(ClassLoaderData*, 
>> InstanceKlass*) + 69
>> 6   libjvm.dylib                  0x0000000104210f01 
>> ClassLoaderData::free_deallocate_list() + 177
>> 7   libjvm.dylib                  0x0000000104210f97 
>> ClassLoaderDataGraph::do_unloading(BoolObjectClosure*) + 105
>> 8   libjvm.dylib                  0x0000000104599da8 
>> SystemDictionary::do_unloading(BoolObjectClosure*) + 18
>> 9   libjvm.dylib                  0x00000001045265b6 
>> PSParallelCompact::marking_phase(ParCompactionManager*, bool, 
>> ParallelOldTracer*) + 1322
>> 10  libjvm.dylib                  0x0000000104527adc 
>> PSParallelCompact::invoke_no_policy(bool) + 1108
>> 11  libjvm.dylib                  0x000000010452bdd8 
>> PSScavenge::invoke() + 214
>> 12  libjvm.dylib                  0x0000000104501217 
>> ParallelScavengeHeap::failed_mem_allocate(unsigned long) + 39
>> 13  libjvm.dylib                  0x000000010460f4fe 
>> VM_ParallelGCFailedAllocation::doit() + 74
>> 14  libjvm.dylib                  0x0000000104615b05 
>> VM_Operation::evaluate() + 79
>> 15  libjvm.dylib                  0x0000000104614171 
>> VMThread::evaluate_operation(VM_Operation*) + 223
>> 16  libjvm.dylib                  0x00000001046145be VMThread::loop() 
>> + 808
>> 17  libjvm.dylib                  0x0000000104613edd VMThread::run() 
>> + 121
>> 18  libjvm.dylib                  0x00000001044efa42 
>> java_start(Thread*) + 246
>> 19  libsystem_pthread.dylib       0x00007fff9b0d52fc _pthread_body + 131
>> 20  libsystem_pthread.dylib       0x00007fff9b0d5279 _pthread_start + 
>> 176
>> 21  libsystem_pthread.dylib       0x00007fff9b0d34b1 thread_start + 13
>>
>> Has the issue been resolved at least in jdk9? If not is it something 
>> new or a well known issue?
>
> I can't find any bugs reports relating to this, so it seems not to be 
> a known issue. google search didn't turn up anything either.
>
> Where has this been seen?
>
> David
>
>> Thank you,
>>     Denis.
>>


From jesper.wilhelmsson at oracle.com  Fri Dec 19 14:41:41 2014
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 19 Dec 2014 15:41:41 +0100
Subject: Patch for a type in globalDefinitions_gcc.cpp
In-Reply-To: <547F6742-0C4D-4DE4-B29D-6BA9C9A2ECF0@icloud.com>
References: <547F6742-0C4D-4DE4-B29D-6BA9C9A2ECF0@icloud.com>
Message-ID: <54943925.8010603@oracle.com>

Hi Alex,

If we for some reason think it is too much work or takes too much time to fix 
the small things that bothers us in the code, we have a problem in our 
development model that needs to be fixed asap. If I had found this typo I would 
have fixed it.

Please provide a patch and I will happily sponsor it.
/Jesper


Alex Yursha skrev 18/12/14 13:14:
> Hi all!
>
> I don?t know if its reasonable to spend time on this but just in case decided to submit a patch. There is a typo in *constant* vs *canstant* in a comment.
>
> Thanks
>
>

From volker.simonis at gmail.com  Fri Dec 19 14:45:27 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 19 Dec 2014 15:45:27 +0100
Subject: 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols
	at build time and suppress warning 1540-1639
Message-ID: <CA+3eh11yVzFM0L5uUqqmMN5KXTR7DJVV=6eU9vk_vuSNEJmfGQ@mail.gmail.com>

Hi,

can somebody please review this tiny, AIX-only build changes:

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

'-bernotok' is the AIX linkers equivalent to Linux ld's '-z defs'.

It's better to detect missing symbols already at build time.

Also supress the warning "1540-1639 (I) The behavior of long type bit
fields has changed from previous releases of this compiler. In 64-bit
mode, long type bit fields now default to long, not int."

The warning is only informational (i.e. "(I)") but very annoying
because it is printed for the bit-fields in
"src/share/vm/services/mallocTracker.hpp" which is included in
virtually every compilation unit.

Thanks,
Volker

From filipp.zhinkin at oracle.com  Fri Dec 19 14:59:02 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Fri, 19 Dec 2014 18:59:02 +0400
Subject: [8u40] Request for approval to backport JDK-8037968 and JDK-8066143
Message-ID: <54943D36.2080001@oracle.com>

Hi,

please approve backport of following test-only fixes into 8u40:

JDK-8037968 Add tests on alignment of objects copied to survivor space:

Bug-id: https://bugs.openjdk.java.net/browse/JDK-8037968
Original review thread: 
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011405.html
Original changeset: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/c196aca52cab


JDK-8066143 [TESTBUG] New tests in gc/survivorAlignment/ fails

Bug-id: https://bugs.openjdk.java.net/browse/JDK-8066143
Original review thread: 
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011573.html
Original changeset: http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3c17077e9882


Fix for 8037968 applied with fuzz, but without any changes. Do I need to create 
a new patch for it?
Fix for 8066143 applied cleanly without any changes.

I've tested these tests after both fixes were applied, no issues were found.

Thanks,
Filipp.

From aph at redhat.com  Fri Dec 19 15:48:07 2014
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Dec 2014 15:48:07 +0000
Subject: [aarch64-port-dev ] What now?
Message-ID: <549448B7.209@redhat.com>

How would you like to proceed?  We have only the os_cpu and cpu/
directories to go, and they are fairly stable now.  I have one other
patch, which provides support for the serviceability agent, but I don't
think that makes any sense before the port itself is in.

I'm not sure it makes any sense to submit the port in pieces, since
none of the parts make much sense on their own.  I can just submit one
huge webrev, but that's not very nice...

Thanks
Andrew.

From goetz.lindenmaier at sap.com  Fri Dec 19 15:50:19 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 19 Dec 2014 15:50:19 +0000
Subject: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws
	RuntimeException
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF43365@DEWDFEMB12A.global.corp.sap>

Hi,

Please review this tiny change.  I please need a sponsor.
http://cr.openjdk.java.net/~goetz/webrevs/8067823-client/webrev.01/

The check that tiered compilation is not supported also checked that it's a client vm.
This is too strict.

Thanks and best regards,
  Goetz.



From goetz.lindenmaier at sap.com  Fri Dec 19 16:05:34 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 19 Dec 2014 16:05:34 +0000
Subject: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF43388@DEWDFEMB12A.global.corp.sap>

Hi,

please review this simple change.  I please need a sponsor.
The change should be downported to 8u60.  It applies nicely except
for some missing files.
http://cr.openjdk.java.net/~goetz/webrevs/8067941-64K/webrev.01/

The issue is that we have linux ppc64 machines that have default page size
of 64K.  This imposes bigger limits on stack and heap sizes than if running
with 4k pages.
Ergonomics increase some flags if they are too small.
Increasing the sizes used in the test slightly helps in most cases.  Details:

runtime/whitebox/WBStackSize.java
  The constant esimating the so far occupied stack is too small. Fix: Consider size of shadow pages

compiler/uncommontrap/TestStackBangRbp.java:
compiler/uncommontrap/TestStackBangMonitorOwned.java
compiler/uncommontrap/StackOverflowGuardPagesOff.java
compiler/uncommontrap/8009761/Test8009761.java
compiler/runtime/6865265/StackOverflowBug.java
compiler/exceptions/TestRecursiveReplacedException.java
Increase stack size to 392K, need at least 328K.

sanity/ExecuteInternalVMTests.java
- Assertion in metaspace.cpp simly must fail with vm_page_size == 64K as it
   basically asserts vm_page_size < 16K
- With 64K pages, heap sizes are computed differently starting from the alignment
   which is card_size * vm_page_size.

gc/arguments/TestMaxHeapSizeTools.java
  Sizes are alinged up being equal in the end. Choose bigger sizes.

gc/g1/TestHumongousAllocInitialMark.java
  Test computes some size based on the -Xmx value it uses.  Heap size is increased slightly
  with 64K making the computation wrong and the test fail. Choose heap size that needs not
  be aligned.

gc/g1/TestGCLogMessages.java
  Heap of 10M is increased to 32M because of the alignment with 64K pages.
  This makes the evacuation succeed. Choose 32M from the beginning and adapt
  size of huge object.

Best regards,
  Goetz.

From goetz.lindenmaier at sap.com  Fri Dec 19 16:11:36 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 19 Dec 2014 16:11:36 +0000
Subject: 8067923: AIX: link libjvm.so with -bernotok to detect missing
	symbols	at build time and suppress warning 1540-1639
In-Reply-To: <CA+3eh11yVzFM0L5uUqqmMN5KXTR7DJVV=6eU9vk_vuSNEJmfGQ@mail.gmail.com>
References: <CA+3eh11yVzFM0L5uUqqmMN5KXTR7DJVV=6eU9vk_vuSNEJmfGQ@mail.gmail.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF43399@DEWDFEMB12A.global.corp.sap>

Hi Volker, 

it's good to fix these two issues, thanks!
The patch works nicely.

Best regards,
  Goetz.


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis
Sent: Freitag, 19. Dezember 2014 15:45
To: HotSpot Open Source Developers; ppc-aix-port-dev at openjdk.java.net
Subject: 8067923: AIX: link libjvm.so with -bernotok to detect missing symbols at build time and suppress warning 1540-1639

Hi,

can somebody please review this tiny, AIX-only build changes:

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

'-bernotok' is the AIX linkers equivalent to Linux ld's '-z defs'.

It's better to detect missing symbols already at build time.

Also supress the warning "1540-1639 (I) The behavior of long type bit
fields has changed from previous releases of this compiler. In 64-bit
mode, long type bit fields now default to long, not int."

The warning is only informational (i.e. "(I)") but very annoying
because it is printed for the bit-fields in
"src/share/vm/services/mallocTracker.hpp" which is included in
virtually every compilation unit.

Thanks,
Volker

From volker.simonis at gmail.com  Fri Dec 19 17:30:11 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 19 Dec 2014 18:30:11 +0100
Subject: RFR: 8067790: Better support for native implementations of
	Atomic::cmpxchg
In-Reply-To: <0F0D9F35-148D-4C62-8065-7E58F5EC76D1@lnu.se>
References: <0F0D9F35-148D-4C62-8065-7E58F5EC76D1@lnu.se>
Message-ID: <CA+3eh11T5jceh9tcqjtij5226eHAqm3-KXWoeNky-EpLjHhfpg@mail.gmail.com>

Hi Erik,

nice change (did I mention already that I LOVE template metaprogramming :)

first some minor layout stuff:

- some of your file contain trailing white space (mostly in empty
lines). Running jcheck on your change reports:

src/os_cpu/bsd_x86/vm/atomic_bsd_x86.hpp:33: Trailing whitespace
src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp:33: Trailing whitespace
src/os_cpu/solaris_x86/vm/atomic_solaris_x86.hpp:33: Trailing whitespace
src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp:33: Trailing whitespace
src/share/vm/utilities/traits/isBaseOf.cpp:32: Trailing whitespace
src/share/vm/utilities/traits/isBaseOf.hpp:63: Trailing whitespace
src/share/vm/utilities/traits/isClassOrUnion.hpp:35: Trailing whitespace
src/share/vm/utilities/traits/isSame.cpp:89: Trailing whitespace
src/share/vm/utilities/traits/selectBaseClass.hpp:39: Trailing whitespace

Could you please fix these lines and make your change 'jcheck'-safe.

- all your test functions are static except
IsBaseOfAndDerivedTest::test()  in isBaseOf.cpp. I understand that it
is not strictly necessary but for symmetric reasons you could make it
static as well.

- your test are elegant and I like them. However I wonder how we can
be sure that the compiler really instantiates all the templates. I can
see that there's no code created for the test functions in the object
files (which is fine). But how can we be sure that they are relly
compiled? Do you have any insights here? (By the way, I noticed that
if a insert a wrong STATIC_ASSERT I get a compile time warning, so
your tests work in general. I only wonder if they really work always
or if a smart compiler can just figure out that he doesn't need to
compile them?)

 - have you also done some performance checks (i.e. is the templatized
version really as fast as the one with macros?)

Following some additional platform/compiler checks (just in case
somebody is interested):

 - doesn?t compile with aCC A.03.73 on HP UX 11.11 / PARISC (SIGSEGV
in compiler)
 - compiles with aCC A.03.95.01 on HP UX 11.31 / PARISC (with
+hpxstd98, without +hpxstd98 SIGSEGV in compiler)

 - compiles with aCC A.06.16.01 on HP UX 11.23 / IA64

 - compiles with g++ 4.1.2 on Linux/ppc64

 - compiles with xlc 10.1 on AIX 5.3
 - compiles with xlC 12.01 on AIX 7.1

Regards,
Volker

On Wed, Dec 17, 2014 at 5:38 PM, Erik ?sterlund <erik.osterlund at lnu.se> wrote:
> Hi all,
>
> Previously, jbyte Atomic::cmpxchg had one general implementation for all platforms. A macro based solution was introduced, adding specialized implementation for the x86 platforms without changing code for the ports for other architectures, making the specialization optional (from ).
>
> However, macros are not very nice and this new fix gets rid of the macros and replaces it with a cleaner solution using inheritance and templates. The core idea is simple: split the Atomic class into three layers of inheritance.
>
> 1. AtomicBase is the base class where general operations for all platforms should go, now it contains the general implementation for jbyte cmpxchg, but in the future other similar methods are welcome too.
> 2. AtomicPlatform is an optional class that a platform can define, but does not have to (and hence does not break existing ports), allowing specialized variants to override the behaviour of AtomicBase. Now it contains the specialized platform dependent x86 variants of jbyte cmpxchg.
> 3. Atomic is the fascade of all atomics as expected. Its jbyte cmpxchg implementation simply forwards to its super class AtomicSuper which is either AtomicBase or AtomicPlatform if provided for the specific platform.
>
> All in all, it?s based on simple inheritance with the twist that the AtomicPlatform part is optional. This is allowed using some C++ metaprogramming idioms. Concretely, a trait was implemented called SelectBaseClass that allows you to specify the desired base class, and another one to fall back to in case the desired base class was not defined (forward declaration). The super class of Atomic is hence defined as:
>
> typedef SelectBaseClass<AtomicPlatform, AtomicBase>::type AtomicSuper;
>
> To implement this trait, an equivalent variant of the C++11/boost is_base_of trait was implemented, called IsBaseOf to follow our naming conventions. It is very similar to the standard version but works on all of our compilers. The only difference so far between IsBaseOf and is_base_of is that IsBaseOf will return true when comparing two unions that are the same, while is_base_of will not. The reason for this is that I found no portable way of detecting unions. A bunch of dependent traits were implemented too, and it can all be found in utilities/traits/ since I like reasonably fine grained headers. All these traits are built to be reusable and perhaps we will have more uses for metaprogramming in the future where this comes in handy. The intended behaviour and contract of the traits are documented in comments.
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8067790
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8067790/webrev.00/
>
> In summary this allows us to get rid of the ugly macro used before and provide a better general mechanism for having generalized and specialized atomics without breaking existing ports for those platforms that do not need it. And hopefully the metaprogramming tools will come in useful in the future for perhaps similar situations.
>
> Testing:
> * All new traits have test cases using STATIC_ASSERT nailing down the intended behaviour and contract also reflected in the comments.
> * The changes passed the jprt testing ok. (Thanks to Jesper for running it!)
>
> Thanks,
> /Erik

From volker.simonis at gmail.com  Fri Dec 19 17:44:56 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 19 Dec 2014 18:44:56 +0100
Subject: RFR (XXS): 8067865 : Changes 8066780/8066782 broke the non-PCH
	build
In-Reply-To: <CA+3eh10JZYcSc2UBfzR7MRfs98jx4=90AhZL7Su3C5j6sLvkNg@mail.gmail.com>
References: <CA+3eh10JZYcSc2UBfzR7MRfs98jx4=90AhZL7Su3C5j6sLvkNg@mail.gmail.com>
Message-ID: <CA+3eh12A+OGLKA2NTBbqBbBnxKn82r+WdDa709uttBNF5QZArw@mail.gmail.com>

Hi,

could somebody please have a quick look at this fix and sponsor it?
It breaks our AIX build.

Thank you and best regards,
Volker


On Thu, Dec 18, 2014 at 5:31 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> could sombody please review and sponsor this little change which fixes
> the build on AIX after 8066780/8066782:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8067865
> https://bugs.openjdk.java.net/browse/JDK-8067865
>
> Here's the full story: 8066780/8066782 did some code refactoring and
> introduced the new files cardGeneration.{hpp,cpp,inline.hpp}.
> Unfortunately, the changes forgot to include cardGeneration.inline.hpp
> into tenuredGeneration.cpp and concurrentMarkSweepGeneration.cpp which
> use the methods defined therein.
>
> This problem doesn't show up on Linux (even if build with
> '--disable-precompiled-headers') because for some reason GCC places
> weak references of the corresponding symbols in cardGeneration.o. So
> later when linking libjvm.so the references can still be resolved. Sun
> Studio also places global instantiations of the corresponding inline
> functions into cardGeneration.o so we don't see any problems there as
> well.
>
> xlC on AIX only puts a locally visible reference of the neede inline
> functions into cardGeneration.o if he can't inline them (which is
> perfectly legal because they are declared 'inline'). However, later
> one during linking no globally visible versions of the corresponding
> inline functions can be found and the link fails.
>
> The final fix is trivial - just include the corresponding
> cardGeneration.inline.hpp file into the .cpp files which require its
> method definitions.
>
> Thank you and best regards,
> Volker

From vladimir.kozlov at oracle.com  Fri Dec 19 17:54:58 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Dec 2014 09:54:58 -0800
Subject: 8067923: AIX: link libjvm.so with -bernotok to detect missing
	symbols at build time and suppress warning 1540-1639
In-Reply-To: <CA+3eh11yVzFM0L5uUqqmMN5KXTR7DJVV=6eU9vk_vuSNEJmfGQ@mail.gmail.com>
References: <CA+3eh11yVzFM0L5uUqqmMN5KXTR7DJVV=6eU9vk_vuSNEJmfGQ@mail.gmail.com>
Message-ID: <54946672.2090109@oracle.com>

Looks good.

Thanks,
Vladimir

On 12/19/14 6:45 AM, Volker Simonis wrote:
> Hi,
>
> can somebody please review this tiny, AIX-only build changes:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8067923
> https://bugs.openjdk.java.net/browse/JDK-8067923
>
> '-bernotok' is the AIX linkers equivalent to Linux ld's '-z defs'.
>
> It's better to detect missing symbols already at build time.
>
> Also supress the warning "1540-1639 (I) The behavior of long type bit
> fields has changed from previous releases of this compiler. In 64-bit
> mode, long type bit fields now default to long, not int."
>
> The warning is only informational (i.e. "(I)") but very annoying
> because it is printed for the bit-fields in
> "src/share/vm/services/mallocTracker.hpp" which is included in
> virtually every compilation unit.
>
> Thanks,
> Volker
>

From vladimir.kozlov at oracle.com  Fri Dec 19 17:57:41 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Dec 2014 09:57:41 -0800
Subject: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws
	RuntimeException
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF43365@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF43365@DEWDFEMB12A.global.corp.sap>
Message-ID: <54946715.9000006@oracle.com>

Looks good.

Thanks,
Vladimir

On 12/19/14 7:50 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> Please review this tiny change.  I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/webrevs/8067823-client/webrev.01/
>
> The check that tiered compilation is not supported also checked that it's a client vm.
> This is too strict.
>
> Thanks and best regards,
>    Goetz.
>
>

From igor.ignatyev at oracle.com  Fri Dec 19 18:00:16 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 19 Dec 2014 21:00:16 +0300
Subject: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws
	RuntimeException
In-Reply-To: <54946715.9000006@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF43365@DEWDFEMB12A.global.corp.sap>
	<54946715.9000006@oracle.com>
Message-ID: <549467B0.2000300@oracle.com>

looks good to me.

Thanks,
Igor

On 12/19/2014 08:57 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 12/19/14 7:50 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> Please review this tiny change.  I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/webrevs/8067823-client/webrev.01/
>>
>> The check that tiered compilation is not supported also checked that
>> it's a client vm.
>> This is too strict.
>>
>> Thanks and best regards,
>>    Goetz.
>>
>>

From vladimir.kozlov at oracle.com  Fri Dec 19 18:02:57 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Dec 2014 10:02:57 -0800
Subject: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF43388@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF43388@DEWDFEMB12A.global.corp.sap>
Message-ID: <54946851.2050107@oracle.com>

I agree with compiler tests changes. Other groups should review changes 
in their files.

You accidentally included 8067823 in CheckCompileThresholdScaling.java

Thanks,
Vladimir

On 12/19/14 8:05 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review this simple change.  I please need a sponsor.
> The change should be downported to 8u60.  It applies nicely except
> for some missing files.
> http://cr.openjdk.java.net/~goetz/webrevs/8067941-64K/webrev.01/
>
> The issue is that we have linux ppc64 machines that have default page size
> of 64K.  This imposes bigger limits on stack and heap sizes than if running
> with 4k pages.
> Ergonomics increase some flags if they are too small.
> Increasing the sizes used in the test slightly helps in most cases.  Details:
>
> runtime/whitebox/WBStackSize.java
>    The constant esimating the so far occupied stack is too small. Fix: Consider size of shadow pages
>
> compiler/uncommontrap/TestStackBangRbp.java:
> compiler/uncommontrap/TestStackBangMonitorOwned.java
> compiler/uncommontrap/StackOverflowGuardPagesOff.java
> compiler/uncommontrap/8009761/Test8009761.java
> compiler/runtime/6865265/StackOverflowBug.java
> compiler/exceptions/TestRecursiveReplacedException.java
> Increase stack size to 392K, need at least 328K.
>
> sanity/ExecuteInternalVMTests.java
> - Assertion in metaspace.cpp simly must fail with vm_page_size == 64K as it
>     basically asserts vm_page_size < 16K
> - With 64K pages, heap sizes are computed differently starting from the alignment
>     which is card_size * vm_page_size.
>
> gc/arguments/TestMaxHeapSizeTools.java
>    Sizes are alinged up being equal in the end. Choose bigger sizes.
>
> gc/g1/TestHumongousAllocInitialMark.java
>    Test computes some size based on the -Xmx value it uses.  Heap size is increased slightly
>    with 64K making the computation wrong and the test fail. Choose heap size that needs not
>    be aligned.
>
> gc/g1/TestGCLogMessages.java
>    Heap of 10M is increased to 32M because of the alignment with 64K pages.
>    This makes the evacuation succeed. Choose 32M from the beginning and adapt
>    size of huge object.
>
> Best regards,
>    Goetz.
>

From vladimir.kozlov at oracle.com  Fri Dec 19 18:16:08 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Dec 2014 10:16:08 -0800
Subject: RFR (XXS): 8067865 : Changes 8066780/8066782 broke the non-PCH
	build
In-Reply-To: <CA+3eh12A+OGLKA2NTBbqBbBnxKn82r+WdDa709uttBNF5QZArw@mail.gmail.com>
References: <CA+3eh10JZYcSc2UBfzR7MRfs98jx4=90AhZL7Su3C5j6sLvkNg@mail.gmail.com>
	<CA+3eh12A+OGLKA2NTBbqBbBnxKn82r+WdDa709uttBNF5QZArw@mail.gmail.com>
Message-ID: <54946B68.6070708@oracle.com>

Looks fine. Where do you want it to be pushed?

Thanks,
Vladimir

On 12/19/14 9:44 AM, Volker Simonis wrote:
> Hi,
>
> could somebody please have a quick look at this fix and sponsor it?
> It breaks our AIX build.
>
> Thank you and best regards,
> Volker
>
>
> On Thu, Dec 18, 2014 at 5:31 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> could sombody please review and sponsor this little change which fixes
>> the build on AIX after 8066780/8066782:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/8067865
>> https://bugs.openjdk.java.net/browse/JDK-8067865
>>
>> Here's the full story: 8066780/8066782 did some code refactoring and
>> introduced the new files cardGeneration.{hpp,cpp,inline.hpp}.
>> Unfortunately, the changes forgot to include cardGeneration.inline.hpp
>> into tenuredGeneration.cpp and concurrentMarkSweepGeneration.cpp which
>> use the methods defined therein.
>>
>> This problem doesn't show up on Linux (even if build with
>> '--disable-precompiled-headers') because for some reason GCC places
>> weak references of the corresponding symbols in cardGeneration.o. So
>> later when linking libjvm.so the references can still be resolved. Sun
>> Studio also places global instantiations of the corresponding inline
>> functions into cardGeneration.o so we don't see any problems there as
>> well.
>>
>> xlC on AIX only puts a locally visible reference of the neede inline
>> functions into cardGeneration.o if he can't inline them (which is
>> perfectly legal because they are declared 'inline'). However, later
>> one during linking no globally visible versions of the corresponding
>> inline functions can be found and the link fails.
>>
>> The final fix is trivial - just include the corresponding
>> cardGeneration.inline.hpp file into the .cpp files which require its
>> method definitions.
>>
>> Thank you and best regards,
>> Volker

From erik.osterlund at lnu.se  Fri Dec 19 18:51:59 2014
From: erik.osterlund at lnu.se (=?utf-8?B?RXJpayDDlnN0ZXJsdW5k?=)
Date: Fri, 19 Dec 2014 18:51:59 +0000
Subject: RFR: 8067790: Better support for native implementations of
	Atomic::cmpxchg
In-Reply-To: <CA+3eh11T5jceh9tcqjtij5226eHAqm3-KXWoeNky-EpLjHhfpg@mail.gmail.com>
References: <0F0D9F35-148D-4C62-8065-7E58F5EC76D1@lnu.se>
	<CA+3eh11T5jceh9tcqjtij5226eHAqm3-KXWoeNky-EpLjHhfpg@mail.gmail.com>
Message-ID: <0C90C9DB-1ED8-4AFF-A6D4-8035D323E95C@lnu.se>

Hi Volker,

Thank you for reviewing this change!

> On 19 Dec 2014, at 17:30, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi Erik,
> 
> nice change (did I mention already that I LOVE template metaprogramming :)

I?m glad there are more people supporting template metaprogramming for solving architectural problems! :)

> first some minor layout stuff:
> 
> - some of your file contain trailing white space (mostly in empty
> lines). Running jcheck on your change reports:
> 
> src/os_cpu/bsd_x86/vm/atomic_bsd_x86.hpp:33: Trailing whitespace
> src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp:33: Trailing whitespace
> src/os_cpu/solaris_x86/vm/atomic_solaris_x86.hpp:33: Trailing whitespace
> src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp:33: Trailing whitespace
> src/share/vm/utilities/traits/isBaseOf.cpp:32: Trailing whitespace
> src/share/vm/utilities/traits/isBaseOf.hpp:63: Trailing whitespace
> src/share/vm/utilities/traits/isClassOrUnion.hpp:35: Trailing whitespace
> src/share/vm/utilities/traits/isSame.cpp:89: Trailing whitespace
> src/share/vm/utilities/traits/selectBaseClass.hpp:39: Trailing whitespace
> 
> Could you please fix these lines and make your change 'jcheck'-safe.
> 

Oh snap, that vimscript to for removing trailing whitespaces on save seems to have been disabled. :/ Fixed.

> - all your test functions are static except
> IsBaseOfAndDerivedTest::test()  in isBaseOf.cpp. I understand that it
> is not strictly necessary but for symmetric reasons you could make it
> static as well.

Sure, fixed.

> - your test are elegant and I like them. However I wonder how we can
> be sure that the compiler really instantiates all the templates. I can
> see that there's no code created for the test functions in the object
> files (which is fine). But how can we be sure that they are relly
> compiled? Do you have any insights here? (By the way, I noticed that
> if a insert a wrong STATIC_ASSERT I get a compile time warning, so
> your tests work in general. I only wonder if they really work always
> or if a smart compiler can just figure out that he doesn't need to
> compile them?)

Optimizations such as dead code elimination within a compilation unit are performed after template instantiation because before template instantiation, it?s impossible to know what the code does and hence if it is dead code or not. Therefore, I?m pretty certain that STATIC_ASSERT will always fail before finding out that the code is not needed. And cross object-file optimizations can be done at link time, but the STATIC_ASSERT will trigger way before linking. Therefore I would be very surprised if this style of testing does not work for all compilers.

> - have you also done some performance checks (i.e. is the templatized
> version really as fast as the one with macros?)

I did by running DaCapo benchmarks using G1 (which uses this for manipulating cards), and there was no visible difference. Not surprising considering it?s all explicitly inlined as before.

> Following some additional platform/compiler checks (just in case
> somebody is interested):
> 
> - doesn?t compile with aCC A.03.73 on HP UX 11.11 / PARISC (SIGSEGV
> in compiler)
> - compiles with aCC A.03.95.01 on HP UX 11.31 / PARISC (with
> +hpxstd98, without +hpxstd98 SIGSEGV in compiler)
> 
> - compiles with aCC A.06.16.01 on HP UX 11.23 / IA64
> 
> - compiles with g++ 4.1.2 on Linux/ppc64
> 
> - compiles with xlc 10.1 on AIX 5.3
> - compiles with xlC 12.01 on AIX 7.1

Very interesting! :)
Do you want a new webrev to see that the trailing whitespaces have been removed and IsBaseOfAndDerivedTest::test was made static?

Thanks,
Erik

> 
> Regards,
> Volker
> 
> On Wed, Dec 17, 2014 at 5:38 PM, Erik ?sterlund <erik.osterlund at lnu.se> wrote:
>> Hi all,
>> 
>> Previously, jbyte Atomic::cmpxchg had one general implementation for all platforms. A macro based solution was introduced, adding specialized implementation for the x86 platforms without changing code for the ports for other architectures, making the specialization optional (from ).
>> 
>> However, macros are not very nice and this new fix gets rid of the macros and replaces it with a cleaner solution using inheritance and templates. The core idea is simple: split the Atomic class into three layers of inheritance.
>> 
>> 1. AtomicBase is the base class where general operations for all platforms should go, now it contains the general implementation for jbyte cmpxchg, but in the future other similar methods are welcome too.
>> 2. AtomicPlatform is an optional class that a platform can define, but does not have to (and hence does not break existing ports), allowing specialized variants to override the behaviour of AtomicBase. Now it contains the specialized platform dependent x86 variants of jbyte cmpxchg.
>> 3. Atomic is the fascade of all atomics as expected. Its jbyte cmpxchg implementation simply forwards to its super class AtomicSuper which is either AtomicBase or AtomicPlatform if provided for the specific platform.
>> 
>> All in all, it?s based on simple inheritance with the twist that the AtomicPlatform part is optional. This is allowed using some C++ metaprogramming idioms. Concretely, a trait was implemented called SelectBaseClass that allows you to specify the desired base class, and another one to fall back to in case the desired base class was not defined (forward declaration). The super class of Atomic is hence defined as:
>> 
>> typedef SelectBaseClass<AtomicPlatform, AtomicBase>::type AtomicSuper;
>> 
>> To implement this trait, an equivalent variant of the C++11/boost is_base_of trait was implemented, called IsBaseOf to follow our naming conventions. It is very similar to the standard version but works on all of our compilers. The only difference so far between IsBaseOf and is_base_of is that IsBaseOf will return true when comparing two unions that are the same, while is_base_of will not. The reason for this is that I found no portable way of detecting unions. A bunch of dependent traits were implemented too, and it can all be found in utilities/traits/ since I like reasonably fine grained headers. All these traits are built to be reusable and perhaps we will have more uses for metaprogramming in the future where this comes in handy. The intended behaviour and contract of the traits are documented in comments.
>> 
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8067790
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8067790/webrev.00/
>> 
>> In summary this allows us to get rid of the ugly macro used before and provide a better general mechanism for having generalized and specialized atomics without breaking existing ports for those platforms that do not need it. And hopefully the metaprogramming tools will come in useful in the future for perhaps similar situations.
>> 
>> Testing:
>> * All new traits have test cases using STATIC_ASSERT nailing down the intended behaviour and contract also reflected in the comments.
>> * The changes passed the jprt testing ok. (Thanks to Jesper for running it!)
>> 
>> Thanks,
>> /Erik


From paul.hohensee at gmail.com  Fri Dec 19 21:08:23 2014
From: paul.hohensee at gmail.com (Paul Hohensee)
Date: Fri, 19 Dec 2014 16:08:23 -0500
Subject: RFR: 8067790: Better support for native implementations of
	Atomic::cmpxchg
Message-ID: <CAAsuuZdsfWZQNgigwe3xMG7bzKrSzTonwfqa3TzFPA6uuwU3kA@mail.gmail.com>

Looks good to me, but then I reviewed it awhile back. :)

Paul

On Wed, Dec 17, 2014 at 5:38 PM, Erik ?sterlund <erik.osterlund at lnu.se>
wrote:
> Hi all,
>
> Previously, jbyte Atomic::cmpxchg had one general implementation for all
platforms. A macro based solution was introduced, adding specialized
implementation for the x86 platforms without changing code for the ports
for other architectures, making the specialization optional (from ).
>
> However, macros are not very nice and this new fix gets rid of the macros
and replaces it with a cleaner solution using inheritance and templates.
The core idea is simple: split the Atomic class into three layers of
inheritance.
>
> 1. AtomicBase is the base class where general operations for all
platforms should go, now it contains the general implementation for jbyte
cmpxchg, but in the future other similar methods are welcome too.
> 2. AtomicPlatform is an optional class that a platform can define, but
does not have to (and hence does not break existing ports), allowing
specialized variants to override the behaviour of AtomicBase. Now it
contains the specialized platform dependent x86 variants of jbyte cmpxchg.
> 3. Atomic is the fascade of all atomics as expected. Its jbyte cmpxchg
implementation simply forwards to its super class AtomicSuper which is
either AtomicBase or AtomicPlatform if provided for the specific platform.
>
> All in all, it?s based on simple inheritance with the twist that the
AtomicPlatform part is optional. This is allowed using some C++
metaprogramming idioms. Concretely, a trait was implemented called
SelectBaseClass that allows you to specify the desired base class, and
another one to fall back to in case the desired base class was not defined
(forward declaration). The super class of Atomic is hence defined as:
>
> typedef SelectBaseClass<
AtomicPlatform, AtomicBase>::type AtomicSuper;
>
> To implement this trait, an equivalent variant of the C++11/boost
is_base_of trait was implemented, called IsBaseOf to follow our naming
conventions. It is very similar to the standard version but works on all of
our compilers. The only difference so far between IsBaseOf and is_base_of
is that IsBaseOf will return true when comparing two unions that are the
same, while is_base_of will not. The reason for this is that I found no
portable way of detecting unions. A bunch of dependent traits were
implemented too, and it can all be found in utilities/traits/ since I like
reasonably fine grained headers. All these traits are built to be reusable
and perhaps we will have more uses for metaprogramming in the future where
this comes in handy. The intended behaviour and contract of the traits are
documented in comments.
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8067790
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8067790/webrev.00/
>
> In summary this allows us to get rid of the ugly macro used before and
provide a better general mechanism for having generalized and specialized
atomics without breaking existing ports for those platforms that do not
need it. And hopefully the metaprogramming tools will come in useful in the
future for perhaps similar situations.
>
> Testing:
> * All new traits have test cases using STATIC_ASSERT nailing down the
intended behaviour and contract also reflected in the comments.
> * The changes passed the jprt testing ok. (Thanks to Jesper for running
it!)
>
> Thanks,
> /Erik

From aph at redhat.com  Fri Dec 19 15:44:17 2014
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Dec 2014 15:44:17 +0000
Subject: What now?
Message-ID: <549447D1.6020206@redhat.com>

How would you like to proceed?  We have only the os_cpu and cpu/
directories to go, and they are fairly stable now.  I have one other
patch, which provides support for the serviceability agent, but I don't
think that makes any sense before the port itself is in.

I'm not sure it makes any sense to submit the port in pieces, since
none of the parts make much sense on their own.  I can just submit one
huge webrev, but that's not very nice...

Thanks
Andrew.

From volker.simonis at gmail.com  Sat Dec 20 08:03:37 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sat, 20 Dec 2014 09:03:37 +0100
Subject: RFR (XXS): 8067865 : Changes 8066780/8066782 broke the non-PCH
	build
In-Reply-To: <54946B68.6070708@oracle.com>
References: <CA+3eh10JZYcSc2UBfzR7MRfs98jx4=90AhZL7Su3C5j6sLvkNg@mail.gmail.com>
	<CA+3eh12A+OGLKA2NTBbqBbBnxKn82r+WdDa709uttBNF5QZArw@mail.gmail.com>
	<54946B68.6070708@oracle.com>
Message-ID: <CA+3eh124Mxak=44ii5NT-BBjbfpZ=BFLi_DkpRrdSSuWhYHF5w@mail.gmail.com>

Hi Vladimir,

would be nice if you could push it to that hs repository which gets synced
next with jdk9/dev.
And it must already have the changes 8066780/8066782.

Other than that I don't have any preferences.

Thanks again,
Volker


On Friday, December 19, 2014, Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Looks fine. Where do you want it to be pushed?
>
> Thanks,
> Vladimir
>
> On 12/19/14 9:44 AM, Volker Simonis wrote:
>
>> Hi,
>>
>> could somebody please have a quick look at this fix and sponsor it?
>> It breaks our AIX build.
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Thu, Dec 18, 2014 at 5:31 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> could sombody please review and sponsor this little change which fixes
>>> the build on AIX after 8066780/8066782:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/8067865
>>> https://bugs.openjdk.java.net/browse/JDK-8067865
>>>
>>> Here's the full story: 8066780/8066782 did some code refactoring and
>>> introduced the new files cardGeneration.{hpp,cpp,inline.hpp}.
>>> Unfortunately, the changes forgot to include cardGeneration.inline.hpp
>>> into tenuredGeneration.cpp and concurrentMarkSweepGeneration.cpp which
>>> use the methods defined therein.
>>>
>>> This problem doesn't show up on Linux (even if build with
>>> '--disable-precompiled-headers') because for some reason GCC places
>>> weak references of the corresponding symbols in cardGeneration.o. So
>>> later when linking libjvm.so the references can still be resolved. Sun
>>> Studio also places global instantiations of the corresponding inline
>>> functions into cardGeneration.o so we don't see any problems there as
>>> well.
>>>
>>> xlC on AIX only puts a locally visible reference of the neede inline
>>> functions into cardGeneration.o if he can't inline them (which is
>>> perfectly legal because they are declared 'inline'). However, later
>>> one during linking no globally visible versions of the corresponding
>>> inline functions can be found and the link fails.
>>>
>>> The final fix is trivial - just include the corresponding
>>> cardGeneration.inline.hpp file into the .cpp files which require its
>>> method definitions.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>

From erik.osterlund at lnu.se  Sat Dec 20 11:20:07 2014
From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=)
Date: Sat, 20 Dec 2014 11:20:07 +0000
Subject: RFR: 8067790: Better support for native implementations of
	Atomic::cmpxchg
In-Reply-To: <CAAsuuZdsfWZQNgigwe3xMG7bzKrSzTonwfqa3TzFPA6uuwU3kA@mail.gmail.com>
References: <CAAsuuZdsfWZQNgigwe3xMG7bzKrSzTonwfqa3TzFPA6uuwU3kA@mail.gmail.com>
Message-ID: <B7BFCC69-6107-4A5F-9C44-79C2B90D64BF@lnu.se>

Hi Paul,

Thanks for the review! :)

/Erik

On 19 dec 2014, at 21:08, Paul Hohensee <paul.hohensee at gmail.com<mailto:paul.hohensee at gmail.com>> wrote:

Looks good to me, but then I reviewed it awhile back. :)

Paul

On Wed, Dec 17, 2014 at 5:38 PM, Erik ?sterlund <erik.osterlund at lnu.se<mailto:erik.osterlund at lnu.se>> wrote:
> Hi all,
>
> Previously, jbyte Atomic::cmpxchg had one general implementation for all platforms. A macro based solution was introduced, adding specialized implementation for the x86 platforms without changing code for the ports for other architectures, making the specialization optional (from ).
>
> However, macros are not very nice and this new fix gets rid of the macros and replaces it with a cleaner solution using inheritance and templates. The core idea is simple: split the Atomic class into three layers of inheritance.
>
> 1. AtomicBase is the base class where general operations for all platforms should go, now it contains the general implementation for jbyte cmpxchg, but in the future other similar methods are welcome too.
> 2. AtomicPlatform is an optional class that a platform can define, but does not have to (and hence does not break existing ports), allowing specialized variants to override the behaviour of AtomicBase. Now it contains the specialized platform dependent x86 variants of jbyte cmpxchg.
> 3. Atomic is the fascade of all atomics as expected. Its jbyte cmpxchg implementation simply forwards to its super class AtomicSuper which is either AtomicBase or AtomicPlatform if provided for the specific platform.
>
> All in all, it?s based on simple inheritance with the twist that the AtomicPlatform part is optional. This is allowed using some C++ metaprogramming idioms. Concretely, a trait was implemented called SelectBaseClass that allows you to specify the desired base class, and another one to fall back to in case the desired base class was not defined (forward declaration). The super class of Atomic is hence defined as:
>
> typedef SelectBaseClass<
AtomicPlatform, AtomicBase>::type AtomicSuper;
>
> To implement this trait, an equivalent variant of the C++11/boost is_base_of trait was implemented, called IsBaseOf to follow our naming conventions. It is very similar to the standard version but works on all of our compilers. The only difference so far between IsBaseOf and is_base_of is that IsBaseOf will return true when comparing two unions that are the same, while is_base_of will not. The reason for this is that I found no portable way of detecting unions. A bunch of dependent traits were implemented too, and it can all be found in utilities/traits/ since I like reasonably fine grained headers. All these traits are built to be reusable and perhaps we will have more uses for metaprogramming in the future where this comes in handy. The intended behaviour and contract of the traits are documented in comments.
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8067790
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8067790/webrev.00/<http://cr.openjdk.java.net/%7Ejwilhelm/8067790/webrev.00/>
>
> In summary this allows us to get rid of the ugly macro used before and provide a better general mechanism for having generalized and specialized atomics without breaking existing ports for those platforms that do not need it. And hopefully the metaprogramming tools will come in useful in the future for perhaps similar situations.
>
> Testing:
> * All new traits have test cases using STATIC_ASSERT nailing down the intended behaviour and contract also reflected in the comments.
> * The changes passed the jprt testing ok. (Thanks to Jesper for running it!)
>
> Thanks,
> /Erik


From goetz.lindenmaier at sap.com  Sat Dec 20 20:57:47 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sat, 20 Dec 2014 20:57:47 +0000
Subject: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.
In-Reply-To: <54946851.2050107@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF43388@DEWDFEMB12A.global.corp.sap>
	<54946851.2050107@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF4490B@DEWDFEMB12A.global.corp.sap>

Hi,

thanks for the Review, Vladimir!

I removed CheckCompileThresholdScaling.java and also TestHumongousCodeCacheRoots.java
which havn't to do anything with page size.
Also, I improved the comment in metaspace.cpp.

I please need another reviewer from gc if possible, and a sponsor!

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
Sent: Friday, December 19, 2014 7:03 PM
To: hotspot-dev at openjdk.java.net
Subject: Re: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.

I agree with compiler tests changes. Other groups should review changes 
in their files.

You accidentally included 8067823 in CheckCompileThresholdScaling.java

Thanks,
Vladimir

On 12/19/14 8:05 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> please review this simple change.  I please need a sponsor.
> The change should be downported to 8u60.  It applies nicely except
> for some missing files.
> http://cr.openjdk.java.net/~goetz/webrevs/8067941-64K/webrev.01/
>
> The issue is that we have linux ppc64 machines that have default page size
> of 64K.  This imposes bigger limits on stack and heap sizes than if running
> with 4k pages.
> Ergonomics increase some flags if they are too small.
> Increasing the sizes used in the test slightly helps in most cases.  Details:
>
> runtime/whitebox/WBStackSize.java
>    The constant esimating the so far occupied stack is too small. Fix: Consider size of shadow pages
>
> compiler/uncommontrap/TestStackBangRbp.java:
> compiler/uncommontrap/TestStackBangMonitorOwned.java
> compiler/uncommontrap/StackOverflowGuardPagesOff.java
> compiler/uncommontrap/8009761/Test8009761.java
> compiler/runtime/6865265/StackOverflowBug.java
> compiler/exceptions/TestRecursiveReplacedException.java
> Increase stack size to 392K, need at least 328K.
>
> sanity/ExecuteInternalVMTests.java
> - Assertion in metaspace.cpp simly must fail with vm_page_size == 64K as it
>     basically asserts vm_page_size < 16K
> - With 64K pages, heap sizes are computed differently starting from the alignment
>     which is card_size * vm_page_size.
>
> gc/arguments/TestMaxHeapSizeTools.java
>    Sizes are alinged up being equal in the end. Choose bigger sizes.
>
> gc/g1/TestHumongousAllocInitialMark.java
>    Test computes some size based on the -Xmx value it uses.  Heap size is increased slightly
>    with 64K making the computation wrong and the test fail. Choose heap size that needs not
>    be aligned.
>
> gc/g1/TestGCLogMessages.java
>    Heap of 10M is increased to 32M because of the alignment with 64K pages.
>    This makes the evacuation succeed. Choose 32M from the beginning and adapt
>    size of huge object.
>
> Best regards,
>    Goetz.
>

From goetz.lindenmaier at sap.com  Sat Dec 20 22:04:36 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sat, 20 Dec 2014 22:04:36 +0000
Subject: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws
	RuntimeException
In-Reply-To: <549467B0.2000300@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF43365@DEWDFEMB12A.global.corp.sap>
	<54946715.9000006@oracle.com> <549467B0.2000300@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44929@DEWDFEMB12A.global.corp.sap>

Thanks Igor and Vladimir!

I still please need a sponsor.

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev
Sent: Friday, December 19, 2014 7:00 PM
To: Vladimir Kozlov; hotspot-dev at openjdk.java.net
Subject: Re: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws RuntimeException

looks good to me.

Thanks,
Igor

On 12/19/2014 08:57 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 12/19/14 7:50 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> Please review this tiny change.  I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/webrevs/8067823-client/webrev.01/
>>
>> The check that tiered compilation is not supported also checked that
>> it's a client vm.
>> This is too strict.
>>
>> Thanks and best regards,
>>    Goetz.
>>
>>

From thomas.schatzl at oracle.com  Mon Dec 22 12:00:38 2014
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 22 Dec 2014 13:00:38 +0100
Subject: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF43388@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF43388@DEWDFEMB12A.global.corp.sap>
Message-ID: <1419249638.3426.11.camel@oracle.com>

Hi Goetz,

On Fri, 2014-12-19 at 16:05 +0000, Lindenmaier, Goetz wrote:
> Hi,
> 
> please review this simple change.  I please need a sponsor.
> The change should be downported to 8u60.  It applies nicely except
> for some missing files.
> http://cr.openjdk.java.net/~goetz/webrevs/8067941-64K/webrev.01/
> 
> The issue is that we have linux ppc64 machines that have default page size
> of 64K.  This imposes bigger limits on stack and heap sizes than if running
> with 4k pages.
> Ergonomics increase some flags if they are too small.
> Increasing the sizes used in the test slightly helps in most cases.  Details:
[...]
> sanity/ExecuteInternalVMTests.java
> - Assertion in metaspace.cpp simly must fail with vm_page_size == 64K as it
>    basically asserts vm_page_size < 16K

I would skip the entire test in that case (everything from the enclosing
braces) instead of skipping only the actual test and not the setup.

> - With 64K pages, heap sizes are computed differently starting from the alignment
>    which is card_size * vm_page_size.
> 
> gc/arguments/TestMaxHeapSizeTools.java
>   Sizes are alinged up being equal in the end. Choose bigger sizes.

Looks good.

> 
> gc/g1/TestHumongousAllocInitialMark.java
>   Test computes some size based on the -Xmx value it uses.  Heap size is increased slightly
>   with 64K making the computation wrong and the test fail. Choose heap size that needs not
>   be aligned.

Okay.

> 
> gc/g1/TestGCLogMessages.java
>   Heap of 10M is increased to 32M because of the alignment with 64K pages.
>   This makes the evacuation succeed. Choose 32M from the beginning and adapt
>   size of huge object.

Okay.

Thomas



From goetz.lindenmaier at sap.com  Mon Dec 22 13:00:15 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 22 Dec 2014 13:00:15 +0000
Subject: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.
In-Reply-To: <1419249638.3426.11.camel@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC2CF43388@DEWDFEMB12A.global.corp.sap>
	<1419249638.3426.11.camel@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44B31@DEWDFEMB12A.global.corp.sap>

Hi Thomas, 

Thanks for looking at this change!

> I would skip the entire test in that case (everything from the enclosing
> braces) instead of skipping only the actual test and not the setup.
I changed it accordingly.  I had to move page_chunks out of the brackets, too.

Best regards,
  Goetz.
 


-----Original Message-----
From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] 
Sent: Montag, 22. Dezember 2014 13:01
To: Lindenmaier, Goetz
Cc: 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.

Hi Goetz,

On Fri, 2014-12-19 at 16:05 +0000, Lindenmaier, Goetz wrote:
> Hi,
> 
> please review this simple change.  I please need a sponsor.
> The change should be downported to 8u60.  It applies nicely except
> for some missing files.
> http://cr.openjdk.java.net/~goetz/webrevs/8067941-64K/webrev.01/
> 
> The issue is that we have linux ppc64 machines that have default page size
> of 64K.  This imposes bigger limits on stack and heap sizes than if running
> with 4k pages.
> Ergonomics increase some flags if they are too small.
> Increasing the sizes used in the test slightly helps in most cases.  Details:
[...]
> sanity/ExecuteInternalVMTests.java
> - Assertion in metaspace.cpp simly must fail with vm_page_size == 64K as it
>    basically asserts vm_page_size < 16K

I would skip the entire test in that case (everything from the enclosing
braces) instead of skipping only the actual test and not the setup.

> - With 64K pages, heap sizes are computed differently starting from the alignment
>    which is card_size * vm_page_size.
> 
> gc/arguments/TestMaxHeapSizeTools.java
>   Sizes are alinged up being equal in the end. Choose bigger sizes.

Looks good.

> 
> gc/g1/TestHumongousAllocInitialMark.java
>   Test computes some size based on the -Xmx value it uses.  Heap size is increased slightly
>   with 64K making the computation wrong and the test fail. Choose heap size that needs not
>   be aligned.

Okay.

> 
> gc/g1/TestGCLogMessages.java
>   Heap of 10M is increased to 32M because of the alignment with 64K pages.
>   This makes the evacuation succeed. Choose 32M from the beginning and adapt
>   size of huge object.

Okay.

Thomas



From goetz.lindenmaier at sap.com  Mon Dec 22 13:07:31 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 22 Dec 2014 13:07:31 +0000
Subject: RFR (S): 8068026: [TESTBUG] Check for -client in
	gc/g1/TestHumongousCodeCacheRoots.java
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44B46@DEWDFEMB12A.global.corp.sap>

Hi,

I please need a review and a sponsor for this tiny change:

http://cr.openjdk.java.net/~goetz/webrevs/8068026-jtregClient/webrev.01/
The test did not check whether -client is supported.

The patch should also go to 8u60, please.

Best regards,
  Goetz

From volker.simonis at gmail.com  Mon Dec 22 14:26:30 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 22 Dec 2014 15:26:30 +0100
Subject: RFR: 8067790: Better support for native implementations of
	Atomic::cmpxchg
In-Reply-To: <0C90C9DB-1ED8-4AFF-A6D4-8035D323E95C@lnu.se>
References: <0F0D9F35-148D-4C62-8065-7E58F5EC76D1@lnu.se>
	<CA+3eh11T5jceh9tcqjtij5226eHAqm3-KXWoeNky-EpLjHhfpg@mail.gmail.com>
	<0C90C9DB-1ED8-4AFF-A6D4-8035D323E95C@lnu.se>
Message-ID: <CA+3eh11zHh3U4UgH=s_W18k2DdLoYAZ1pzT0OvsyH_BGMecB-A@mail.gmail.com>

On Fri, Dec 19, 2014 at 7:51 PM, Erik ?sterlund <erik.osterlund at lnu.se> wrote:
> Hi Volker,
>
> Thank you for reviewing this change!
>
>> On 19 Dec 2014, at 17:30, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> Hi Erik,
>>
>> nice change (did I mention already that I LOVE template metaprogramming :)
>
> I?m glad there are more people supporting template metaprogramming for solving architectural problems! :)
>
>> first some minor layout stuff:
>>
>> - some of your file contain trailing white space (mostly in empty
>> lines). Running jcheck on your change reports:
>>
>> src/os_cpu/bsd_x86/vm/atomic_bsd_x86.hpp:33: Trailing whitespace
>> src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp:33: Trailing whitespace
>> src/os_cpu/solaris_x86/vm/atomic_solaris_x86.hpp:33: Trailing whitespace
>> src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp:33: Trailing whitespace
>> src/share/vm/utilities/traits/isBaseOf.cpp:32: Trailing whitespace
>> src/share/vm/utilities/traits/isBaseOf.hpp:63: Trailing whitespace
>> src/share/vm/utilities/traits/isClassOrUnion.hpp:35: Trailing whitespace
>> src/share/vm/utilities/traits/isSame.cpp:89: Trailing whitespace
>> src/share/vm/utilities/traits/selectBaseClass.hpp:39: Trailing whitespace
>>
>> Could you please fix these lines and make your change 'jcheck'-safe.
>>
>
> Oh snap, that vimscript to for removing trailing whitespaces on save seems to have been disabled. :/ Fixed.
>
>> - all your test functions are static except
>> IsBaseOfAndDerivedTest::test()  in isBaseOf.cpp. I understand that it
>> is not strictly necessary but for symmetric reasons you could make it
>> static as well.
>
> Sure, fixed.
>
>> - your test are elegant and I like them. However I wonder how we can
>> be sure that the compiler really instantiates all the templates. I can
>> see that there's no code created for the test functions in the object
>> files (which is fine). But how can we be sure that they are relly
>> compiled? Do you have any insights here? (By the way, I noticed that
>> if a insert a wrong STATIC_ASSERT I get a compile time warning, so
>> your tests work in general. I only wonder if they really work always
>> or if a smart compiler can just figure out that he doesn't need to
>> compile them?)
>
> Optimizations such as dead code elimination within a compilation unit are performed after template instantiation because before template instantiation, it?s impossible to know what the code does and hence if it is dead code or not. Therefore, I?m pretty certain that STATIC_ASSERT will always fail before finding out that the code is not needed. And cross object-file optimizations can be done at link time, but the STATIC_ASSERT will trigger way before linking. Therefore I would be very surprised if this style of testing does not work for all compilers.
>
>> - have you also done some performance checks (i.e. is the templatized
>> version really as fast as the one with macros?)
>
> I did by running DaCapo benchmarks using G1 (which uses this for manipulating cards), and there was no visible difference. Not surprising considering it?s all explicitly inlined as before.
>
>> Following some additional platform/compiler checks (just in case
>> somebody is interested):
>>
>> - doesn?t compile with aCC A.03.73 on HP UX 11.11 / PARISC (SIGSEGV
>> in compiler)
>> - compiles with aCC A.03.95.01 on HP UX 11.31 / PARISC (with
>> +hpxstd98, without +hpxstd98 SIGSEGV in compiler)
>>
>> - compiles with aCC A.06.16.01 on HP UX 11.23 / IA64
>>
>> - compiles with g++ 4.1.2 on Linux/ppc64
>>
>> - compiles with xlc 10.1 on AIX 5.3
>> - compiles with xlC 12.01 on AIX 7.1
>
> Very interesting! :)
> Do you want a new webrev to see that the trailing whitespaces have been removed and IsBaseOfAndDerivedTest::test was made static?
>

Hi Erik,

you don't need to prepare a new webrev as long as you don't forget to
include the changes in the final changeset :)

And please pay attention, I've found other layout problem in atomic.hpp

- please keep only one space character between the variables and types
in the declaration of the cmpxchg() method (like in
atomic_<os>_x86.hpp)

One final comment: I'm perfectly fine with this change in jdk9 but I
would be reluctant to down-port it to jdk8 as this may still affect
people building jdk8 with older compilers.

Regards,
Volker

> Thanks,
> Erik
>
>>
>> Regards,
>> Volker
>>
>> On Wed, Dec 17, 2014 at 5:38 PM, Erik ?sterlund <erik.osterlund at lnu.se> wrote:
>>> Hi all,
>>>
>>> Previously, jbyte Atomic::cmpxchg had one general implementation for all platforms. A macro based solution was introduced, adding specialized implementation for the x86 platforms without changing code for the ports for other architectures, making the specialization optional (from ).
>>>
>>> However, macros are not very nice and this new fix gets rid of the macros and replaces it with a cleaner solution using inheritance and templates. The core idea is simple: split the Atomic class into three layers of inheritance.
>>>
>>> 1. AtomicBase is the base class where general operations for all platforms should go, now it contains the general implementation for jbyte cmpxchg, but in the future other similar methods are welcome too.
>>> 2. AtomicPlatform is an optional class that a platform can define, but does not have to (and hence does not break existing ports), allowing specialized variants to override the behaviour of AtomicBase. Now it contains the specialized platform dependent x86 variants of jbyte cmpxchg.
>>> 3. Atomic is the fascade of all atomics as expected. Its jbyte cmpxchg implementation simply forwards to its super class AtomicSuper which is either AtomicBase or AtomicPlatform if provided for the specific platform.
>>>
>>> All in all, it?s based on simple inheritance with the twist that the AtomicPlatform part is optional. This is allowed using some C++ metaprogramming idioms. Concretely, a trait was implemented called SelectBaseClass that allows you to specify the desired base class, and another one to fall back to in case the desired base class was not defined (forward declaration). The super class of Atomic is hence defined as:
>>>
>>> typedef SelectBaseClass<AtomicPlatform, AtomicBase>::type AtomicSuper;
>>>
>>> To implement this trait, an equivalent variant of the C++11/boost is_base_of trait was implemented, called IsBaseOf to follow our naming conventions. It is very similar to the standard version but works on all of our compilers. The only difference so far between IsBaseOf and is_base_of is that IsBaseOf will return true when comparing two unions that are the same, while is_base_of will not. The reason for this is that I found no portable way of detecting unions. A bunch of dependent traits were implemented too, and it can all be found in utilities/traits/ since I like reasonably fine grained headers. All these traits are built to be reusable and perhaps we will have more uses for metaprogramming in the future where this comes in handy. The intended behaviour and contract of the traits are documented in comments.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8067790
>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8067790/webrev.00/
>>>
>>> In summary this allows us to get rid of the ugly macro used before and provide a better general mechanism for having generalized and specialized atomics without breaking existing ports for those platforms that do not need it. And hopefully the metaprogramming tools will come in useful in the future for perhaps similar situations.
>>>
>>> Testing:
>>> * All new traits have test cases using STATIC_ASSERT nailing down the intended behaviour and contract also reflected in the comments.
>>> * The changes passed the jprt testing ok. (Thanks to Jesper for running it!)
>>>
>>> Thanks,
>>> /Erik
>

From vladimir.kozlov at oracle.com  Mon Dec 22 17:57:21 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 22 Dec 2014 09:57:21 -0800
Subject: Please, delay changes to hotspot/test/testlibrary/whitebox files
	(they are not there)
Message-ID: <54985B81.8030209@oracle.com>

testlibrary/whitebox was moved to top repository in hs-comp forest:

http://hg.openjdk.java.net/jdk9/hs-comp/rev/c82ea5393dda
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eba1bd212c02

It created conflict with 8047290 changes and other issues which 
prevented the sync from hs-comp/ to hs/. We are working on resolving 
this and will do merge into main hs/ after it is solved.

If you don't want to go through the same problems, please, delay changes 
to whitebox tests until current problems are resolved and fixes are 
synced into all hotspot repos.

Regards,
Vladimir

From goetz.lindenmaier at sap.com  Mon Dec 22 22:20:34 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 22 Dec 2014 22:20:34 +0000
Subject: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF44B31@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF43388@DEWDFEMB12A.global.corp.sap>
	<1419249638.3426.11.camel@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF44B31@DEWDFEMB12A.global.corp.sap>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44DAD@DEWDFEMB12A.global.corp.sap>

Hi,

could someone from runtime please have a look at the last of these fixes?
runtime/whitebox/WBStackSize.java
http://cr.openjdk.java.net/~goetz/webrevs/8067941-64K/webrev.01/test/runtime/whitebox/WBStackSize.java.udiff.html
I get the shadow page size from WB to compute the space wasted on the stack so far.

And I please need a sponsor for this!  (In case somebody works the next days. If not, it's Christmas time!)

Best regards,
  Goetz.


-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
Sent: Monday, December 22, 2014 2:00 PM
To: Thomas Schatzl
Cc: 'hotspot-dev at openjdk.java.net'
Subject: RE: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.

Hi Thomas, 

Thanks for looking at this change!

> I would skip the entire test in that case (everything from the enclosing
> braces) instead of skipping only the actual test and not the setup.
I changed it accordingly.  I had to move page_chunks out of the brackets, too.

Best regards,
  Goetz.
 


-----Original Message-----
From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] 
Sent: Montag, 22. Dezember 2014 13:01
To: Lindenmaier, Goetz
Cc: 'hotspot-dev at openjdk.java.net'
Subject: Re: RFR(M): 8067941: [TESTBUG] Fix tests for OS with 64K page size.

Hi Goetz,

On Fri, 2014-12-19 at 16:05 +0000, Lindenmaier, Goetz wrote:
> Hi,
> 
> please review this simple change.  I please need a sponsor.
> The change should be downported to 8u60.  It applies nicely except
> for some missing files.
> http://cr.openjdk.java.net/~goetz/webrevs/8067941-64K/webrev.01/
> 
> The issue is that we have linux ppc64 machines that have default page size
> of 64K.  This imposes bigger limits on stack and heap sizes than if running
> with 4k pages.
> Ergonomics increase some flags if they are too small.
> Increasing the sizes used in the test slightly helps in most cases.  Details:
[...]
> sanity/ExecuteInternalVMTests.java
> - Assertion in metaspace.cpp simly must fail with vm_page_size == 64K as it
>    basically asserts vm_page_size < 16K

I would skip the entire test in that case (everything from the enclosing
braces) instead of skipping only the actual test and not the setup.

> - With 64K pages, heap sizes are computed differently starting from the alignment
>    which is card_size * vm_page_size.
> 
> gc/arguments/TestMaxHeapSizeTools.java
>   Sizes are alinged up being equal in the end. Choose bigger sizes.

Looks good.

> 
> gc/g1/TestHumongousAllocInitialMark.java
>   Test computes some size based on the -Xmx value it uses.  Heap size is increased slightly
>   with 64K making the computation wrong and the test fail. Choose heap size that needs not
>   be aligned.

Okay.

> 
> gc/g1/TestGCLogMessages.java
>   Heap of 10M is increased to 32M because of the alignment with 64K pages.
>   This makes the evacuation succeed. Choose 32M from the beginning and adapt
>   size of huge object.

Okay.

Thomas



From vladimir.kozlov at oracle.com  Mon Dec 22 23:44:19 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 22 Dec 2014 15:44:19 -0800
Subject: RFR(S) 8067985: merging hs-comp to hs blocked by some tests not
	updated in 8054892
Message-ID: <5498ACD3.2080102@oracle.com>

Formal request for changes I pushed to pass JPRT job which syncs jdk9/hs 
and jdk9/hs-comp.

http://cr.openjdk.java.net/~kvn/8067985/webrev/

Fixed hotspot/test/gc/arguments/TestSurvivorAlignmentInBytesOption.java 
to use changed by 8054892 CommandLineOptionTest methods.
Also fixed tests to use new location of WhiteBox testlib.

Thanks,
Vladimir

From goetz.lindenmaier at sap.com  Tue Dec 23 08:09:32 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 23 Dec 2014 08:09:32 +0000
Subject: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws
	RuntimeException
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF44929@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF43365@DEWDFEMB12A.global.corp.sap>
	<54946715.9000006@oracle.com> <549467B0.2000300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF44929@DEWDFEMB12A.global.corp.sap>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44E1F@DEWDFEMB12A.global.corp.sap>

Thanks for pushing the change, whoever was so friendly.

Merry Christmas,
  Goetz.



-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
Sent: Samstag, 20. Dezember 2014 23:05
To: 'Igor Ignatyev'; 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
Subject: RE: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws RuntimeException

Thanks Igor and Vladimir!

I still please need a sponsor.

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev
Sent: Friday, December 19, 2014 7:00 PM
To: Vladimir Kozlov; hotspot-dev at openjdk.java.net
Subject: Re: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws RuntimeException

looks good to me.

Thanks,
Igor

On 12/19/2014 08:57 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 12/19/14 7:50 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> Please review this tiny change.  I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/webrevs/8067823-client/webrev.01/
>>
>> The check that tiered compilation is not supported also checked that
>> it's a client vm.
>> This is too strict.
>>
>> Thanks and best regards,
>>    Goetz.
>>
>>

From goetz.lindenmaier at sap.com  Tue Dec 23 08:17:41 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 23 Dec 2014 08:17:41 +0000
Subject: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws
	RuntimeException
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF44929@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC2CF43365@DEWDFEMB12A.global.corp.sap>
	<54946715.9000006@oracle.com> <549467B0.2000300@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CF44929@DEWDFEMB12A.global.corp.sap>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44E36@DEWDFEMB12A.global.corp.sap>

Ahhh, thanks Vladimir!  It's in the JBS message ;)

Best regards,
  Goetz.



-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
Sent: Samstag, 20. Dezember 2014 23:05
To: 'Igor Ignatyev'; 'Vladimir Kozlov'; 'hotspot-dev at openjdk.java.net'
Subject: RE: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws RuntimeException

Thanks Igor and Vladimir!

I still please need a sponsor.

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev
Sent: Friday, December 19, 2014 7:00 PM
To: Vladimir Kozlov; hotspot-dev at openjdk.java.net
Subject: Re: RFR (XXS): 8067823: CheckCompileThresholdScaling.java throws RuntimeException

looks good to me.

Thanks,
Igor

On 12/19/2014 08:57 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 12/19/14 7:50 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>
>> Please review this tiny change.  I please need a sponsor.
>> http://cr.openjdk.java.net/~goetz/webrevs/8067823-client/webrev.01/
>>
>> The check that tiered compilation is not supported also checked that
>> it's a client vm.
>> This is too strict.
>>
>> Thanks and best regards,
>>    Goetz.
>>
>>

From filipp.zhinkin at oracle.com  Tue Dec 23 13:27:33 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Tue, 23 Dec 2014 17:27:33 +0400
Subject: [8u40] Request for approval to backport JDK-8037968 and
	JDK-8066143
In-Reply-To: <54981595.4050601@oracle.com>
References: <54943D36.2080001@oracle.com> <54981595.4050601@oracle.com>
Message-ID: <54996DC5.8090701@oracle.com>

Thank you for approval, Rob.

Regards,
Filipp.

On 12/22/2014 04:59 PM, Rob McKenna wrote:
> Approved. (Fuzz doesn't require a new patch)
>
>     -Rob
>
> On 19/12/14 14:59, Filipp Zhinkin wrote:
>> Hi,
>>
>> please approve backport of following test-only fixes into 8u40:
>>
>> JDK-8037968 Add tests on alignment of objects copied to survivor space:
>>
>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8037968
>> Original review thread: 
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-November/011405.html
>> Original changeset: 
>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/c196aca52cab
>>
>>
>> JDK-8066143 [TESTBUG] New tests in gc/survivorAlignment/ fails
>>
>> Bug-id: https://bugs.openjdk.java.net/browse/JDK-8066143
>> Original review thread: 
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-December/011573.html
>> Original changeset: 
>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3c17077e9882
>>
>>
>> Fix for 8037968 applied with fuzz, but without any changes. Do I need to 
>> create a new patch for it?
>> Fix for 8066143 applied cleanly without any changes.
>>
>> I've tested these tests after both fixes were applied, no issues were found.
>>
>> Thanks,
>> Filipp.
>


From vladimir.kozlov at oracle.com  Tue Dec 23 17:00:02 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Dec 2014 09:00:02 -0800
Subject: Please, delay changes to hotspot/test/testlibrary/whitebox files
	(they are not there)
In-Reply-To: <54985B81.8030209@oracle.com>
References: <54985B81.8030209@oracle.com>
Message-ID: <54999F92.9070901@oracle.com>

hs-comp was merged with hs. If you use whitebox lib in a test you need to specify in @library

/../../test/lib

instead of

/testlibrary/whitebox

Regards,
Vladimir

On 12/22/14 9:57 AM, Vladimir Kozlov wrote:
> testlibrary/whitebox was moved to top repository in hs-comp forest:
>
> http://hg.openjdk.java.net/jdk9/hs-comp/rev/c82ea5393dda
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eba1bd212c02
>
> It created conflict with 8047290 changes and other issues which prevented the sync from hs-comp/ to hs/. We are working
> on resolving this and will do merge into main hs/ after it is solved.
>
> If you don't want to go through the same problems, please, delay changes to whitebox tests until current problems are
> resolved and fixes are synced into all hotspot repos.
>
> Regards,
> Vladimir

From david.holmes at oracle.com  Sun Dec 28 11:44:52 2014
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 28 Dec 2014 21:44:52 +1000
Subject: Please, delay changes to hotspot/test/testlibrary/whitebox files
	(they are not there)
In-Reply-To: <54999F92.9070901@oracle.com>
References: <54985B81.8030209@oracle.com> <54999F92.9070901@oracle.com>
Message-ID: <549FED34.1030302@oracle.com>

On 24/12/2014 3:00 AM, Vladimir Kozlov wrote:
> hs-comp was merged with hs. If you use whitebox lib in a test you need
> to specify in @library
>
> /../../test/lib
>
> instead of
>
> /testlibrary/whitebox

You mean all the existing tests are now broken ??

David

> Regards,
> Vladimir
>
> On 12/22/14 9:57 AM, Vladimir Kozlov wrote:
>> testlibrary/whitebox was moved to top repository in hs-comp forest:
>>
>> http://hg.openjdk.java.net/jdk9/hs-comp/rev/c82ea5393dda
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eba1bd212c02
>>
>> It created conflict with 8047290 changes and other issues which
>> prevented the sync from hs-comp/ to hs/. We are working
>> on resolving this and will do merge into main hs/ after it is solved.
>>
>> If you don't want to go through the same problems, please, delay
>> changes to whitebox tests until current problems are
>> resolved and fixes are synced into all hotspot repos.
>>
>> Regards,
>> Vladimir

From vladimir.kozlov at oracle.com  Sun Dec 28 18:26:15 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sun, 28 Dec 2014 10:26:15 -0800
Subject: Please, delay changes to hotspot/test/testlibrary/whitebox files
	(they are not there)
In-Reply-To: <549FED34.1030302@oracle.com>
References: <54985B81.8030209@oracle.com> <54999F92.9070901@oracle.com>
	<549FED34.1030302@oracle.com>
Message-ID: <54A04B47.8050803@oracle.com>

I mean for new tests. We fixed all existing tests:

http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/579e9a019f35

Vladimir

On 12/28/14 3:44 AM, David Holmes wrote:
> On 24/12/2014 3:00 AM, Vladimir Kozlov wrote:
>> hs-comp was merged with hs. If you use whitebox lib in a test you need
>> to specify in @library
>>
>> /../../test/lib
>>
>> instead of
>>
>> /testlibrary/whitebox
>
> You mean all the existing tests are now broken ??
>
> David
>
>> Regards,
>> Vladimir
>>
>> On 12/22/14 9:57 AM, Vladimir Kozlov wrote:
>>> testlibrary/whitebox was moved to top repository in hs-comp forest:
>>>
>>> http://hg.openjdk.java.net/jdk9/hs-comp/rev/c82ea5393dda
>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/eba1bd212c02
>>>
>>> It created conflict with 8047290 changes and other issues which
>>> prevented the sync from hs-comp/ to hs/. We are working
>>> on resolving this and will do merge into main hs/ after it is solved.
>>>
>>> If you don't want to go through the same problems, please, delay
>>> changes to whitebox tests until current problems are
>>> resolved and fixes are synced into all hotspot repos.
>>>
>>> Regards,
>>> Vladimir

From zoltan.majo at oracle.com  Mon Dec 29 11:52:57 2014
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 29 Dec 2014 12:52:57 +0100
Subject: [8u60] Request for approval: Backport of 8058345(S)
Message-ID: <54A14099.1080608@oracle.com>

Hi,


I would like to request the backport of the fix for JDK-8058345 to 8u60.

Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8058345
Patch: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/86183a940db4
Original changeset: 
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/86183a940db4

The patch applies cleanly.

This patch also fixes bug JDK-8066799 'hs_err can contain incomplete 
stack trace':

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

All JPRT tests completed successfully.

Thank you and best regards,


Zoltan


From christian.thalinger at oracle.com  Mon Dec 29 15:54:12 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Dec 2014 07:54:12 -0800
Subject: [8u60] Request for approval: Backport of 8058345(S)
In-Reply-To: <54A14099.1080608@oracle.com>
References: <54A14099.1080608@oracle.com>
Message-ID: <FCEB08DC-FB89-4349-A3B4-EFE5EEF3FC70@oracle.com>

Good.

> On Dec 29, 2014, at 3:52 AM, Zolt?n Maj? <zoltan.majo at oracle.com> wrote:
> 
> Hi,
> 
> 
> I would like to request the backport of the fix for JDK-8058345 to 8u60.
> 
> Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8058345
> Patch: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/86183a940db4
> Original changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/86183a940db4
> 
> The patch applies cleanly.
> 
> This patch also fixes bug JDK-8066799 'hs_err can contain incomplete stack trace':
> 
> https://bugs.openjdk.java.net/browse/JDK-8066799
> 
> All JPRT tests completed successfully.
> 
> Thank you and best regards,
> 
> 
> Zoltan
> 


From zoltan.majo at oracle.com  Mon Dec 29 15:59:25 2014
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 29 Dec 2014 16:59:25 +0100
Subject: [8u60] Request for approval: Backport of 8058345(S)
In-Reply-To: <FCEB08DC-FB89-4349-A3B4-EFE5EEF3FC70@oracle.com>
References: <54A14099.1080608@oracle.com>
	<FCEB08DC-FB89-4349-A3B4-EFE5EEF3FC70@oracle.com>
Message-ID: <54A17A5D.1030203@oracle.com>

Thank you, Chris!


Zoltan

On 12/29/2014 04:54 PM, Christian Thalinger wrote:
> Good.
>
>> On Dec 29, 2014, at 3:52 AM, Zolt?n Maj? <zoltan.majo at oracle.com> wrote:
>>
>> Hi,
>>
>>
>> I would like to request the backport of the fix for JDK-8058345 to 8u60.
>>
>> Original (9) bug: https://bugs.openjdk.java.net/browse/JDK-8058345
>> Patch: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/86183a940db4
>> Original changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/86183a940db4
>>
>> The patch applies cleanly.
>>
>> This patch also fixes bug JDK-8066799 'hs_err can contain incomplete stack trace':
>>
>> https://bugs.openjdk.java.net/browse/JDK-8066799
>>
>> All JPRT tests completed successfully.
>>
>> Thank you and best regards,
>>
>>
>> Zoltan
>>


From kim.barrett at oracle.com  Tue Dec 30 23:05:14 2014
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 30 Dec 2014 18:05:14 -0500
Subject: RFR: 8067790: Better support for native implementations of
	Atomic::cmpxchg
In-Reply-To: <0F0D9F35-148D-4C62-8065-7E58F5EC76D1@lnu.se>
References: <0F0D9F35-148D-4C62-8065-7E58F5EC76D1@lnu.se>
Message-ID: <8DCE9938-C537-48AA-B27E-77E12279EA86@oracle.com>

On Dec 17, 2014, at 11:38 AM, Erik ?sterlund <erik.osterlund at lnu.se> wrote:
> 
> RFE: https://bugs.openjdk.java.net/browse/JDK-8067790
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8067790/webrev.00/

This seems like a lot of infrastructure, just to eliminate a
per-platform conditionally defined macro and the corresponding test
for its definition. If there were more atomic operations that could be
similarly conditionalized, with a default version that can be
overridden by a platform-specific version, some additional
infrastructure might be warranted. But as it stands, I don't think it
is.

The rest of these comments only matter if, contrary to my suggestion
above, some additional infrastructure is thought necessary.

The AtomicBase and various AtomicPlatform classes should not provide
public cmpxchg(jbyte...) functions. They should instead provide
protected cmpxchg_jbyte() functions, to be called by the public Atomic
interface function (whch can make an unqualified call to
cmpxchg_jbyte() and get the right version).
(AtomicBase::cmpxchg_general should be renamed to cmpxchg_jbyte.)

All of the template metaprogramming infrastructure proposed by the
offered change set can instead be accomplished by one conditionally
defined macro, e.g.

- Along with each definition of AtomicPlatform, also define
VM_HAS_ATOMIC_PLATFORM.

- After all the atomic_<os_arch>.hpp headers have been conditionally
included, add the following:

#ifdef VM_HAS_ATOMIC_PLATFORM
typedef AtomicPlatform AtomicSuper;
#else
typedef AtomicBase AtomicSuper;
#endif

[An alternative to the introduction of the AtomicSuper typedef would
be to just conditionalize the base class for Atomic.]

This scales with the number of AtomicPlatform definitions, rather than
the number of specialized functions as happens with the existing code.

The rest of these comments only matter if, contrary to my suggestion
above, the additional template metaprogramming infrastructure is
thought necessary.

I think the name "IsBaseOfAndDerived" would be better as
"IsBaseAndDerived".  That would also match the naming used by Boost,
and several other similar libraries one can find via web search (some
of which make explicit nod to the Boost name).

The current implementation of IsBaseOfAndDerived (and therefore
IsBaseOf) may (silently) provide incorrect answers when called with
incomplete types. C++11 is_base_of requires Derived to be complete if
it differs from Base. Boost has the stronger requirement that both
Base and Derived must be complete. This is an important flaw in the
offered implementations.

The actual usage in this proposed change-set even relies on this
flawed behavior of these metafunctions, since AtomicPlatform isn't
always defined. This seems rather icky to me. The only way to address
this would be to ensure that AtomicPlatform is defined for all
targets, either via explicit empty definitions or via the
VM_HAS_ATOMIC_PLATFORM technique described above.  But if the latter,
then we don't need all this TMP infrastructure.




From kim.barrett at oracle.com  Wed Dec 31 00:47:18 2014
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 30 Dec 2014 19:47:18 -0500
Subject: RFR: 8068396: Rename assert() to vmassert()
Message-ID: <42C93786-4866-47D9-A14C-F99B3EF4F687@oracle.com>

Please review this change to rename the assert macro to vmassert, as a
step toward eliminating the name clash between the VM's assert() macro
and the standard (<assert.h> / <cassert>) assert() macro.

[Coleen has volunteered sponsorship, since she's been prodding me to
make this change for months. Changes are based on jdk9/hs-rt repo.]

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

Webrev:
http://cr.openjdk.java.net/~kbarrett/8068396/webrev

Testing:
jprt. Also manually verified asserts occur as expected in fastdebug
build and not in release build.

Details of the changes are:

* Renamed the assert macro to vmassert. Also renamed the assert_status
macro to vmassert_status, for name consistency.

* Added temporary synonym macros of assert => vmassert and
assert_status => vmassert_status, for backward compatibility. This
change does not modify the (18K+) occurrences of the old macro names
to use the new names. The synonyms allow that renaming to occur
incrementally, with removal of the synonyms once renaming is complete.

* Simplified the definition of vmassert_status to just use vmassert,
rather than duplicating much of the implementation of vmassert. While
I was at it, added back a comma in the message that was (probably
accidentally) removed by 6888954: argument formatting for assert() and
friends (hg:1410 4/22/2010).

* Moved the assert_if_no_error macro to utilities/xmlstream.cpp, which
is the only place it is used. Also simplified the definition to just
use vmassert, rather than duplicating much of the implementation of
vmassert.

* Changed shark/llvmHeaders.hpp to just define assert as a synonym of
vmassert, rather than duplicating the definition of [vm]assert. [This
is an ugly hack, but still an improvement on what was there. This is a
place that could quickly benefit from updating uses.]

* Removed the non-product AssertRepeat option and the associated
support by the [vm]assert macro. Support for this option has been
broken since 6888954: argument formatting for assert() and friends
(hg:1410 4/22/2010), due to a missing line continuation in the
corresponding definition of the assert macro.  Since the feature
doesn't look very interesting, has been broken for nearly 5 years, and
can easily be resurrected if needed, I chose to simplify by removal.


From david.holmes at oracle.com  Wed Dec 31 01:22:18 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 31 Dec 2014 11:22:18 +1000
Subject: RFR: 8068396: Rename assert() to vmassert()
In-Reply-To: <42C93786-4866-47D9-A14C-F99B3EF4F687@oracle.com>
References: <42C93786-4866-47D9-A14C-F99B3EF4F687@oracle.com>
Message-ID: <54A34FCA.4060305@oracle.com>

Hi Kim,

On 31/12/2014 10:47 AM, Kim Barrett wrote:
> Please review this change to rename the assert macro to vmassert, as a
> step toward eliminating the name clash between the VM's assert() macro
> and the standard (<assert.h> / <cassert>) assert() macro.
>
> [Coleen has volunteered sponsorship, since she's been prodding me to
> make this change for months. Changes are based on jdk9/hs-rt repo.]
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8068396
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8068396/webrev
>
> Testing:
> jprt. Also manually verified asserts occur as expected in fastdebug
> build and not in release build.
>
> Details of the changes are:
>
> * Renamed the assert macro to vmassert. Also renamed the assert_status
> macro to vmassert_status, for name consistency.
>
> * Added temporary synonym macros of assert => vmassert and
> assert_status => vmassert_status, for backward compatibility. This
> change does not modify the (18K+) occurrences of the old macro names
> to use the new names. The synonyms allow that renaming to occur
> incrementally, with removal of the synonyms once renaming is complete.
>
> * Simplified the definition of vmassert_status to just use vmassert,

But by doing that you are forcing evaluation of err_msg and strerror in 
all cases, rather than only when the assertion condition is false.

David
-----


> rather than duplicating much of the implementation of vmassert. While
> I was at it, added back a comma in the message that was (probably
> accidentally) removed by 6888954: argument formatting for assert() and
> friends (hg:1410 4/22/2010).
>
> * Moved the assert_if_no_error macro to utilities/xmlstream.cpp, which
> is the only place it is used. Also simplified the definition to just
> use vmassert, rather than duplicating much of the implementation of
> vmassert.
>
> * Changed shark/llvmHeaders.hpp to just define assert as a synonym of
> vmassert, rather than duplicating the definition of [vm]assert. [This
> is an ugly hack, but still an improvement on what was there. This is a
> place that could quickly benefit from updating uses.]
>
> * Removed the non-product AssertRepeat option and the associated
> support by the [vm]assert macro. Support for this option has been
> broken since 6888954: argument formatting for assert() and friends
> (hg:1410 4/22/2010), due to a missing line continuation in the
> corresponding definition of the assert macro.  Since the feature
> doesn't look very interesting, has been broken for nearly 5 years, and
> can easily be resurrected if needed, I chose to simplify by removal.
>

From kim.barrett at oracle.com  Wed Dec 31 02:44:33 2014
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 30 Dec 2014 21:44:33 -0500
Subject: RFR: 8068396: Rename assert() to vmassert()
In-Reply-To: <54A34FCA.4060305@oracle.com>
References: <42C93786-4866-47D9-A14C-F99B3EF4F687@oracle.com>
	<54A34FCA.4060305@oracle.com>
Message-ID: <BDE8E3E2-7F9E-4C09-89CB-FD1433F881D9@oracle.com>

On Dec 30, 2014, at 8:22 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
>> * Simplified the definition of vmassert_status to just use vmassert,
> 
> But by doing that you are forcing evaluation of err_msg and strerror in all cases, rather than only when the assertion condition is false.

vmassert (nee assert) only evaluates the msg argument when the assertion condition is false.  It?s a macro, after all.


From david.holmes at oracle.com  Wed Dec 31 03:10:58 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 31 Dec 2014 13:10:58 +1000
Subject: RFR: 8068396: Rename assert() to vmassert()
In-Reply-To: <BDE8E3E2-7F9E-4C09-89CB-FD1433F881D9@oracle.com>
References: <42C93786-4866-47D9-A14C-F99B3EF4F687@oracle.com>
	<54A34FCA.4060305@oracle.com>
	<BDE8E3E2-7F9E-4C09-89CB-FD1433F881D9@oracle.com>
Message-ID: <54A36942.7050402@oracle.com>

On 31/12/2014 12:44 PM, Kim Barrett wrote:
> On Dec 30, 2014, at 8:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>>> * Simplified the definition of vmassert_status to just use vmassert,
>>
>> But by doing that you are forcing evaluation of err_msg and strerror in all cases, rather than only when the assertion condition is false.
>
> vmassert (nee assert) only evaluates the msg argument when the assertion condition is false.  It?s a macro, after all.

Yep - my bad. Sorry.

David


From erik.osterlund at lnu.se  Wed Dec 31 11:12:09 2014
From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=)
Date: Wed, 31 Dec 2014 11:12:09 +0000
Subject: RFR: 8067790: Better support for native implementations of
	Atomic::cmpxchg
In-Reply-To: <8DCE9938-C537-48AA-B27E-77E12279EA86@oracle.com>
References: <0F0D9F35-148D-4C62-8065-7E58F5EC76D1@lnu.se>,
	<8DCE9938-C537-48AA-B27E-77E12279EA86@oracle.com>
Message-ID: <1D2B176D-67FA-43C0-96CA-2D33BEA16853@lnu.se>

Hi Kim,

Thank you for the review.

> On 30 dec 2014, at 23:05, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> On Dec 17, 2014, at 11:38 AM, Erik ?sterlund <erik.osterlund at lnu.se> wrote:
>> 
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8067790
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8067790/webrev.00/
> 
> This seems like a lot of infrastructure, just to eliminate a
> per-platform conditionally defined macro and the corresponding test
> for its definition. If there were more atomic operations that could be
> similarly conditionalized, with a default version that can be
> overridden by a platform-specific version, some additional
> infrastructure might be warranted. But as it stands, I don't think it
> is.
> 
> The rest of these comments only matter if, contrary to my suggestion
> above, some additional infrastructure is thought necessary.
> 

This is what I originally thought too and hence the current solution. But voices said that using macros for this is, I quote, "that bad".

> The AtomicBase and various AtomicPlatform classes should not provide
> public cmpxchg(jbyte...) functions. They should instead provide
> protected cmpxchg_jbyte() functions, to be called by the public Atomic
> interface function (whch can make an unqualified call to
> cmpxchg_jbyte() and get the right version).
> (AtomicBase::cmpxchg_general should be renamed to cmpxchg_jbyte.)
> 
> All of the template metaprogramming infrastructure proposed by the
> offered change set can instead be accomplished by one conditionally
> defined macro, e.g.
> 
> - Along with each definition of AtomicPlatform, also define
> VM_HAS_ATOMIC_PLATFORM.
> 
> - After all the atomic_<os_arch>.hpp headers have been conditionally
> included, add the following:
> 
> #ifdef VM_HAS_ATOMIC_PLATFORM
> typedef AtomicPlatform AtomicSuper;
> #else
> typedef AtomicBase AtomicSuper;
> #endif
> 
> [An alternative to the introduction of the AtomicSuper typedef would
> be to just conditionalize the base class for Atomic.]
> 
> This scales with the number of AtomicPlatform definitions, rather than
> the number of specialized functions as happens with the existing code.

So your proposal is to still use ugly macros but move it to the class level instead, even though at the moment there is really only one member function that needs it. That feels a bit meh to be honest. IMO if we want to do this right, why go half the way and still rely on ugly macros?

> 
> The rest of these comments only matter if, contrary to my suggestion
> above, the additional template metaprogramming infrastructure is
> thought necessary.
> 
> I think the name "IsBaseOfAndDerived" would be better as
> "IsBaseAndDerived".  That would also match the naming used by Boost,
> and several other similar libraries one can find via web search (some
> of which make explicit nod to the Boost name).
> 
> The current implementation of IsBaseOfAndDerived (and therefore
> IsBaseOf) may (silently) provide incorrect answers when called with
> incomplete types. C++11 is_base_of requires Derived to be complete if
> it differs from Base. Boost has the stronger requirement that both
> Base and Derived must be complete. This is an important flaw in the
> offered implementations.
> 
> The actual usage in this proposed change-set even relies on this
> flawed behavior of these metafunctions, since AtomicPlatform isn't
> always defined. This seems rather icky to me. The only way to address
> this would be to ensure that AtomicPlatform is defined for all
> targets, either via explicit empty definitions or via the
> VM_HAS_ATOMIC_PLATFORM technique described above.  But if the latter,
> then we don't need all this TMP infrastructure.
> 

So what you are saying here is that I should rename IsBaseOfAndDerived to IsBaseAndDerived to more closely resemble other external libraries we do not use. But if I do that my behaviour is "incorrect" because it is not identical to that of the external library. And therefore my change would not work if it was made "correctly".

On the contrary this is a well tested feature on all our supported compilers and I did not intend to engineer it to be identical to some external library if it only causes trouble rather than helping. This is our own class and it can do what we want it to do and be called what we want it to be called, and I think that is fine as long as it is well tested, which it is. At least this is my opinion. Anyone else agree?

Thanks,
Erik

From serguei.spitsyn at oracle.com  Wed Dec 31 17:42:28 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 31 Dec 2014 09:42:28 -0800
Subject: RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed:
	OLD and/or OBSOLETE method(s) found
Message-ID: <54A43584.6050707@oracle.com>

Please, review the fix for:
   https://bugs.openjdk.java.net/browse/JDK-8068162


Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/


Summary:

    The sun.misc.Unsafe:throwIllegalAccessError() method is used in 
place of a default
    interface method in the itable if a default method was not defined 
in the interface.

    This approach creates a problem when the class sun.misc.Unsafe is 
retransformed.
    The Method* pointer to the old (redefined) method in the itable 
triggers an assert
    (see the hs_err log in the bug report).

    The fix is to replace the old method in the itable with the latest 
method version.


Testing:
   In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests


Thanks,
Serguei


From coleen.phillimore at oracle.com  Wed Dec 31 18:40:00 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 31 Dec 2014 13:40:00 -0500
Subject: RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false)
	failed: OLD and/or OBSOLETE method(s) found
In-Reply-To: <54A43584.6050707@oracle.com>
References: <54A43584.6050707@oracle.com>
Message-ID: <54A44300.4010801@oracle.com>


The adjustment should be in klassItable::adjust_method_entries() not the 
checking function.  I don't think check_no_old_or_obsolete_entries is 
called in product mode.

I still don't see how the first klassItable::adjust_method_entries() 
missed this function.

Coleen

On 12/31/14, 12:42 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
>   https://bugs.openjdk.java.net/browse/JDK-8068162
>
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/ 
>
>
>
> Summary:
>
>    The sun.misc.Unsafe:throwIllegalAccessError() method is used in 
> place of a default
>    interface method in the itable if a default method was not defined 
> in the interface.
>
>    This approach creates a problem when the class sun.misc.Unsafe is 
> retransformed.
>    The Method* pointer to the old (redefined) method in the itable 
> triggers an assert
>    (see the hs_err log in the bug report).
>
>    The fix is to replace the old method in the itable with the latest 
> method version.
>
>
> Testing:
>   In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests
>
>
> Thanks,
> Serguei
>


From serguei.spitsyn at oracle.com  Wed Dec 31 18:50:10 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 31 Dec 2014 10:50:10 -0800
Subject: RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false)
	failed: OLD and/or OBSOLETE method(s) found
In-Reply-To: <54A44300.4010801@oracle.com>
References: <54A43584.6050707@oracle.com> <54A44300.4010801@oracle.com>
Message-ID: <54A44562.3090207@oracle.com>

Colleen,

Thank you for a quick review.
You are right, this is a good catch!
I need to rework my fix as it is incorrect in general.


On 12/31/14 10:40 AM, Coleen Phillimore wrote:
>
> The adjustment should be in klassItable::adjust_method_entries() not 
> the checking function.  I don't think check_no_old_or_obsolete_entries 
> is called in product mode.
>
> I still don't see how the first klassItable::adjust_method_entries() 
> missed this function.

The Unsafe::throw_illegal_access is added to other itables, not to the 
one that belongs to the class Unsafe.

Thanks,
Serguei


>
> Coleen
>
> On 12/31/14, 12:42 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>>   https://bugs.openjdk.java.net/browse/JDK-8068162
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/ 
>>
>>
>>
>> Summary:
>>
>>    The sun.misc.Unsafe:throwIllegalAccessError() method is used in 
>> place of a default
>>    interface method in the itable if a default method was not defined 
>> in the interface.
>>
>>    This approach creates a problem when the class sun.misc.Unsafe is 
>> retransformed.
>>    The Method* pointer to the old (redefined) method in the itable 
>> triggers an assert
>>    (see the hs_err log in the bug report).
>>
>>    The fix is to replace the old method in the itable with the latest 
>> method version.
>>
>>
>> Testing:
>>   In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests
>>
>>
>> Thanks,
>> Serguei
>>
>